Introduction, IoT Design Methodology, Case Study on IoT System for Weather Monitoring, loT SystemsSEPM - Module 1.ppt

1
Module 1 - Chapter 1
Software and Software Engineering
Software and Software Engineering

2
Introduction
Introduction
 What is a software
What is a software?
?
 Computer software is the product that software
Computer software is the product that software
professionals build and then support over the long term.
professionals build and then support over the long term.
 Software engineering encompasses a process, a collection
Software engineering encompasses a process, a collection
of methods (practice) and an array of tools that allow
of methods (practice) and an array of tools that allow
professionals to build high quality computer software.
professionals to build high quality computer software.
 Who does it?
Who does it?
 Software engineers build and support software.
Software engineers build and support software.

3
Software’s Dual Role
Software’s Dual Role
 Software is a product
Software is a product
 As a product, it delivers computational power represented by a
As a product, it delivers computational power represented by a
network of computers that are accessible by local hardware.
network of computers that are accessible by local hardware.
 Whether it resides within a mobile phone or operates inside a
Whether it resides within a mobile phone or operates inside a
mainframe computer, software is an information transformer -
mainframe computer, software is an information transformer -
Produces, manages, acquires, modifies, displays, or transmits
Produces, manages, acquires, modifies, displays, or transmits
information.
information.
 Software is a vehicle for delivering a product
Software is a vehicle for delivering a product
 As the vehicle used to deliver the product, software acts as the basis
As the vehicle used to deliver the product, software acts as the basis
for the
for the
 Control of the computer (Eg: operating systems)
Control of the computer (Eg: operating systems)
 Communications of Information (e.g., networking software)
Communications of Information (e.g., networking software)
 Creation and control of other programs (software tools and
Creation and control of other programs (software tools and
environments).
environments).
 Supports or directly provides system functionality
Supports or directly provides system functionality

4
What is Software?
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...

5
What is Software?
What is Software?
 Software is:
Software is:
(1)
(1) instructions (computer programs) that when executed
instructions (computer programs) that when executed
provide desired features, function, and performance;
provide desired features, function, and performance;
(2) data structures that enable the programs to
(2) data structures that enable the programs to
adequately manipulate information, and
adequately manipulate information, and
(3) descriptive information in both hard copy and virtual
(3) descriptive information in both hard copy and virtual
forms that describes the operation and use of the
forms that describes the operation and use of the
programs.
programs.
(4) Software is a logical rather than a physical system
(4) Software is a logical rather than a physical system
element
element

6
Characteristics of a Software
1. Software is developed or engineered. It is not
manufactured in the classical sense
manufactured in the classical sense.
.
2.
2. Software does not “wear out.”
Software does not “wear out.”
3. Although the industry is moving toward component-
based construction, most software continues to be
based construction, most software continues to be
custom built.
custom built.

7
manufactured in the classical sense
manufactured in the classical sense.
.
Although some similarities exist between software development and
Although some similarities exist between software development and
hardware manufacturing, the two activities are fundamentally
hardware manufacturing, the two activities are fundamentally
different.
different.

8
 Figure 1.1 depicts failure rate as a function of time for hardware.
Figure 1.1 depicts failure rate as a function of time for hardware.
 The relationship, “bathtub curve,” indicates that hardware exhibits
The relationship, “bathtub curve,” indicates that hardware exhibits
relatively high failure rates early in its life (these failures are often
relatively high failure rates early in its life (these failures are often
attributable to design or manufacturing defects);
attributable to design or manufacturing defects);
 Defects are corrected and the failure rate drops to a steady-state
Defects are corrected and the failure rate drops to a steady-state
level (hopefully, quite low) for some period of time.
level (hopefully, quite low) for some period of time.
 As time passes, however, the failure rate rises again as hardware
As time passes, however, the failure rate rises again as hardware
components suffer from the cumulative effects of dust, vibration,
components suffer from the cumulative effects of dust, vibration,
abuse, temperature extremes, and many other environmental
abuse, temperature extremes, and many other environmental
maladies.
maladies.

Failure (“Bathtub”) Curve for Hardware
Failure (“Bathtub”) Curve for Hardware
Time
Failure
Rate
Infant
mortality
Wear
out

10
 Software is not susceptible to the environmental maladies that
Software is not susceptible to the environmental maladies that
cause
cause
hardware to wear out.
hardware to wear out.
 As shown in Figure 1.2. undiscovered defects will cause high
As shown in Figure 1.2. undiscovered defects will cause high
failure rates early in the life of a program.
failure rates early in the life of a program.
 However, these are corrected and the curve flattens as shown.
However, these are corrected and the curve flattens as shown.
 However, the implication is clear—software doesn’t wear out. But
However, the implication is clear—software doesn’t wear out. But
it does deteriorate!
it does deteriorate!

11
Wear vs. Deterioration
Wear vs. Deterioration
idealized curve
change
actual curve
Failure
rate
Time
increased failure
rate due to side effects

12
based construction, most software continues to be custom
based construction, most software continues to be custom
built.
built.
 Despite the trend in the software industry towards using
Despite the trend in the software industry towards using
reusable components to build software, the majority of software is
reusable components to build software, the majority of software is
still being developed from scratch to meet specific requirements.
still being developed from scratch to meet specific requirements.
 Component-based construction refers to the practice of developing
Component-based construction refers to the practice of developing
software systems by assembling and integrating pre-existing
software systems by assembling and integrating pre-existing
software components.
software components.
 Custom built software means software that is created specifically for
Custom built software means software that is created specifically for
a particular user or organization's needs, without heavily relying on
a particular user or organization's needs, without heavily relying on
pre-made components.
pre-made components.

13
Software Applications Domains
 System software
System software
 Application software
Application software
 Engineering/scientific software
Engineering/scientific software
 Embedded software
Embedded software
 Product-line software
Product-line software
 WebApps (Web applications)
WebApps (Web applications)
 AI software
AI software
There are seven broad categories of computer software
exists

14
 System software
System software :
:
 A collection of programs written to service other programs.
A collection of programs written to service other programs.
 Examples: Compilers, editors, and file management utilities,
Examples: Compilers, editors, and file management utilities,
operating system components, drivers, networking software,
operating system components, drivers, networking software,
telecommunications processors etc.
telecommunications processors etc.
 Application software
Application software:
:
 Stand-alone programs that solve a specific business need.
Stand-alone programs that solve a specific business need.
 Engineering/scientific software
