SOFTWARE ENGINEERING

AND PROJECT
MANAGEMENT

Module 1
INTRODUCTION
 What is it? Computer software is the product that
software professionals build and then support over the
long term.
 Software engineering encompasses a process, a collection
of methods (practice) and an array of tools that allow
professionals to build high quality computer software.
 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.
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.
 As a product, it delivers the computing potential embodied
by computer hardware or more broadly, by a network of
computers that are accessible by local hardware.
 Whether it resides within a mobile phone or operates inside
a mainframe computer, software is an information
transformer—producing, managing, acquiring, modifying,
displaying, or transmitting information that can be as
simple as a single bit or as complex as a multimedia
presentation derived from data acquired from dozens of
independent sources.
 As the vehicle used to deliver the product, software acts as
the basis for the control of the computer (operating
systems) the communication of information (networks), and
the creation and control of other programs (software tools
and environments).
 NATURE OF SOFTWARE
 Software delivers the most important product of our time—
information. It transforms personal data (e.g., an individual’s
financial transactions) so that the data can be more useful in a local
context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information
networks (e.g., the Internet), and provides the means for acquiring
information in all of its forms.
 Today, a huge software industry has become a dominant factor in
the economies of the industrialized world.
 And yet, the questions that were asked of the lone programmer are
the same questions that are asked when modern computer-based
 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?
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 adequately manipulate information, and (3)
descriptive information in both hard copy and virtual
forms that describes the operation and use of the
programs.
CHARACTERISTICS OF SOFTWARE.
 1. Software is developed or engineered; it is not
manufactured in the classical sense.
 2. Software doesn’t “wear out.”

 3. Although the industry is moving toward

component-based construction, most software

continues to be custom built.
 SOFTWARE APPLICATION DOMAINS
 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.
 In either case, the systems software area is characterized by
heavy interaction with computer hardware; heavy usage by
multiple users; concurrent operation that requires scheduling,
resource sharing, and sophisticated process management;
complex data structures; and multiple external interfaces.
 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.
 In addition to conventional data processing applications,
application software is used to control business functions in real
time.
SOFTWARE APPLICATION DOMAINS
 Engineering/scientific software—has been
characterized by “number crunching” algorithms.
 Modern applications within the engineering/scientific area
are moving away from conventional numerical algorithms.
 Embedded 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.
 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) or address mass
consumer markets (e.g., word processing, spreadsheets,
computer graphics, multimedia, entertainment, database
management, and personal and business financial
applications).
SOFTWARE APPLICATION DOMAINS
 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 non
numerical algorithms to solve complex problems that are
not amenable to computation or straightforward analysis.
Applications within this area include robotics, expert
systems, pattern recognition (image and voice), artificial
neural networks, theorem proving, and game playing.
LEGACY SOFTWARE
 Legacy software systems . . . were developed decades ago and
have been continually modified to meet changes in business
requirements and computing platforms. The proliferation of
such systems is causing headaches for large organizations
who find them costly to maintain and risky to evolve.
 If the legacy software meets the needs of its users and runs
reliably, it isn’t broken and does not need to be fixed.
However, as time passes, legacy systems often evolve for one
or more of the following reasons:
 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 viable within a
network environment.
THE UNIQUE NATURE 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.
 Unpredictable load. The number of users of the
WebApp may vary by orders of magnitude from day to
day. One hundred users may show up on Monday; 10,000
may use the system on Thursday.
 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.
THE UNIQUE NATURE OF WEBAPPS
 Availability. Although expectation of 100 percent
availability is unreasonable, users of popular WebApps
often demand access on a 24/7/365 basis. Users in
Australia or Asia might demand access during times when
traditional domestic software applications in North
America might be taken off-line for maintenance.
 Data driven. The primary function of many WebApps is
to use hypermedia to present text, graphics, audio, and
video content to the end user.
 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.
THE UNIQUE NATURE OF WEBAPPS
 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, if not impossible, to limit the
population of end users who may access the application.
 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.
SOFTWARE ENGINEERING
 In order to build software that is ready to meet the
challenges of the twenty-first century, you must recognize
a few simple realities:
 Software has become deeply embedded in virtually every
