SOFTWARE ENGINEERING

AND PROJECT
MANAGEMENT
 SCHEME

 SOFTWARE ENGINEERING & PROJECT

MANAGEMENT Course Code 21CS61
 Teaching Hours/Week (L:T:P: S) 2:2:0:0
 CIE Marks 50
 SEE Marks 50
 Total Marks 100
 Credits 03
 Course Outcomes

At the end of the course the student will be able to:

CO 1. Understand the activities involved in software
engineering and analyze the role of various process models
CO 2. Explain the basics of object-oriented concepts and
build a suitable class model using modelling techniques
CO 3. Describe various software testing methods and to
understand the importance of agile methodology and DevOps
CO 4. Illustrate the role of project planning and quality
management in software development
CO 5. Understand the importance of activity planning and
different planning models
 Lecturer method (L) need not to be only a traditional
lecture method, but alternative effective teaching
methods could be adopted to attain the outcomes.
 Use of Video/Animation to explain functioning of various
concepts.
 Encourage collaborative (Group Learning) Learning in the
class.
 Ask at least three HOT (Higher order Thinking) questions
in the class, which promotes critical thinking.
 Adopt Problem Based Learning (PBL),
Textbooks
 1. Roger S. Pressman: Software Engineering-
A Practitioners approach, 7th Edition, Tata
McGraw Hill.
2. Bob Hughes, Mike Cotterell, Rajib Mall:
Software Project Management, 6th Edition,
McGraw Hill Education, 2018.
Module-1 Software and Software Engineering: The
nature of Software, The unique nature of WebApps,
Software Engineering, The software Process, The
software Engineering practice, The software myths,
Textbook 1: Chapter 1: 1.1 to 1.7
Process Models: A generic process model, Process
assessment and improvement, Prescriptive process
models, Waterfall model, Incremental process models,
Evolutionary process models, Concurrent models,
Specialized process models. Textbook 1: Chapter 2: 2.1
to 2.4
 Module-2:Understanding Requirements:
Textbook 1: Chapter 5: 5.1 to 5.7 Requirements
Modeling. Textbook 1: Chapter 6: 6.1 to 6.5
 Module-3 AGILE DEVELOPMENT: Textbook 1:
Chater 3: 3.1 to 3.6, Chapter 4: 4.1 to 4.4
 Module-4 Introduction to Project Management:
Textbook 2: Chapter 1: 1.1 to 1.17
 Module-5 Software Quality: Textbook 2:
Chapter 13: (13.1 to 13.14)
 MODULE-I

Software and Software

Engineering:
The nature of Software, The unique nature
of WebApps, Software Engineering, The
software Process, The software
Engineering practice, The software myths,
How it all starts Textbook 1: Chapter 1: 1.1
to 1.7
 INTRODUCTION

 “The old-school view of software—you buy it, you own it, and
it’s your job to manage it—that’s coming to an end.
 Today, with Web 2.0 and pervasive computing we’re see a
completely different generation of software. It’ll be delivered via
the Internet and will look exactly like it’s residing on each user’s
computing device . . . but it’ll reside on a far-away server.”
 Why is it important? Software is important because it affects
nearly every aspect of our lives and has become pervasive in
our commerce, our culture, and our everyday activities.
Software engineering is important because it enables us to build
complex systems in a timely manner and with high quality
 What is software?

 Computer software is the product that

software professionals build and then support
over the long term.
 It encompasses programs that execute within
a computer of any size and architecture,
content that is presented as the computer
programs execute, and descriptive information
in both hard copy and virtual forms that
encompass virtually any electronic media.
 SOFTWARE

Defining Software
Software is: (1) instructions (computer programs)
that when executed provide desired features,
function, and performance; (2) data structures
that enable the programs to effectively
manipulate information, and (3) descriptive
information in both hard copy and virtual forms
that describes the operation and use of the
programs.
 Software Engineering

 Software engineering encompasses a

process, a collection of methods (practice)
and an array of tools that allow professionals
to build high quality computer software.
 Who does it? Software engineers build and
support software, and virtually everyone in
the industrialized world uses it either directly
or indirectly.
What is the work product?

 From the point of view of a software