Engineering/scientific software:
:
 It has been characterized by “number crunching” algorithms.
It has been characterized by “number crunching” algorithms.
Applications range from astronomy to volcanology, from
Applications range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics, and
automotive stress analysis to space shuttle orbital dynamics, and
from molecular biology to automated manufacturing.
from molecular biology to automated manufacturing.

15
 Embedded software:
Embedded software:
 Resides within a product or system and is used to implement and
Resides within a product or system and is used to implement and
control features and functions for the end user and for the system
control features and functions for the end user and for the system
itself.
itself.
 Examples: key pad control for a microwave oven, digital
Examples: key pad control for a microwave oven, digital
functions in an automobile such as fuel control, dashboard
functions in an automobile such as fuel control, dashboard
displays, and braking systems.
displays, and braking systems.
 Product-line software:
Product-line software:
 Designed to provide a specific capability for use by many
Designed to provide a specific capability for use by many
different customers.
different customers.
 Examples: Inventory control products, word processing,
Examples: Inventory control products, word processing,
spreadsheets, computer graphics, multimedia, entertainment,
spreadsheets, computer graphics, multimedia, entertainment,
database management, and personal and business financial
database management, and personal and business financial
application.
application.

16
 WebApps (Web applications):
WebApps (Web applications):
 This network-centric software.
This network-centric software.
 They are a set of linked hypertext files that present information
They are a set of linked hypertext files that present information
using text and limited graphics.
using text and limited graphics.
 However, they also provide stand-alone features, computing
However, they also provide stand-alone features, computing
functions, and content to the end user.
functions, and content to the end user.
 They are integrated with corporate databases and business
They are integrated with corporate databases and business
applications.
applications.
 AI software:
AI software:
 Makes use of non numerical algorithms to solve complex
Makes use of non numerical algorithms to solve complex
problems. Applications within this area include robotics, expert
problems. Applications within this area include robotics, expert
systems, pattern recognition (image and voice), artificial neural
systems, pattern recognition (image and voice), artificial neural
networks, theorem proving, and game playing.
networks, theorem proving, and game playing.

17
Software - New Challenges
 Open-world computing:
Open-world computing:
 The rapid growth of wireless networking may soon lead to true
The rapid growth of wireless networking may soon lead to true
pervasive, distributed computing.
pervasive, distributed computing.
 The challenge for software engineers will be to develop systems
The challenge for software engineers will be to develop systems
and application software that will allow mobile devices, personal
and application software that will allow mobile devices, personal
computers, and enterprise systems to communicate across vast
computers, and enterprise systems to communicate across vast
networks.
networks.
 Netsourcing:
Netsourcing:
 The World Wide Web is rapidly becoming a computing engine
The World Wide Web is rapidly becoming a computing engine
as well as a content provider.
as well as a content provider.
 The challenge for software engineers is to architect simple (e.g.,
The challenge for software engineers is to architect simple (e.g.,
personal financial planning) and sophisticated applications that
personal financial planning) and sophisticated applications that
provide a benefit to targeted end-user markets worldwide.
provide a benefit to targeted end-user markets worldwide.

18
 Open source
Open source:
:
 A growing trend that results in distribution of source code for
A growing trend that results in distribution of source code for
systems applications (e.g., operating systems, database, and
systems applications (e.g., operating systems, database, and
development environments) so that many people can contribute
development environments) so that many people can contribute
to its development.
to its development.
 The challenge for software engineers is to build source code that
The challenge for software engineers is to build source code that
is self-descriptive, but more importantly, to develop techniques
is self-descriptive, but more importantly, to develop techniques
that will enable both customers and developers to know what
that will enable both customers and developers to know what
changes have been made and how those changes manifest
changes have been made and how those changes manifest
themselves within the software.
themselves within the software.

19
Legacy Software
Legacy Software
 Legacy software systems were developed decades ago and have been
Legacy software systems were developed decades ago and have been
continually modified to meet changes in business requirements and
continually modified to meet changes in business requirements and
computing platforms.
computing platforms.
 The proliferation of such systems is causing headaches for large
The proliferation of such systems is causing headaches for large
organizations who find them costly to maintain and risky to evolve.
organizations who find them costly to maintain and risky to evolve.
 Many legacy systems remain supportive to core business functions
Many legacy systems remain supportive to core business functions
and are ‘indispensable’ to the business.
and are ‘indispensable’ to the business.
 Additional characteristic that is present in legacy software - poor
Additional characteristic that is present in legacy software - poor
quality, inextensible designs, convoluted code, poor or nonexistent
quality, inextensible designs, convoluted code, poor or nonexistent
documentation, test cases and results that were never archived, a
documentation, test cases and results that were never archived, a
poorly managed change history
poorly managed change history

20
Legacy Software
Legacy Software
 software must be
software must be adapted
adapted to meet the needs of new computing
to meet the needs of new computing
environments or technology.
environments or technology.
software must be enhanced
enhanced to implement new business
to implement new business
requirements.
requirements.
software must be extended to make it interoperable
extended to make it interoperable with other
with other
more modern systems or databases.
more modern systems or databases.
software must be re-architected
re-architected to make it viable within a
to make it viable within a
network environment
network environment.
Why must it change?

21
The Unique Nature of WebApps
 In the early days of the World Wide Web , websites consisted of little more than
In the early days of the World Wide Web , websites consisted of little more than
a set of linked hypertext files that presented information using text and limited
a set of linked hypertext files that presented information using text and limited
graphics.
graphics.
 As time passed, the augmentation of HTML by development tools (e.g., XML,
As time passed, the augmentation of HTML by development tools (e.g., XML,
Java) enabled Web engineers to provide computing capability alongwith
Java) enabled Web engineers to provide computing capability alongwith
informational content.
informational content.
 Web-based systems and applications (WebApps) have evolved into
Web-based systems and applications (WebApps) have evolved into
sophisticated computing tools that not only provide stand-alone function to the
sophisticated computing tools that not only provide stand-alone function to the
end user, but also have been integrated with corporate databases and business
end user, but also have been integrated with corporate databases and business
applications.
applications.
 Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel.
When an application has been designed to market or sell products or ideas,
aesthetics may have as much to do with success as technical design.

22
 The following attributes are encountered in the vast majority of
The following attributes are encountered in the vast majority of
WebApps.
WebApps.
 Network intensiveness.
Network intensiveness.
 Concurrency.
Concurrency.
 Unpredictable load.
Unpredictable load.
 Performance.