aspect of our lives, and as a consequence, the number of
people who have an interest in the features and functions
provided by a specific application has grown dramatically.
It follows that a concerted effort should be made to
understand the problem before a software solution is
developed.
 The information technology requirements demanded by
individuals, businesses, and governments grow increasing
complex with each passing year. It follows that design
becomes a pivotal activity.
 Individuals, businesses, and governments increasingly
rely on software for strategic and tactical decision making
as well as day-to-day operations and control. It follows
that software should exhibit high quality.
SOFTWARE ENGINEERING
 As the perceived value of a specific application grows,
the likelihood is that its user base and longevity will also
grow. As its user base and time-in-use increase, demands
for adaptation and enhancement will also grow. It follows
that software should be maintainable.
 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.
SOFTWARE ENGINEERING LAYERS
 The foundation for software engineering is the process
layer. The software engineering process is the glue that
holds the technology layers together and enables rational
and timely development of computer software.
 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.
SOFTWARE ENGINEERING PRACTICE
 Generic framework activities—communication, planning,
modeling, construction, and deployment—and umbrella
activities establish a skeleton architecture for software
engineering work.
The Essence of Presence
 the essence of software engineering practice:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality
assurance).
 In the context of software engineering, these commonsense
steps lead to a series of essential questions:
 Understand the problem.
 Plan the solution.
 Carry out the plan.
SOFTWARE ENGINEERING PRACTICE
 Examine the result.

 General Principles
 The First Principle: The Reason It All Exists
 The Second Principle: (Keep It Simple, Stupid!)
 The Third Principle: Maintain the Vision
 The Fourth Principle: What You Produce, Others
Will Consume
 The Fifth Principle: Be Open to the Future
 The Sixth Principle: Plan Ahead for Reuse
 The Seventh principle: Think!
SOFTWARE MYTHS
 Software myths—erroneous beliefs about software and
the process that is used to build it—can be traced to the
earliest days of computing.
 Myths have a number of attributes that make them
insidious.

 Management myths.
 Customer myths.
 Practitioner’s myths.
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, and others
—are applied throughout the process.
 This aspect—called process flow—describes how the
framework activities and the actions and tasks that occur
within each framework activity are organized with respect
to sequence and time.
 A linear process flow executes each of the five framework
activities in sequence, beginning with communication and
culminating with deployment.
 An iterative process flow repeats one or more of the
activities before proceeding to the next
A GENERIC PROCESS MODEL
 An evolutionary process flow executes the activities in a
“circular” manner. Each circuit through the five activities
leads to a more complete version of the software.
 A parallel process flow executes one or more activities in
parallel with other activities.
 A PROCESS FRAMEWORK
 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?
 For a small software project requested by one person (at a
remote location) with simple, straightforward requirements,
the communication activity might encompass little more than
a phone call with the appropriate stakeholder.
 Therefore, the only necessary action is phone conversation,
and the work tasks (the task set) that this 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.
PROCESS PATTERNS
 Every software team encounters problems as it moves
through the software process.
 It would be useful if proven solutions to these problems
were readily available to the team so that the problems
could be addressed and resolved quickly.
 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.
 Pattern Name. The pattern is given a meaningful name
describing it within the context of the software process
(e.g., Technical Reviews).
 Forces. The environment in which the pattern is
encountered and the issues that make the problem visible
and may affect its solution.
PROCESS PATTERNS
 Type. The pattern type is specified. Ambler [Amb98]
suggests three types:
 1. Stage pattern—defines a problem associated with a
framework activity for the process. Since a framework
activity encompasses multiple actions and work tasks, a
stage pattern incorporates multiple task patterns that are
relevant to the stage.
 2. Task pattern—defines a problem associated with a
software engineering action or work task and relevant to
successful software engineering practice (e.g.,
Requirements Gathering is a task pattern).
 3. Phase pattern—define the sequence of framework
activities that occurs within the process, even when the
overall flow of activities is iterative in nature. An example
of a phase pattern might be Spiral Model or
Prototyping.
PROCESS PATTERNS
 Initial context. Describes the conditions under which the