engineer, the work product is the set of
programs, content (data), and other work
products that are computer software.

 But from the user’s viewpoint, the work

product is the resultant information that
somehow makes the user’s world better
 NATURE OF SOFTWARE

 Today, software takes on a dual role. It is a

product, and at the same time, the vehicle for
delivering a product.
 The role of computer software has undergone
significant change over the last half-century.
 Teams of software specialists, each focusing
on one part of the technology required to
deliver a complex application, have replaced
the lone programmer of an earlier era
 NATURE OF SOFTWARE

 Why does it take so long to get software finished?

 Why are development costs so high?
 Why can’t we find all errors before we give the
software to our customers?
 Why do we spend so much time and effort
maintaining existing programs?
 Why do we continue to have difficulty in
measuring progress as software is being
developed and maintained?
Software Characteristics

Software is a logical rather than a physical system element.

Therefore, software has characteristics that are considerably
different than those of hardware:
1.Software is developed or engineered; it is not
manufactured in the classical sense.
 In both activities, high quality is achieved through good design, but
the manufacturing phase for hardware can introduce quality problems
that are nonexistent (or easily corrected) for software
 Both activities require the construction of a “product,” but the
approaches are different. Software costs are concentrated in
engineering.

2.Software doesn’t “wear out.” But it does deteriorate!

Software Characteristics

2. Software doesn’t “wear out.”

Hardware exhibits relatively high failure rates early

in its life (design or manufacturing defects); defects
are corrected and the failure rate drops to a steady-
state level for some period of time. As time passes,
however, the failure rate rises again as hardware
components suffer from the cumulative effects of
dust, vibration, temperature extremes etc. Stated
simply, the hardware begins to wear out
Figure 1: Failure curve
for hardware

Figure 1.2: Failure curves

for software
Software Characteristics

 Software is not susceptible to the environmental

maladies that cause hardware to wear out. In
theory, therefore, the failure rate curve for
software should take the form of the “idealized
curve” shown in Figure. Undiscovered defects
will cause high failure rates early in the life of a
program. However, these are corrected and the
curve flattens as shown.. However, the
implication is clear—software doesn’t wear
out. But it does deteriorate!
Software Characteristics

 When a hardware component wears out, it is

replaced by a spare part. There are no software
spare parts.
 Every software failure indicates an error in design
or in the process through which design was
translated into machine executable code.
Therefore, the software maintenance tasks
that accommodate requests for change
involve considerably more complexity than
hardware maintenance.
Software Characteristics

3. Although the industry is moving toward

component-based construction, most software
continues to be custom built.

In the hardware world, component reuse is a natural

part of the engineering process. Standard screws and
off-the-shelf ICs are only two of thousands of standard
components that are used by mechanical and electrical
engineers as they design new systems. In the software
world, it is something that has only begun to be
achieved on a broad scale.
 Software Characteristics

 A software component should be designed and

implemented so that it can be reused in many
different programs. Modern reusable components
encapsulate both data and the processing that is
applied to the data, enabling the software engineer
to create new applications from reusable parts.
 For example, today’s interactive user interfaces are
built with reusable components that enable the
creation of graphics windows, pull-down menus, and
a wide variety of interaction mechanisms.
Software Application Domains
(seven categories of Computer Software)

 System software
a collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management
utilities) processes complex, but determinate, information structures.
Other systems applications (e.g., operating system components,
drivers, networking software, telecommunications processors)
process largely indeterminate data.
the systems software area is characterized by heavy interaction with
computer hardware
 Application software
stand-alone programs that solve a specific business need.
Applications in this area process business or technical data in a way
that facilitates business operations or management/technical
decision making
 Engineering/scientific software
characterized by “number crunching” algorithms. Applications
range from astronomy to volcanology, from automotive stress
analysis to space shuttle orbital dynamics, and from molecular
biology to automated manufacturing. Computer-aided design,
system simulation, and other interactive applications have
begun to take on real-time and even system software
characteristics.

 Embedded software