Performance.
 Availability.
Availability.
 Data driven.
Data driven.
 Content sensitive.
Content sensitive.
 Continuous evolution.
Continuous evolution.
 Immediacy.
Immediacy.
 Security.
Security.
 Aesthetics
Aesthetics

23
Software Engineering
In order to build software that is ready to meet the challenges of the
In order to build software that is ready to meet the challenges of the
twenty-first century, you must recognize a few simple realities:
twenty-first century, you must recognize a few simple realities:
 A concerted effort should be made to understand the problem before a
A concerted effort should be made to understand the problem before a
software solution is developed.
software solution is developed.
 Design becomes a pivotal activity.
Design becomes a pivotal activity.
 Software should exhibit high quality.
Software should exhibit high quality.
 Software should be maintainable.
Software should be maintainable.
These simple realities lead to one conclusion: software in all of its forms
These simple realities lead to one conclusion: software in all of its forms
and across all of its application domains should be engineered –
and across all of its application domains should be engineered –
Software Engineering.
Software Engineering.

24
Software engineering is a layered technology.
 Referring to Figure 1.3, any engineering approach (including
Referring to Figure 1.3, any engineering approach (including
software engineering) must rest on an organizational commitment to
software engineering) must rest on an organizational commitment to
quality.
quality.
 The bedrock that supports software engineering is a quality focus.
The bedrock that supports software engineering is a quality focus.

25
 The foundation for software engineering is the process layer.
The foundation for software engineering is the process layer.
 The software engineering process is the
The software engineering process is the glue
glue that holds the technology layers
that holds the technology layers
together and enables rational and timely development of computer software.
together and enables rational and timely development of computer software.
Process defines a
Process defines a framework
framework that must be established for effective delivery of
that must be established for effective delivery of
software engineering technology.
software engineering technology.
 The software process forms the
The software process forms the basis for management control of software
basis for management control of software
projects
projects and establishes the context in which technical methods are applied,
and establishes the context in which technical methods are applied,
work products (models, documents, data, reports, forms, etc.) are produced,
work products (models, documents, data, reports, forms, etc.) are produced,
milestones are established, quality is ensured, and change is properly
milestones are established, quality is ensured, and change is properly
managed.
managed.

26
 Software engineering methods provide the technical
Software engineering methods provide the technical how-to
how-to’s for building
’s for building
software.
software.
 Methods encompass a broad array of tasks that include communication,
Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
requirements analysis, design modeling, program construction, testing, and
support.
support.
 Software engineering methods rely on a set of basic principles that govern
Software engineering methods rely on a set of basic principles that govern
each area of the technology and include modeling activities and other
each area of the technology and include modeling activities and other
descriptive techniques.
descriptive techniques.

27
 Software engineering tools provide automated or semi automated support
Software engineering tools provide automated or semi automated support
for the process and the methods.
for the process and the methods.
 When tools are integrated so that information created by one tool can be used
When tools are integrated so that information created by one tool can be used
by another, a system for the support of software development, called
by another, a system for the support of software development, called
computer-aided software engineering
computer-aided software engineering, is established.
, is established.