pattern applies. Prior to the initiation of the pattern: (1) What
organizational or team-related activities have already
occurred? (2) What is the entry state for the process? (3)
What software engineering information or project information
already exists?
 Problem. The specific problem to be solved by the pattern.
 Solution. Describes how to implement the pattern
successfully. It also describes how software engineering
information or project information that is available before the
initiation of the pattern is transformed as a consequence of
the successful execution of the pattern.
 Resulting Context. Describes the conditions that will result
once the pattern has been successfully implemented. Upon
completion of the pattern: (1) What organizational or team-
related activities must have occurred? (2) What is the exit
state for the process? (3) What software engineering
information or project information has been developed?
PROCESS PATTERNS
 Related Patterns. Provide a list of all process patterns
that are directly related to this one. This may be
represented as a hierarchy or in some other diagrammatic
form. For example, the stage pattern Communication
encompasses the task patterns: ProjectTeam,
CollaborativeGuidelines, ScopeIsolation,
RequirementsGathering, ConstraintDescription, and
ScenarioCreation.
 Known Uses and Examples. Indicate the specific
instances in which the pattern is applicable. For example,
Communication is mandatory at the beginning of every
software project, is recommended throughout the software
project, and I mandatory once the deployment activity is
under way.
 Process patterns provide an effective mechanism for
addressing problems associated with any software
process.
 PROCESS ASSESSMENT AND
IMPROVEMENT
 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 (SCAMPI)—provides a five-step process
assessment model that incorporates five phases: initiating,
diagnosing, establishing, acting, and learning.
 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. Therefore, the
standard is directly applicable to software organizations and
companies
PRESCRIPTIVE PROCESS MODEL

 Prescriptive process models were originally proposed to

bring order to the chaos of software development.
 History has indicated that these traditional models have
brought a certain amount of useful structure to software
engineering work and have provided a reasonably
effective road map for software teams.
THE WATERFALL MODEL
 There are times when the requirements for a problem are
well understood—when work flows from communication
through deployment in a reasonably linear fashion.
 The waterfall model, sometimes called the classic life
cycle, suggests a systematic, sequential approach6 to
software development that begins with customer
specification of requirements and progresses through
planning, modeling, construction, and deployment,
culminating in ongoing support of the completed
software.
THE WATERFALL MODEL
 A variation in the representation of the waterfall model is
called the V-model.
THE WATERFALL 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.
 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 validate each of the
models created as the team moved down the left side.
 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 verification and validation actions
are applied to earlier engineering work.
 The waterfall model is the oldest paradigm for software
engineering. However, over the past three decades,
criticism of this process model has caused even ardent
supporters to question its efficacy.
LIMITATIONS OF WATERFALL MODEL
1. Real projects rarely follow the sequential flow that the
model proposes. As a result, changes can cause confusion
as the project team proceeds.
2. It is often difficult for the customer to state all
requirements explicitly. The waterfall model requires this
and has difficulty accommodating the natural uncertainty
that exists at the beginning of many projects.
3. The customer must have patience. A working version of
the program(s) will not be available until late in the project
time span. A major blunder, if undetected until the working
program is reviewed, can be disastrous.
 INCREMENTAL PROCESS MODEL
 The incremental model combines elements of linear and
parallel process flows.
 Each linear sequence produces deliverable “increments” of
the software in a manner that is similar to the increments
produced by an evolutionary process flow.
 For example, word-processing software developed using the
incremental paradigm might deliver basic file management,
editing, and document production functions in the first
increment; more sophisticated editing and document
production capabilities in the second increment; spelling and
grammar checking in the third increment; and advanced
page layout capability in the fourth increment.
 The incremental process model focuses on the delivery of an
operational product with each increment.
 Incremental development is particularly useful when staffing
is unavailable for a complete implementation by the business
deadline that has been established for the project.
INCREMENTAL PROCESS MODEL

o Early increments can be implemented with fewer people. If the

core product is well received, then additional staff (if required) can
be added to implement the next increment.
o In addition, increments can be planned to manage technical risks
EVOLUTIONARY PROCESS MODEL
 Business and product requirements often change as