software—resides within a product or system and is used to
implement and control features and functions for the end user
and for the system itself. (e.g., key pad control for a microwave
 Product-line software
designed to provide a specific capability for use by many
different customers. Product-line software can focus on a limited
and esoteric marketplace (e.g., inventory control products) (e.g.,
word processing, spreadsheets, computer graphics,
multimedia, database management, and personal and business
financial applications).

 Web applications
called “WebApps,” this network-centric software category
spans a wide array of applications. In their simplest form,
WebApps can be little more than a set of linked hypertext files
that present information using text and limited graphics
 Artificial intelligence
software
- makes use of nonnumerical algorithms to
solve complex problems that are not
amenable to computation or straightforward
analysis.
Applications within this area include robotics,
expert systems, pattern recognition and game
playing.
 Legacy software

Some other programs are older, in some cases much older.

Legacy software systems . . . were developed decades ago

and have been continually modified to meet changes in
business requirements and computing platforms.

The production of such systems is causing headaches for

large organizations who find them costly to maintain and
1
risky to evolve.
 Legacy Software

 Many legacy systems remain supportive to core business

functions and are ‘essential’ to the business. What to do?
 What types of changes are made to legacy systems?
 The software must be adapted to meet the needs of new
computing environments or technology.
 The software must be enhanced to implement new business
requirements.
 The software must be extended to make it interoperable with other
more modern systems or databases.
 The software must be re-architected to make it feasible within a
1
network environment.
 UNIQUE NATURE OF
WEBAPPS

 A set of linked hypertext files that presented

information using text and limited graphics

 Today, WebApps have evolved into

sophisticated computing tools that not only
provide stand-alone function to the end user,
but also have been integrated with corporate
databases and business applications.
 What characteristic
differentiates WebApps
from other software?
 The following attributes are encountered in the vast
majority of WebApps:
 Network intensiveness: A WebApp resides on a
network and must serve the needs of a diverse
community of clients. The network may enable
worldwide access and communication (i.e., the Internet)
or more limited access and communication (e.g., a
corporate Intranet).
 Concurrency: A large number of users may access
the WebApp at one time. In many cases, the patterns of
usage among end users will vary greatly
 What characteristic
differentiates WebApps
from other software?
 Unpredictable load: The number of users of the
WebApp may vary by orders of magnitude from day
to day.
 Performance: If a WebApp user must wait too long
(for access, for serverside processing, for client-side
formatting and display), he or she may decide to go
elsewhere.
 Availability: Although expectation of 100 percent
availability is unreasonable, users of popular
WebApps often demand access on a 24/7/365 basis.
 What characteristic
differentiates WebApps
from other software?
 Data driven. The primary function of many WebApps is to use
hypermedia to present text, graphics, audio, and video content to
the end user. In addition, WebApps are commonly used to access
information that exists on databases (e.g., e-commerce or financial
applications).
 Content sensitive. The quality and aesthetic nature of content
remains an important determinant of the quality of a WebApp.
 Continuous evolution. Unlike conventional application software
that evolves over a series of planned, chronologically spaced
releases, Web applications evolve continuously. It is not unusual for
some WebApps to be updated on a minute-by-minute schedule or
for content to be independently computed for each request.
 What characteristic
differentiates WebApps
from other software?
 Immediacy: Although immediacy—the compelling need to get
software to market quickly—is a characteristic of many application
domains, WebApps often exhibit a time-to-market that can be a matter of
a few days or weeks.
 Security: Because WebApps are available via network access, it is
difficult, to limit the population of end users who may access the
application. In order to protect sensitive content and provide secure
modes of data transmission, strong security measures must be
implemented throughout the infrastructure that supports a WebApp and
within the application itself.
 Aesthetics. 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
 Software Engineering

 [Software engineering is] the establishment and

use of sound engineering principles in order to
obtain economically software that is reliable and
works efficiently on real machines.
 Software Engineering: (1) The application of a
systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of
software; that is, the application of engineering
to software. (2) The study of approaches as in
(1).
Software Engineering
Layers
 Software Engineering
Layers

 Software engineering is a layered technology.

 The foundation for software engineering is the process
layer.
 Process defines a framework that must be established for
effective delivery of software engineering technology.
The software process forms the basis for management
control of software projects and establishes the context
in which technical methods are applied, work products
(models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured,
and change is properly managed.
 Software Engineering
Layers

 Software engineering methods provide the technical how-to’s

for building software. Methods encompass a broad array of
tasks that include communication, requirements analysis,
design modeling, program construction, testing, and support.

 Software engineering tools provide automated or semi-

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

A process is a collection of activities,

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

A generic process framework for software engineering

encompasses five activities:
 Communication
important to communicate and collaborate with the customer
and other stakeholders. The intent is to understand stakeholders’
objectives for the project and to gather requirements.
 Planning
planning activity creates a “map” that helps, guide .The map—
called a software project plan—defines the software engineering
work by describing the technical tasks to be conducted.
generic process framework

 Modeling
creating models to better understand software requirements
and the design that will achieve requirements.
 Construction
This activity combines code generation (either manual or
automated) and the testing that is required to uncover errors in
the code.
 Deployment
The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the
delivered product and provides feedback based on the evaluation
 umbrella activities

Software engineering process framework activities are complemented by

a number of umbrella activities In general, umbrella activities are
applied throughout a software project and help a software team
manage and control progress, quality, change, and risk. Typical
umbrella activities include:
 Software project tracking and control
allows the software team to assess progress against the project plan
and take any necessary action to maintain the schedule.
 Risk management
assesses risks that may affect the outcome of the project or the
quality of the product.
 Technical reviews
assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
 umbrella activities
 Software quality assurance
defines and conducts the activities required to ensure
software quality.
 Measurement
Measurement—defines and collects process, project, and
product measures that assist the team in delivering software
that meets stakeholders’ needs
 Software configuration management
manages the effects of change throughout the software
process
 Reusability management
defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable
components.
 Work product preparation and production
 SOFTWARE ENGINEERING
PRACTICE

 The Essence of Practice

• Understand the problem (communication and
analysis).
• Plan a solution (modeling and software design).
• Carry out the plan (code generation).
• Examine the result for accuracy (testing and quality
assurance).
 Understand the problem

 who are the stakeholders? •

 What are the unknowns? What data,
functions, and features are required to
properly solve the problem?
 Can the problem be compartmentalized? Is it
possible to represent smaller problems that
may be easier to understand?
 Can the problem be represented graphically?
Can an analysis model be created?
 Plan a solution

 Have you seen similar problems before? Has

a similar problem been solved? If so, are
elements of the solution reusable?
 Is there existing software that implements
the data, functions, and features that are
required? Can subproblems be defined?
 Can you represent a solution in a manner
that leads to effective implementation? Can
a design model be created?
 Carry out the plan

 Is source code traceable to the design

model?
 Is each component part of the solution
provably correct? Have the design and code
been reviewed, or better, have correctness
proofs been applied to the algorithm?
 Examine the result for
accuracy

 Is it possible to test each component part of

the solution? Has a reasonable testing
strategy been implemented?
 Does the solution produce results that
conform to the data, functions, and features
that are required? Has the software been
validated against all stakeholder
requirements?
 SOFTWARE ENGINEERING
PRACTICE

 David Hooker [Hoo96] has proposed seven principles that focus on software
engineering practice as a whole.
 General Principles
1. The Reason It All Exists
-A software system exists for one reason: to provide value to its users . “Does this
add real value to the system?” If the answer is “no,” don’t do it.
2. Keep It Simple, Stupid(KISS)
All design should be as simple as possible, but no simpler. This facilitates having a
more easily understood and easily maintained system. The payoff is software that is
more maintainable and less error-prone.
3. Maintain the Vision
A clear vision is essential to the success of a software project Having an empowered
architect who can hold the vision and enforce compliance helps ensure a very
successful software project.
4. What You Produce, Others Will Consume
Always specify, design, and implement knowing someone else will
have to understand what you are doing
5. Be Open to the Future
system with a long lifetime has more value. systems must be
ready to adapt to these and other changes. Never design yourself
into a corner. Always ask “what if,” and prepare for all possible
answers by creating systems that solve the general problem.
6. Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is
arguably the hardest goal to accomplish in developing a software
system. Planning ahead for reuse reduces the cost and increases
the value of both the reusable components and the systems into
which they are incorporated.
7. Think!
Placing clear, complete thought before action almost always
produces better results. When you think about something, you
are more likely to do it right. You also gain knowledge about how
to do it right again
 Software Myths - erroneous beliefs about software
and the process

Management Myths (Managers with software

responsibility)
i)Myth: We already have a book that's full of standards and
procedures for building software,
Reality: but is it used? Are software practitioners aware of its
existence? Is it complete? Is it adaptable?
ii)Myth: My people have state-of-the-art software development
tools,
Reality: Computer-Aided Software Engineering (CASE) tools are
1
more important than hardware for achieving good quality and
productivity, yet the majority of software developers still do not
 iii)Myth: If we get behind schedule, we can add more