28
The Software Process
A process is a collection of activities, actions, and tasks that are
A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
performed when some work product is to be created.
 An activity strives to achieve a broad objective (e.g., communication with
An activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the
stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort, or degree of rigor with which software
project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.
engineering is to be applied.
 An action (e.g., architectural design) encompasses a set of tasks that produce
An action (e.g., architectural design) encompasses a set of tasks that produce
a major work product (e.g., an architectural design model).
a major work product (e.g., an architectural design model).
 A task focuses on a small, but well-defined objective (e.g., conducting a unit
A task focuses on a small, but well-defined objective (e.g., conducting a unit
test) that produces a tangible outcome.
test) that produces a tangible outcome.

29
 A process framework establishes the foundation for a complete software
A process framework establishes the foundation for a complete software
engineering process by identifying a small number of framework activities
engineering process by identifying a small number of framework activities
that are applicable to all software projects, regardless of their size or
that are applicable to all software projects, regardless of their size or
complexity.
complexity.
 In addition, the process framework encompasses a set of umbrella activities
In addition, the process framework encompasses a set of umbrella activities
that are applicable across the entire software process.
that are applicable across the entire software process.

30
 A generic process framework for software engineering encompasses five
A generic process framework for software engineering encompasses five
activities:
activities:

31
Software Engineering Practice
 A generic software process model composed of a set of activities
A generic software process model composed of a set of activities
that establish a framework for software engineering practice and
that establish a framework for software engineering practice and
umbrella activities establish a skeleton architecture for software
umbrella activities establish a skeleton architecture for software
engineering work.
engineering work.
 Software Engineering Practice provides basic understanding of the
Software Engineering Practice provides basic understanding of the
generic concepts and principles that apply to framework activities.
generic concepts and principles that apply to framework activities.
 The Essence of Practice
The Essence of Practice
 General Principles
General Principles

32
The essence of software engineering practice includes:
The essence of software engineering practice includes:
1. Understand the problem (communication and analysis).
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
4. Examine the result for accuracy (testing and quality assurance).

33
Understand the problem
Understand the problem
In order to understand the problem, answering a few simple questions is
In order to understand the problem, answering a few simple questions is
necessary:
necessary:
 Who has a stake in the solution to the problem? That is, who are the
Who has a stake in the solution to the problem? That is, who are the
stakeholders?
stakeholders?
 What are the unknowns? What data, functions, and features are required to
What are the unknowns? What data, functions, and features are required to
properly solve the problem?
properly solve the problem?
 Can the problem be compartmentalized? Is it possible to represent smaller
Can the problem be compartmentalized? Is it possible to represent smaller
problems that may be easier to understand?
problems that may be easier to understand?
 Can the problem be represented graphically? Can an analysis model be
Can the problem be represented graphically? Can an analysis model be
created?
created?

34
Plan the solution
Plan the solution
Before coding, it is necessary to do little design:
Before coding, it is necessary to do little design:
 Have you seen similar problems before? Are there patterns that are
Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that implements
recognizable in a potential solution? Is there existing software that implements
the data, functions, and features that are required?
the data, functions, and features that are required?
 Has a similar problem been solved? If so, are elements of the solution
Has a similar problem been solved? If so, are elements of the solution
reusable?
reusable?
 Can sub problems be defined? If so, are solutions readily apparent for the sub
Can sub problems be defined? If so, are solutions readily apparent for the sub
problems?
problems?
 Can you represent a solution in a manner that leads to effective
Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?
implementation? Can a design model be created?

35
Carry out the plan
Carry out the plan
The design serves as a road map for the system to be build. But the “plan” will
The design serves as a road map for the system to be build. But the “plan” will
allow you to proceed without getting lost.
allow you to proceed without getting lost.
 Does the solution conform to the plan? Is source code traceable to the design
Does the solution conform to the plan? Is source code traceable to the design
model?
model?
 Is each component part of the solution provably correct? Have the design
Is each component part of the solution provably correct? Have the design
and code been reviewed, or better, have correctness proofs been applied to
and code been reviewed, or better, have correctness proofs been applied to
the algorithm?
the algorithm?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36
Software Myths
Software Myths
 Affect managers, customers (and other non-technical
Affect managers, customers (and other non-technical
stakeholders) and practitioners
stakeholders) and practitioners
 Are believable because they often have elements of truth,
Are believable because they often have elements of truth,
but …
but …
 Invariably lead to bad decisions,
Invariably lead to bad decisions,
therefore …
therefore …
 Insist on reality as you navigate your way through
Insist on reality as you navigate your way through
software engineering
software engineering

37
Process Models
Process Models

38
A Generic Process Model
 The software process is represented schematically in Figure 2.1.
The software process is represented schematically in Figure 2.1.
 Referring to the figure, each framework activity is populated by a set
Referring to the figure, each framework activity is populated by a set
of software engineering actions.
of software engineering actions.
 Each software engineering action is defined by a task set that
Each software engineering action is defined by a task set that
identifies the work tasks that are to be completed, the work products
identifies the work tasks that are to be completed, the work products
that will be produced, the quality assurance points that will be
that will be produced, the quality assurance points that will be
required, and the milestones that will be used to indicate progress.
required, and the milestones that will be used to indicate progress.

39

40
A Generic Process Model – Process Flow
 The aspect called process flow - describes how the framework
The aspect called process flow - describes how the framework
activities and the actions and tasks that occur within each framework
activities and the actions and tasks that occur within each framework
activity are organized with respect to sequence and time and is
activity are organized with respect to sequence and time and is
illustrated in Figure 2.2.
 A linear process flow executes each of the five framework activities
A linear process flow executes each of the five framework activities
in sequence, beginning with communication and culminating with
in sequence, beginning with communication and culminating with
deployment (Figure 2.2a).
deployment (Figure 2.2a).
 An iterative process flow repeats one or more of the activities before
An iterative process flow repeats one or more of the activities before
proceeding to the next (Figure 2.2b).
proceeding to the next (Figure 2.2b).

41
 An evolutionary process flow executes the activities in a “circular”
An evolutionary process flow executes the activities in a “circular”
manner. Each circuit through the five activities leads to a more
manner. Each circuit through the five activities leads to a more
complete version of the software (Figure 2.2c).
complete version of the software (Figure 2.2c).
 A parallel process flow (Figure 2.2d) executes one or more activities
A parallel process flow (Figure 2.2d) executes one or more activities
in parallel with other activities (e.g., modeling for one aspect of the
in parallel with other activities (e.g., modeling for one aspect of the
software might be executed in parallel with construction of another
software might be executed in parallel with construction of another
aspect of the software).
aspect of the software).

42

43

44
Defining a Framework Activity
 What
What actions are appropriate for a framework activity
actions are appropriate for a framework activity, given the
, given the
nature of the problem to be solved, the characteristics of the people
nature of the problem to be solved, the characteristics of the people
doing the work, and the stakeholders who are sponsoring the
doing the work, and the stakeholders who are sponsoring the
project?
project?

45
For a small software project requested by one person (at a remote
For a small software project requested by one person (at a remote
location)
location)
 Communication activity
Communication activity encompass a phone call with the
encompass a phone call with the
appropriate stakeholder.
appropriate stakeholder. Action is phone conversation.
Action is phone conversation.
 Work tasks (the
Work tasks (the task set
task set)
)
1. Make contact with stakeholder via telephone.
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
4. E-mail to stakeholder for review and approval.

46
Identifying a Task Set
 Each software engineering action (e.g., elicitation, an action
Each software engineering action (e.g., elicitation, an action
associated with the communication activity) can be represented by a
associated with the communication activity) can be represented by a
number of different task sets - each a collection of software
number of different task sets - each a collection of software
engineering work tasks, related work products, quality assurance
engineering work tasks, related work products, quality assurance
points, and project milestones.
points, and project milestones.

47

48
Process Patterns
Process Patterns
 Every software team encounters problems as it moves through the
Every software team encounters problems as it moves through the
software process.
software process.
 It would be useful if proven solutions to these problems were readily
It would be useful if proven solutions to these problems were readily
available to the team so that the problems could be addressed and
available to the team so that the problems could be addressed and
resolved quickly.
resolved quickly.
 A process pattern describes a process-related problem that is
A process pattern describes a process-related problem that is
encountered during software engineering work, identifies the
encountered during software engineering work, identifies the
environment in which the problem has been encountered, and
environment in which the problem has been encountered, and
suggests one or more proven solutions to the problem.
suggests one or more proven solutions to the problem.

49
Process Patterns
Process Patterns
 A process pattern provides a template - a consistent method for
A process pattern provides a template - a consistent method for
describing problem solutions within the context of the software
describing problem solutions within the context of the software
process.
process.
 By combining patterns, a software team can solve problems and
By combining patterns, a software team can solve problems and
construct a process that best meets the needs of a project.
construct a process that best meets the needs of a project.

50
Process Patterns
Process Patterns
 Patterns can be defined at any level of abstraction.
Patterns can be defined at any level of abstraction.
 A pattern might be used to
A pattern might be used to
 Describe a problem (and solution) associated with a complete
Describe a problem (and solution) associated with a complete
process model (e.g., prototyping).
process model (e.g., prototyping).
 Describe a problem (and solution) associated with a framework
Describe a problem (and solution) associated with a framework
activity (e.g., planning)
activity (e.g., planning)
 Describe a problem (and solution) associated with an action
Describe a problem (and solution) associated with an action
within a framework activity (e.g., project estimating).
within a framework activity (e.g., project estimating).

51
Process Patterns
Process Patterns
Ambler [Amb98] has proposed a template for describing a process
Ambler [Amb98] has proposed a template for describing a process
pattern:
pattern:
 Pattern Name:
Pattern Name: The pattern is given a meaningful name describing it
The pattern is given a meaningful name describing it
within the context of the software process (e.g., TechnicalReviews).
within the context of the software process (e.g., TechnicalReviews).
 Forces:
Forces: The environment in which the pattern is encountered and the
The environment in which the pattern is encountered and the
issues that make the problem visible and may affect its solution.
issues that make the problem visible and may affect its solution.

52
Process Patterns
Process Patterns
 Type:
Type: The pattern type is specified. Ambler [Amb98] suggests three
The pattern type is specified. Ambler [Amb98] suggests three
types:
types:
 Stage pattern
Stage pattern - defines a problem associated with a framework activity for the
- defines a problem associated with a framework activity for the
process. An example of a stage pattern might be EstablishingCommunication.
process. An example of a stage pattern might be EstablishingCommunication.
 Task pattern
Task pattern - defines a problem associated with a software engineering action or
- defines a problem associated with a software engineering action or
work task and relevant to successful software engineering practice (e.g.,
work task and relevant to successful software engineering practice (e.g.,
RequirementsGathering is a task pattern).
RequirementsGathering is a task pattern).
 Phase pattern
Phase pattern - define the sequence of framework activities that occurs within the
- define the sequence of framework activities that occurs within the
process. An example of a phase pattern might be SpiralModel or Prototyping.
process. An example of a phase pattern might be SpiralModel or Prototyping.
Patterns are applicable to many software engineering activities like Analysis,
Patterns are applicable to many software engineering activities like Analysis,
design, and testing patterns.
design, and testing patterns.

53
Process Patterns
Process Patterns
 Initial context:
Initial context: Describes the conditions under which the pattern
Describes the conditions under which the pattern
applies. Prior to the initiation of the pattern:
applies. Prior to the initiation of the pattern:
(1) What organizational or team-related activities have already occurred?
(1) What organizational or team-related activities have already occurred?
(2) What is the entry state for the process?
(2) What is the entry state for the process?
(3) What software engineering information or project information already
(3) What software engineering information or project information already
exists?
exists?
 Problem:
Problem: The specific problem to be solved by the pattern.
The specific problem to be solved by the pattern.

54
Process Patterns
Process Patterns
 Solution:
Solution: Describes how to implement the pattern successfully. This
Describes how to implement the pattern successfully. This
section describes how the initial state of the process (that exists
section describes how the initial state of the process (that exists
before the pattern is implemented) is modified as a consequence of
before the pattern is implemented) is modified as a consequence of
the initiation of the pattern.
the initiation of the pattern.
 It also describes how software engineering information or project
It also describes how software engineering information or project
information that is available before the initiation of the pattern is
information that is available before the initiation of the pattern is
transformed as a consequence of the successful execution of the
transformed as a consequence of the successful execution of the
pattern.
pattern.

55
Process Patterns
Process Patterns
 Resulting Context:
Resulting Context: Describes the conditions that will result once the
Describes the conditions that will result once the
pattern has been successfully implemented. Upon completion of the
pattern has been successfully implemented. Upon completion of the
pattern:
pattern:
(1) What organizational or team-related activities must have
(1) What organizational or team-related activities must have
occurred?
occurred?
(2) What is the exit state for the process?
(2) What is the exit state for the process?
(3) What software engineering information or project information
(3) What software engineering information or project information
has been developed?
has been developed?

56
Process Patterns
Process Patterns
 Related Patterns:
Related Patterns: Provide a list of all process patterns that are
Provide a list of all process patterns that are
directly related to this pattern.
directly related to this pattern.
 Known Uses and Examples
Known Uses and Examples: Indicate the specific instances in which
: Indicate the specific instances in which
the pattern is applicable. For example, Communication is mandatory
the pattern is applicable. For example, Communication is mandatory
at the beginning of every software project, is recommended
at the beginning of every software project, is recommended
throughout the software project, and is mandatory once the
throughout the software project, and is mandatory once the
deployment activity is under way.
deployment activity is under way.

57
Process Patterns
Process Patterns

58
Process Assessment and Improvement
 The existence of a software process is no guarantee that software will
The existence of a software process is no guarantee that software will
be delivered on time, that it will meet the customer’s needs, or that it
be delivered on time, that it will meet the customer’s needs, or that it
will exhibit the technical characteristics that will lead to long-term
will exhibit the technical characteristics that will lead to long-term
quality characteristics.
quality characteristics.
 The process itself can be assessed to ensure that it meets a set of basic
The process itself can be assessed to ensure that it meets a set of basic
process criteria that have been shown to be essential for a successful
process criteria that have been shown to be essential for a successful
software engineering.
software engineering.

59
A number of different approaches to software process assessment and
improvement have been proposed over the past few decades:
 Standard CMMI Assessment Method for Process Improvement
Standard CMMI Assessment Method for Process Improvement
(SCAMPI)
(SCAMPI) - provides a five-step process assessment model that
- provides a five-step process assessment model that
incorporates five phases: initiating, diagnosing, establishing, acting,
incorporates five phases: initiating, diagnosing, establishing, acting,
and learning. The SCAMPI method uses the SEI CMMI as the basis for
and learning. The SCAMPI method uses the SEI CMMI as the basis for
assessment [SEI00].
assessment [SEI00].
 CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
- provides a diagnostic technique for assessing the relative maturity of
- provides a diagnostic technique for assessing the relative maturity of
a software organization; uses the SEI CMM as the basis for the
a software organization; uses the SEI CMM as the basis for the
assessment [Dun01].
assessment [Dun01].

60
 SPICE (ISO/IEC15504)
SPICE (ISO/IEC15504) - a standard that defines a set of requirements
- a standard that defines a set of requirements
for software process assessment. The intent of the standard is to assist
for software process assessment. The intent of the standard is to assist
organizations in developing an objective evaluation of the efficacy of
organizations in developing an objective evaluation of the efficacy of
any defined software process [ISO08].
any defined software process [ISO08].
 ISO 9001:2000 for Software
ISO 9001:2000 for Software - a generic standard that applies to any
- a generic standard that applies to any
organization that wants to improve the overall quality of the products,
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies [Ant06].
applicable to software organizations and companies [Ant06].

61
Prescriptive Process Models
 The Waterfall Model
The Waterfall Model
 The waterfall model is the oldest paradigm for software engineering.
The waterfall model is the oldest paradigm for software engineering.
 The Waterfall model, sometimes called the classic life cycle, suggests a
The Waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins with
systematic, sequential approach to software development that begins with
customer specification of requirements and progresses through planning,
customer specification of requirements and progresses through planning,
modeling, construction, and deployment, culminating in ongoing support
modeling, construction, and deployment, culminating in ongoing support
of the completed software (Figure 2.3).
of the completed software (Figure 2.3).
 This model is applicable
This model is applicable
 when well-defined adaptations or enhancements to an existing system must be
when well-defined adaptations or enhancements to an existing system must be
made.
made.
 When requirements are well defined and reasonably stable in case of new
When requirements are well defined and reasonably stable in case of new
development efforts.
development efforts.

62
 The Waterfall Model
The Waterfall Model

63
 The V - model
The V - model
 A variation in the representation of the waterfall model is called the V-
A variation in the representation of the waterfall model is called the V-
model. Represented in Figure 2.4, the V-model depicts the relationship of
model. Represented in Figure 2.4, the V-model depicts the relationship of
quality assurance actions to the actions associated with communication,
quality assurance actions to the actions associated with communication,
modeling, and early construction activities.
modeling, and early construction activities.
 As a software team moves down the left side of the V, basic problem
As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical
requirements are refined into progressively more detailed and technical
representations of the problem and its solution.
representations of the problem and its solution.
 Once code has been generated, the team moves up the right side of the V,
Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that
essentially performing a series of tests (quality assurance actions) that
validate each of the models created as the team moved down the left side.
validate each of the models created as the team moved down the left side.

64
The V- model
The V- model

65
 The Waterfall model
The Waterfall model
 In reality, there is no fundamental difference between the classic life cycle
In reality, there is no fundamental difference between the classic life cycle
and the V-model. The V-model provides a way of visualizing how
and the V-model. The V-model provides a way of visualizing how
verification and validation actions are applied to earlier engineering work.
verification and validation actions are applied to earlier engineering work.
 The problems that are encountered when the waterfall model is applied
The problems that are encountered when the waterfall model is applied
are:
are:
1. Real projects rarely follow the sequential flow.
1. Real projects rarely follow the sequential flow.
2. It is often difficult for the customer to state all requirements explicitly.
2. It is often difficult for the customer to state all requirements explicitly.
3. The customer must have patience. A working version of the program(s)
3. The customer must have patience. A working version of the program(s)
will not be available until late in the project time span.
will not be available until late in the project time span.

66
 The Waterfall model
The Waterfall model
 Today, software work is fast-paced and subject to a never-ending stream
Today, software work is fast-paced and subject to a never-ending stream
of changes (to features, functions, and information content).
of changes (to features, functions, and information content).
 The waterfall model is often inappropriate for such work.
The waterfall model is often inappropriate for such work.
 However, it can serve as a useful process model in situations where
However, it can serve as a useful process model in situations where
requirements are fixed and work is to proceed to completion in a linear
requirements are fixed and work is to proceed to completion in a linear
manner.
manner.

67
 Incremental Process Model
Incremental Process Model
 Incremental Process Model is used when initial software requirements are
Incremental Process Model is used when initial software requirements are
reasonably well defined.
reasonably well defined.
 But there may be a need to provide a limited set of software functionality
But there may be a need to provide a limited set of software functionality
to users quickly and then refine and expand on that functionality in later
to users quickly and then refine and expand on that functionality in later
software releases.
software releases.
 This process model is designed to produce the software in increments.
This process model is designed to produce the software in increments.
 The incremental model combines elements of linear and parallel process
The incremental model combines elements of linear and parallel process
flows.
flows.

68

69
 For example, word-processing software developed using the incremental
For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document
paradigm might deliver basic file management, editing, and document
production functions in the first increment;
production functions in the first increment;
 More sophisticated editing and document production capabilities in the
More sophisticated editing and document production capabilities in the
second increment;
second increment;
 Spelling and grammar checking in the third increment;
Spelling and grammar checking in the third increment;
 and advanced page layout capability in the fourth increment.
and advanced page layout capability in the fourth increment.

70
 When an incremental model is used, the first increment is often a core
When an incremental model is used, the first increment is often a core
product. That is, basic requirements are addressed but many supplementary
product. That is, basic requirements are addressed but many supplementary
features (some known, others unknown) remain undelivered.
features (some known, others unknown) remain undelivered.
 The core product is used by the customer (or undergoes detailed
The core product is used by the customer (or undergoes detailed
evaluation).
evaluation).
 As a result of use and/or evaluation, a plan is developed for the next
As a result of use and/or evaluation, a plan is developed for the next
increment.
increment.
 The plan addresses the modification of the core product to better meet the
The plan addresses the modification of the core product to better meet the
needs of the customer and the delivery of additional features and
needs of the customer and the delivery of additional features and
functionality.
functionality.

71
 This process is repeated following the delivery of each increment, until
This process is repeated following the delivery of each increment, until
the complete product is produced.
the complete product is produced.
 The incremental process model focuses on the delivery of an operational
The incremental process model focuses on the delivery of an operational
product with each increment.
product with each increment.
 Incremental development is particularly useful when staffing is
Incremental development is particularly useful when staffing is
unavailable for a complete implementation.
unavailable for a complete implementation.
 Early increments can be implemented with fewer people. If the core
Early increments can be implemented with fewer people. If the core
product is well received, then additional staff (if required) can be added to
product is well received, then additional staff (if required) can be added to
implement the next increment.
implement the next increment.
 In addition, increments can be planned to manage technical risks.
In addition, increments can be planned to manage technical risks.

72
 Evolutionary Process Models
Evolutionary Process Models
 Software evolves over a period of time. Business and product
Software evolves over a period of time. Business and product
requirements often change as development proceeds, making an end
requirements often change as development proceeds, making an end
product unrealistic;
product unrealistic;
 Tight market deadlines make completion of a comprehensive software
Tight market deadlines make completion of a comprehensive software
product impossible, but a limited version must be introduced to meet
product impossible, but a limited version must be introduced to meet
competitive or business pressure;
competitive or business pressure;
 A set of core product or system requirements is well understood, but the
A set of core product or system requirements is well understood, but the
details of product or system extensions have yet to be defined.
details of product or system extensions have yet to be defined.
 Evolutionary models are iterative. They are enables you to develop
Evolutionary models are iterative. They are enables you to develop
increasingly more complete versions of the software.
increasingly more complete versions of the software.

73
 Evolutionary Process Models
Evolutionary Process Models
Two evolutionary process models –
Two evolutionary process models –
1. Prototyping
1. Prototyping
2. The Spiral Model
2. The Spiral Model

74
 Evolutionary Process Models –
Evolutionary Process Models – Prototyping
Prototyping
 Customer
Customer
 Defines a set of general objectives for software
Defines a set of general objectives for software
 But does not identify detailed requirements for functions and features.
But does not identify detailed requirements for functions and features.
 In other cases, the developer may be
In other cases, the developer may be
 Unsure of the efficiency of an algorithm
Unsure of the efficiency of an algorithm
 The adaptability of an operating system
The adaptability of an operating system
 The form that human-machine interaction should take.
The form that human-machine interaction should take.
 In these, and many other situations, a prototyping paradigm may offer the
In these, and many other situations, a prototyping paradigm may offer the
best approach.
best approach.
 Prototyping paradigm assists you and other stakeholders to better
Prototyping paradigm assists you and other stakeholders to better
understand what is to be built when requirements are fuzzy.
understand what is to be built when requirements are fuzzy.

75
Prototyping
 The prototyping paradigm (Figure 2.6) begins with communication. You
The prototyping paradigm (Figure 2.6) begins with communication. You
meet with other stakeholders to define the overall objectives for the
meet with other stakeholders to define the overall objectives for the
software, identify whatever requirements are known, and outline areas
software, identify whatever requirements are known, and outline areas
where further definition is mandatory.
where further definition is mandatory.
 A prototyping iteration is planned quickly, and modeling (in the form of a
A prototyping iteration is planned quickly, and modeling (in the form of a
“quick design”) occurs.
“quick design”) occurs.
 A quick design focuses on a representation of those aspects of the
A quick design focuses on a representation of those aspects of the
software that will be visible to end users (e.g., human interface layout or
software that will be visible to end users (e.g., human interface layout or
output display formats).
output display formats).

76
Prototyping
 The quick design leads to the construction of a prototype.
The quick design leads to the construction of a prototype.
 The prototype is deployed and evaluated by stakeholders, who provide
The prototype is deployed and evaluated by stakeholders, who provide
feedback that is used to further refine requirements.
feedback that is used to further refine requirements.
 The prototype can serve as “the first system.”
The prototype can serve as “the first system.”
 Although some prototypes are built as “throwaways,” other prototype
Although some prototypes are built as “throwaways,” other prototype
slowly evolves into the actual system.
slowly evolves into the actual system.
 Both stakeholders and software engineers like the prototyping paradigm.
Both stakeholders and software engineers like the prototyping paradigm.
 Users get a feel for the actual system, and developers get to build
Users get a feel for the actual system, and developers get to build
something immediately.
something immediately.

77
Prototyping
Prototyping can be problematic for the following reasons:
Prototyping can be problematic for the following reasons:
 Stakeholders see what appears to be a working version of the software,
Stakeholders see what appears to be a working version of the software,
unaware that the prototype is held together haphazardly, unaware that in
unaware that the prototype is held together haphazardly, unaware that in
the rush to get it working you haven’t considered overall software quality
the rush to get it working you haven’t considered overall software quality
or long-term maintainability.
or long-term maintainability.
 As a software engineer, you often make implementation compromises in
As a software engineer, you often make implementation compromises in
order to get a prototype working quickly. An inappropriate operating
order to get a prototype working quickly. An inappropriate operating
system or programming language may be used simply because it is
system or programming language may be used simply because it is
available and known; an inefficient algorithm may be implemented
available and known; an inefficient algorithm may be implemented
simply to demonstrate capability.
simply to demonstrate capability.

78
Prototyping

79
Evolutionary Process Models – The Spiral Model
The Spiral Model
 Originally proposed by Barry Boehm, the spiral model, is an evolutionary
Originally proposed by Barry Boehm, the spiral model, is an evolutionary
software process model that couples the iterative nature of prototyping
software process model that couples the iterative nature of prototyping
with the controlled and systematic aspects of the waterfall model.
with the controlled and systematic aspects of the waterfall model.

80
The Spiral Model
 Boehm describes the model in the following manner:
Boehm describes the model in the following manner:
 The spiral development model is a risk-driven process model generator
The spiral development model is a risk-driven process model generator
that is used to guide multi-stakeholder concurrent engineering of software
that is used to guide multi-stakeholder concurrent engineering of software
intensive systems.
intensive systems.
 It has two main distinguishing features.
It has two main distinguishing features.
 One is a
One is a cyclic approach for incrementally growing
cyclic approach for incrementally growing a system’s degree of
a system’s degree of
definition and implementation while decreasing its
definition and implementation while decreasing its degree of risk
degree of risk.
.
 The other is a set of anchor point milestones for ensuring stakeholder
The other is a set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system solutions.
commitment to feasible and mutually satisfactory system solutions.

81
The Spiral Model
 Using the spiral model, software is developed in a series of evolutionary
Using the spiral model, software is developed in a series of evolutionary
releases.
releases.
 During early iterations, the release might be a model or prototype.
During early iterations, the release might be a model or prototype.
 During later iterations, increasingly more complete versions of the
During later iterations, increasingly more complete versions of the
engineered system are produced.
engineered system are produced.

82
The Spiral Model
 A spiral model is divided into a set of framework activities defined by the
A spiral model is divided into a set of framework activities defined by the
software engineering team.
software engineering team.
 Each of the framework activities represent one segment of the spiral path
Each of the framework activities represent one segment of the spiral path
 The software team performs activities in a clockwise direction, beginning
The software team performs activities in a clockwise direction, beginning
at the center.
at the center.
 Risk is considered as each revolution is made.
Risk is considered as each revolution is made.
 Anchor point milestones - a combination of work products and conditions
Anchor point milestones - a combination of work products and conditions
that are attained along the path of the spiral - are noted for each
that are attained along the path of the spiral - are noted for each
evolutionary pass.
evolutionary pass.

83
The Spiral Model
 The first circuit around the spiral might result in the development of a
The first circuit around the spiral might result in the development of a
product specification;
product specification;
 Subsequent passes around the spiral might be used to develop a prototype
Subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the software.
and then progressively more sophisticated versions of the software.
 Each pass through the planning region results in adjustments to the
Each pass through the planning region results in adjustments to the
project plan.
project plan.
 Cost and schedule are adjusted based on feedback derived from the
Cost and schedule are adjusted based on feedback derived from the
customer after delivery.
customer after delivery.
 In addition, the project manager adjusts the planned number of iterations
In addition, the project manager adjusts the planned number of iterations
required to complete the software.
required to complete the software.

84
Specialized Process Models
 Specialized process models take on many of the characteristics of one or
Specialized process models take on many of the characteristics of one or
more of the traditional models like waterfall model, spiral model etc.
more of the traditional models like waterfall model, spiral model etc.
 However, these models tend to be applied when a specialized or software
However, these models tend to be applied when a specialized or software
engineering approach is chosen. Examples include
engineering approach is chosen. Examples include
 Component-Based Development
Component-Based Development
 The Formal Methods Model
The Formal Methods Model
 Aspect-Oriented Software Development
Aspect-Oriented Software Development

85
 The component-based development model incorporates many of the
The component-based development model incorporates many of the
characteristics of the spiral model.
characteristics of the spiral model.
 It is evolutionary in nature, demanding an iterative approach to the
It is evolutionary in nature, demanding an iterative approach to the
creation of software.
creation of software.
 However, the component-based development model constructs
However, the component-based development model constructs
applications from prepackaged software components.
applications from prepackaged software components.
 Prepackaged software components means Commercial off-the-shelf
Prepackaged software components means Commercial off-the-shelf
(COTS) software components, developed by vendors, provide targeted
(COTS) software components, developed by vendors, provide targeted
functionality with well-defined interfaces that enable the component to be
functionality with well-defined interfaces that enable the component to be
integrated into the software that is to be built.
integrated into the software that is to be built.

86
 Modeling and construction activities begin with the identification of
Modeling and construction activities begin with the identification of
candidate components.
candidate components.
 These components can be designed as either conventional software
These components can be designed as either conventional software
modules or object-oriented classes or packages of classes.
modules or object-oriented classes or packages of classes.

87
 Regardless of the technology that is used to create the components, the
Regardless of the technology that is used to create the components, the
component-based development model incorporates the following steps:
component-based development model incorporates the following steps:
1. Available component-based products are researched and evaluated for
1. Available component-based products are researched and evaluated for
the application domain in question.
the application domain in question.
2. Component integration issues are considered.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
5. Comprehensive testing is conducted to ensure proper functionality.

88
 The component-based development model leads to software reuse, and
The component-based development model leads to software reuse, and
reusability provides software engineers with a number of measurable
reusability provides software engineers with a number of measurable
benefits.
benefits.
 Software engineering team can achieve a reduction in development cycle
Software engineering team can achieve a reduction in development cycle
time as well as a reduction in project cost if component reuse becomes part
time as well as a reduction in project cost if component reuse becomes part
of your culture.
of your culture.

89
 The formal methods model encompasses a set of activities that leads to
The formal methods model encompasses a set of activities that leads to
formal mathematical specification of computer software
formal mathematical specification of computer software.
.
 Formal methods enable you to specify, develop, and verify a computer-
Formal methods enable you to specify, develop, and verify a computer-
based system by applying a rigorous, mathematical notation.
based system by applying a rigorous, mathematical notation.
 When formal methods are used during development, they provide a
When formal methods are used during development, they provide a
mechanism for eliminating many of the problems that are difficult to
mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms.
overcome using other software engineering paradigms.
 Ambiguity, incompleteness, and inconsistency can be discovered and
Ambiguity, incompleteness, and inconsistency can be discovered and
corrected more easily through the application of mathematical analysis.
corrected more easily through the application of mathematical analysis.

90
 When formal methods are used during design, they serve as a basis for
When formal methods are used during design, they serve as a basis for
program verification and offers the promise of defect-free software.
program verification and offers the promise of defect-free software.
 But,
But,
 The development of formal models is currently quite time consuming and
The development of formal models is currently quite time consuming and
expensive.
expensive.
 Because few software developers have the necessary background to apply
Because few software developers have the necessary background to apply
formal methods, extensive training is required.
formal methods, extensive training is required.
 It is difficult to use the models as a communication mechanism for
It is difficult to use the models as a communication mechanism for
technically unsophisticated customers.
technically unsophisticated customers.

91
 Aspect-oriented software development (AOSD), often referred to as
Aspect-oriented software development (AOSD), often referred to as
aspect-oriented programming (AOP), is a relatively new software
aspect-oriented programming (AOP), is a relatively new software
engineering paradigm that provides a process and methodological
engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing aspects.
approach for defining, specifying, designing, and constructing aspects.
 An aspect of a program is a feature linked to many other parts of the
An aspect of a program is a feature linked to many other parts of the
program, but is not related to the program's primary function.
program, but is not related to the program's primary function.

92
 When concerns cut across multiple system functions, features, and
When concerns cut across multiple system functions, features, and
information, they are often referred to as crosscutting concerns.
information, they are often referred to as crosscutting concerns.
 Aspectual requirements define those crosscutting concerns that have an
Aspectual requirements define those crosscutting concerns that have an
impact across the software architecture.
impact across the software architecture.
 Cross-cutting concerns are parts of a program that rely on or must affect
Cross-cutting concerns are parts of a program that rely on or must affect
many other parts of the system. They form the basis for the development
many other parts of the system. They form the basis for the development
of
of aspects. Such cross-cutting concerns do not fit cleanly into
. Such cross-cutting concerns do not fit cleanly into
object-oriented programming or
or procedural programming.
.

93
 A distinct aspect-oriented process has not yet matured.
A distinct aspect-oriented process has not yet matured.
 However, it is likely that such a process will adopt characteristics of both
However, it is likely that such a process will adopt characteristics of both
evolutionary and concurrent process models.
evolutionary and concurrent process models.
 The evolutionary model is appropriate as aspects are identified and then
The evolutionary model is appropriate as aspects are identified and then
constructed.
constructed.
 The parallel nature of concurrent development is essential because aspects
The parallel nature of concurrent development is essential because aspects
are engineered independently of localized software components and yet,
are engineered independently of localized software components and yet,
aspects have a direct impact on these components.
aspects have a direct impact on these components.

Introduction, IoT Design Methodology, Case Study on IoT System for Weather Monitoring, loT SystemsSEPM - Module 1.ppt

More Related Content

Similar to Introduction, IoT Design Methodology, Case Study on IoT System for Weather Monitoring, loT SystemsSEPM - Module 1.ppt (20)

Recently uploaded (20)

Introduction, IoT Design Methodology, Case Study on IoT System for Weather Monitoring, loT SystemsSEPM - Module 1.ppt