development proceeds, making a straight line path to an
end product unrealistic; tight market deadlines make
completion of a comprehensive software product
impossible, but a limited version must be introduced to
meet competitive or business pressure; a set of core
product or system requirements is well understood, but the
details of product or system extensions have yet to be
defined.
 In these and similar situations, you need a process model
that has been explicitly designed to accommodate a
product that evolves over time.
 Two Types :-
 The Prototyping
 Spiral Model
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.
 The prototype is deployed and evaluated by stakeholders,
who provide feedback that is used to further refine
requirements.
 PROTOTYPING
 A quick design focuses on a representation of those aspects of the
software that will be visible to end users.
 The quick design leads to the construction of a prototype.
 Ideally, the prototype serves as a mechanism for identifying
software requirements.
 prototyping can be problematic for the following reasons:
 Stakeholders see what appears to be a working version of the
software, unaware that the prototype is held together
haphazardly, unaware that in the rush to get it working you
haven’t considered overall software quality or long-term
maintainability.
 As a software engineer, you often make implementation
compromises in order to get a prototype working quickly. An
inappropriate operating system or programming language may be
used simply because it is available and known; an inefficient
algorithm may be implemented simply to demonstrate capability.
After a time, you may become comfortable with these choices and
forget all the reasons why they were inappropriate.
SPIRAL MODEL
 Originally proposed by Barry Boehm [Boe88], 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.
 During early iterations, the release might be a model or
prototype.
 During later iterations, increasingly more complete
versions of the engineered system are produced.
 A spiral model is divided into a set of framework activities
defined by the software engineering team.
 the software team performs activities that are implied by a
circuit around the spiral in a clockwise direction, beginning
at the center.
SPIRAL MODEL
 The first circuit around the spiral might result in the
development of a product specification; subsequent
passes around the spiral might be used to develop a
prototype and then progressively more sophisticated
versions of the software.
 CONCURRENT MODELS
 The concurrent development model, sometimes called
concurrent engineering, allows a software team to represent
iterative and concurrent elements of any of the process
models.
 early in a project the communication activity has completed its
first iteration and exists in the awaiting changes state.
 The modeling activity which existed in the inactive state while
initial communication was completed, now makes a transition
into the under development state.
 customer indicates that changes in requirements must be
made, the modeling activity moves from the under
development state into the awaiting changes state.
 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.
CONCURRENT MODELS
SPECIALIZED PROCESS MODELS
 Specialized process models take on many of the
characteristics of one or more of the traditional models
 Component-Based Development
 The Formal Methods Model
 Aspect-Oriented Software Development
COMPONENT-BASED
DEVELOPMENT
 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.
 Modeling and construction activities begin with the
identification of candidate components.
 These components can be designed as either conventional
software modules or object-oriented classes or packages of
classes.
 Regardless of the technology that is used to create the
components, the component-based development model
incorporates the following steps
 1. Available component-based products are researched and
evaluated for the application domain in question.
 2. Component integration issues are considered.
COMPONENT-BASED DEVELOPMENT
 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.
 THE FORMAL METHODS MODEL
 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.
 When formal methods are used during development, they
provide a mechanism for eliminating many of the problems that
are difficult to overcome using other software engineering
paradigms.
 Ambiguity, incompleteness, and inconsistency can be discovered
and corrected more easily—not through ad hoc review, but
through the application of mathematical analysis.
 When formal methods are used during design, they serve as a
basis for program verification and therefore enable you to
discover and correct errors that might otherwise go undetected.
 Although not a mainstream approach, the formal methods model
offers the promise of defect-free software.
THE FORMAL METHODS MODEL
 Yet, concern about its applicability in a business
environment has been voiced:
 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
 Aspect-oriented software development (AOSD), often
referred to as aspect-oriented programming (AOP), is a
relatively new software engineering paradigm that
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”
 However, it is likely that such a process will adopt
characteristics of both evolutionary and concurrent
process models.
 The evolutionary model is appropriate as aspects are
identified and then constructed.
 The parallel nature of concurrent development is essential
because aspects are engineered independently of
localized software components and yet, aspects have a
direct impact on these components.