programmers and catch up
Reality: “Adding people to a late software project makes it later”.
However, as new people are added, people who were working
must spend time educating the newcomers. People can be added
but only in a planned and well-coordinated manner.
iv)Myth: If I decide to outsource the software project to a third
party, I can just relax and let that firm build it.
Reality: If an organization does not understand how to manage
and control software projects internally, it will be problematic to
1 build that project.
 Customer’s Myths
i)Myth: A general statement of objectives is sufficient to begin
writing programs, we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed
software efforts. A formal and detailed description of the
information domain, function, behavior, performance, interfaces,
design constraints, and validation criteria is essential which is
determined only after thorough communication between customer
and developer.
ii)Myth: Project requirements continually change, but change can be
easily accommodated because software is flexible.
1Reality: It is true that software requirements change, but the impact
 Practitioner Myths
(Related To Practitioner or Programmer)
i)Myth: Once we write the program and get it to work, our
job is done.
Reality: “ The sooner you begin 'writing code', the longer
it'll take you to get done”.
ii)Myth: The only deliverable work product for a successful
project is the working program.
Reality : A working program is only one part of a software
configuration that includes many elements. Documentation
1
provides a foundation for successful engineering and, more
important, guidance for software support.
 Practitioner Myths
(Related To Practitioner or Programmer)
iii)Myth: Until I get the program “running” I have no way of
assessing its quality.
Reality: One of the most effective software quality assurance
mechanisms can be applied from the inception of a project—the
technical review. Software reviews are a “quality filter
iv)Myth: Software engineering will make us create voluminous
and unnecessary documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is
about creating a quality product. Better quality leads to reduced
1
rework. And reduced rework results in faster delivery times.
 A GENERIC PROCESS
MODEL

A software process
framework
A GENERIC PROCESS
MODEL

Process flow
 A GENERIC PROCESS
MODEL

 A generic process framework for software engineering defines five

framework activities—communication, planning, modeling,
construction, and deployment. In addition, a set of umbrella
activities—project tracking and control, risk management, quality
assurance, configuration management, technical reviews
 Defining a Framework Activity
-What actions are appropriate for a framework activity, given the
nature of the problem to be solved, the characteristics of the
people doing the work, and the stakeholders who are sponsoring
the project?
- action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

 Identifying a Task Set

 Process Patterns A process pattern describes a process-related
problem that is encountered during software engineering work,
identifies the environment in which the problem has been
encountered, and suggests one or more proven solutions to the
problem.
Ambler has proposed a template for describing a process pattern:
 Pattern Name
The pattern is given a meaningful name describing it within the
context of the software process (e.g., TechnicalReviews).
 Forces
The environment in which the pattern is encountered and the issues
that make the problem visible and may affect its solution.
 Type-three types:
1. Stage pattern—defines a problem associated with a framework
activity for the process .
2. Task pattern—defines a problem associated with a software
engineering action or work task and relevant to successful software
engineering practice (e.g., R equirementsGathering is a task
pattern).
 Phase pattern—define the sequence of framework activities that
 PROCESS ASSESSMENT AND IMPROVEMENT
 Standard CMMI Assessment Method for Process
Improvement (SCAMPI)
- provides a five-step process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting, and learning. The
SCAMPI method uses the SEI CMMI as the basis for assessment.
 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.
 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.
 ISO 9001:2000 for Software
- a generic standard that applies to any organization that wants to
improve the overall quality of the products, systems, or services that it
provides
 PRESCRIPTIVE PROCESS
1.
MODELS
The Waterfall Model
 The waterfall model, sometimes called the classic
life cycle, suggests a systematic, sequential
approach to software development that begins with
customer specification of requirements and
progresses through planning, modeling,
construction, and deployment.
 A variation in the representation of the waterfall
model is called the V-model .
 As a software team moves down the left side of the
V, basic problem requirements are refined into
progressively more detailed and technical
representations of the problem and its solution.
 oldest paradigm for software engineering.
 serve as a useful process model in situations where
requirements are fixed and work is to proceed to
completion in a linear manner.
 PRESCRIPTIVE PROCESS
MODELS
2. Incremental Process Models
 The incremental model combines elements of linear and
parallel process flows.
 When an incremental model is used, the first increment is
often a core product. That is, basic requirements are
addressed but many supplementary features (some
known, others unknown) remain undelivered.
 The core product is used by the customer (or undergoes
detailed evaluation). As a result of use and/or evaluation,
a plan is developed for the next increment.
 The plan addresses the modification of the core product
to better meet the needs of the customer and the
delivery of additional features and functionality.
 This process is repeated following the delivery of each
increment, until the complete product is produced.
 focuses on the delivery of an operational product
with each increment.
PRESCRIPTIVE PROCESS
MODELS

3. Evolutionary Process Models

I. Prototyping
 The prototyping paradigm begins with communication.
 You meet with other stakeholders to define the overall
objectives for the software, identify whatever requirements
are known, and outline areas where further definition is
mandatory.
 A prototyping iteration is planned quickly, and modeling (in
the form of a “quick design”) occurs.
 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 output display formats).
 The quick design leads to the construction of a prototype.
 The prototype is deployed and evaluated by stakeholders,
who provide feedback that is used to further refine
requirements .
 prototype serves as a mechanism for identifying
software requirements. If a working prototype is to be
built, you can make use of existing program fragments
or apply tools .
 The prototype can serve as “the first system “
PRESCRIPTIVE PROCESS
MODELS

II. The Spiral Model

 Originally proposed by Barry Boehm, the spiral model is an
evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic
aspects of the waterfall model.
 It provides the potential for rapid development of increasingly
more complete versions of the software.
 risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive
systems.
 It has two main distinguishing features. One is a cyclic approach
for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk .
 Software is developed in a series of evolutionary releases.
During early iterations, the release might be a model or
prototype. During later iterations, increasingly more complete
versions of the engineered system are produced.
 divided into a set of framework activities defined by the
software engineering team.
 The spiral model is a realistic approach to the development of
large-scale systems and software
PRESCRIPTIVE PROCESS
MODELS

4. Concurrent Models
 called concurrent engineering, allows a
software team to represent iterative and
concurrent elements of any of the process
models.
 All software engineering activities exist
concurrently but reside in different states.
 Concurrent modeling defines a series of
events that will trigger transitions from state
to state for each of the software engineering
activities, actions, or tasks .
 Concurrent modeling is applicable to all types
of software development and provides an
accurate picture of the current state of a
project.
 SPECIALIZED PROCESS
MODELS
these models tend to be applied when a specialized or narrowly
defined software engineering approach is chosen.
 Component-Based Development
 Commercial off-the-shelf (COTS) software components,
developed by vendors who offer them as products, provide
targeted functionality with well-defined interfaces that enable the
component to be integrated into the software that is to be built.
 The component-based development model incorporates many of
the characteristics of the spiral model.
 It is evolutionary in nature, demanding an iterative approach to
the creation of software. However, the component-based
development model constructs applications from prepackaged
software components.
 Modeling and construction activities begin with the identification
of candidate components.
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. A software architecture is designed to
accommodate the components.
4. Components are integrated into the
architecture.
5. Comprehensive testing is conducted to
ensure proper functionality.
 leads to software reuse, and reusability
provides software engineers with a number of
measurable benefits.
 The Formal Methods Model
 encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to
specify, develop, and verify a computer-based system by applying
a rigorous, mathematical notation. A variation on this approach,
called cleanroom software engineering
 The development of formal models is currently quite time
consuming and expensive.
• Because few software developers have the necessary background
to apply formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for
technically unsophisticated customers.
 Aspect-Oriented Software Development
 provides a process and methodological approach for defining,
specifying, designing, and constructing aspects—“mechanisms
beyond subroutines and inheritance for localizing the expression of
a crosscutting concern”.
 Common, systemic aspects include user interfaces, collaborative
work, distribution, persistency, memory management, transaction
processing, security, integrity and so on. Components may provide
or require one or more “aspect details” relating to a particular
aspect
 PERSONAL AND TEAM
PROCESS MODELS

Personal Software Process (PSP)

The PSP model defines five framework activities
 Planning
 High-level design
 High-level design review
 Development
 Postmortem
Team Software Process (TSP)
AGILE PROCESS MODELS
 AGILE PROCESS
What Is An Agile Process
Agility Principles
 The Agile Alliance defines agility principles for those
who want to achieve agility:
 Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
 Welcome changing requirements, even late in
development. Agile processes harness change for the
customer’s competitive advantage.
 Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
 Business people and developers must work
together daily throughout the project.
 Build projects around motivated individuals. Give
them the environment and support they need,
and trust them to get the job done.
 The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
 Working software is the primary measure of
progress.
 Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant pace
indefinitely.
 Continuous attention to technical excellence and
good design enhances agility.
•The best architectures, requirements, and designs
emerge from self– organizing teams.
At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
 The Politics of Agile Development
 Human Factors
- Agile development focuses on the talents and skills of individuals,
molding the process to specific people and teams
 Competence.
- Skill and knowledge of process can and should be taught to all
people who serve as agile team members.
 Common focus
- focused on one goal
- the team will also focus on continual adaptations (small and large)
 Collaboration.
- team members must collaborate—with one another and all other
stakeholders.
 Self-organization
(1)the agile team organizes itself for the work to be done,
(2)the team organizes the process to best accommodate its
local environment.
(3)the team organizes the work schedule to best achieve
delivery of the software increment.
 Decision-making ability.
- team is given autonomy—decision-making authority for both
technical and project issues.
 Fuzzy problem-solving ability
- team must accept the fact that the problem they are solving
today may not be the problem that needs to be solved
tomorrow.
 Mutual trust and respect
EXTREME PROGRAMMING
XP Values (XP)
- communication, simplicity, feedback, courage, and respect. Each of
these values is used as a driver for specific XP activities, actions, and
tasks
The XP Process
 Planning
-begins with listening—a requirements gathering activity that enables
the technical members of the XP team to understand the business
context .
- creation of a set of “stories” (also called user stories) that describe
required output, features, and functionality for software to be built.
Each story is written by the customer and is placed on an index card.
- assign a cost—measured in development weeks—to it.
 Design
 Coding
 Testing
Industrial XP
-IXP is an organic evolution of XP.
- customer-centric, test-driven spirit.
- IXP differs most from the original XP in its greater inclusion
of management, its expanded role for customers, and its
upgraded technical practices.
 Readiness assessment
(1) an appropriate development environment exists to support
IXP, (2) the team will be populated by the proper set of
stakeholders, (3) the organization has a distinct quality
program and supports continuous improvement, (4) the
organizational culture will support the new values of an
agile team, and (5) the broader project community will be
populated appropriately.
 Project community
- people on the team must be well-trained, adaptable and
skilled, and have the proper temperament to contribute to a
self-organizing team
 Project chartering
- examines the context of the project to determine how it
complements, extends, or replaces existing systems or
processes
 Test-driven management
- requires measurable criteria for assessing the state of the
project and the progress
 Retrospectives
-IXP team conducts a specialized technical review after a
software increment is delivered. Called a retrospective
 Continuous learn
- XP team are encouraged (and possibly, incented) to learn new
methods and techniques that can lead to a higher quality
product.
 The XP Debate