21CS61 : SOFTWARE

ENGINEERING &
PROJECT
MANAGEMENT
 2

REFERENCE 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.
 3

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, How it all starts
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 1:

SOFTWARE AND
SOFTWARE
ENGINEERING
 5

WHAT IS A 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.
Software is a collection of executable program codes, associated
libraries and documentation
CHARACTERISTICS OF
6
SOFTWARE
• Software is developed or engineered; it is not manufactured
• Software doesn’t “wear out.”
• Although the industry is moving toward component-based
construction, most software continues to be custom built.

Software engineering methods strive to reduce the magnitude

of the spikes and the slope of the actual curve
SOFTWARE APPLICATION DOMAINS

• System software—a collection of programs written to

service other programs.
• Application software—stand-alone programs that
solve a specific business need.
• Engineering/scientific software
• 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
• Web applications—called “WebApps,” this
network-centric software
• Artificial intelligence software—makes use of
nonnumerical algorithms to solve complex problems
that are not amenable to computation or
straightforward analysis
 8

CHALLENGES IN SOFTWARE
ENGINEERING
• Open-world computing: to develop systems and application software
that will allow mobile devices, personal computers, and enterprise
systems communicate across vast networks.
• Netsourcing: to architect simple (e.g., personal financial planning) and
sophisticated applications that provide a benefit to targeted end-user
markets worldwide.
• Open source: to build source code that is self-descriptive and to develop
techniques that will enable both customers and developers to know what
changes have been made and how those changes manifest themselves
within the software.
 9

LEGACY SOFTWARE
• Dayani et al: Legacy software systems were
developed decades ago and have been continually
modified to meet changes in business requirements
and computing platforms.
• Liu et al: “many legacy systems remain supportive to
core business functions and are ‘indispensable’ to the
business.”
• Characteristics:-
* longevity
* business criticality.
* poor quality
 10
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 viable
within a network environment.
THE UNIQUE NATURE OF WEBAPPS
• Not only provide stand-alone function to the end user, but also have 11
been integrated with corporate databases and business applications.
Attributes of WebApps
• Network ……
intensiveness.
• Content sensitive.
• Concurrency.
• Continuous
• Unpredictable load. evolution.
• Performance. • Immediacy.
• Availability.
• Security.
• Data driven.
• Aesthetics.
 12
SOFTWARE
ENGINEERING
•Understand the problem before you build a solution
•Design is a pivotal software engineering activity
•Software should exhibit high quality
•Software should be maintainable

IEEE Definition: The application of a systematic,

disciplined, quantifiable approach to the development,
operation and maintenance of software, that is the
application of engineering to software.
 13

SOFTWARE ENGINEERING-
A LAYERED TECHNOLOGY
•Quality Focus: Bedrock that
supports software engineering
•Process : -Glue that holds the
technology layers together
-Framework for effective
delivery of software engineering
technology
•Methods:- How-to?
•Tools:- provide
automated/semi-automated
support for process and methods
 14

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 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 a unit
test) that produces a tangible outcome.
 15
FIVE GENERIC PROCESS FRAMEWORK
ACTIVITIES

Communication: to understand stakeholders’ objectives for the

project and to gather requirements
Planning :defines the software engineering work by describing the technical
tasks to be conducted, the risks that are likely, the resources that will be required,
the work products to be produced, and a work schedule.
Modeling: to better understand software requirements and the design that will
achieve those requirements.
Construction: combines code generation and testing
Deployment: The software is delivered to the customer

Above activities are applied repeatedly through a number of project iterations.

Each project iteration produces a software increment.
UMBRELLA ACTIVITIES 16
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.
Software quality assurance—defines and conducts the activities required to ensure software
quality.
Technical reviews—assesses software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs; can be used in conjunction with all
other framework and umbrella activities.
Software configuration management—manages the effects of change throughout the
software process.
Reusability management—defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
Work product preparation and production—encompasses the activities
required to create work products such as models, documents, logs, forms,
and lists.
 17

HOW DO PROCESS MODELS

DIFFER FROM ONE ANOTHER?
•Overall flow of activities, actions, and tasks and the interdependencies among them
• Degree to which actions and tasks are defined within each framework activity
• Degree to which work products are identified and required
•Manner in which quality assurance activities are applied
• Manner in which project tracking and control activities are applied
• Overall degree of detail and rigor with which the process is described
• Degree to which the customer and other stakeholders are involved with the
project
• Level of autonomy given to the software team
• Degree to which team organization and roles are prescribed
 18

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).

 1. UNDERSTAND THE 19

PROBLEM
• Who has a stake in the solution to the problem? That is, 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?
2. PLAN THE SOLUTION 20

• Have you seen similar problems before?

Are there patterns that are recognizable in a potential solution? Is there existing
software that implements the data, functions, and features that are required?
• Has a similar problem been solved?
If so, are elements of the solution reusable?
• Can subproblems be defined?
If so, are solutions readily apparent for the subproblems?
• Can you represent a solution in a manner that leads to effective
implementation?
Can a design model be created?
 21

3. CARRY OUT THE PLAN

• Does the solution conform to 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?
 22

4. EXAMINE THE RESULT.

• Is it possible to test each component part of the solution?

• Has a reasonable testing strategy been implemented?

• Has the software been validated against all stakeholder requirements?

 GENERAL PRINCIPLES ON SE 23

PRACTICES (PROPOSED BY
DAVID HOOKER)
• The First Principle: The Reason It All Exists - to provide value to its users
• The Second Principle: Keep It Simple
• The Third Principle: Maintain the Vision
• The Fourth Principle: What You Produce, Others Will Consume - someone else
will have to understand what you are doing
• The Fifth Principle: Be Open to the Future
• The Sixth Principle: Plan Ahead for Reuse
• The Seventh principle: Think!
SOFTWARE MYTHS 24
—erroneous beliefs about software and the process that is used to build it

• Management myths
• Customer myths.
• Practitioner’s myths.
 25
MANAGEMENT MYTHS
• Myth 1: We already have a book that’s full of standards and
procedures for building software. Won’t that provide my people
with everything they need to know?

• Myth 2: If we get behind schedule, we can add more programmers

and catch up (sometimes called the “Mongolian horde” concept).

• Myth 3: If I decide to outsource the software project to a third

party, I can just relax and let that firm build it.
 26

CUSTOMER MYTHS
• Myth 1: A general statement of objectives is sufficient to
begin writing programs—we can fill in the details later.

• Myth 2: Software requirements continually change, but

change can be easily accommodated because software is
flexible.
 27
PRACTITIONER’S MYTHS

• Myth 1: Once we write the program and get it to work, our job is done. (60 to 80
percent of all effort expended on software will be expended after it is delivered to the
customer for the first time.)

• Myth 2: Until I get the program “running” I have no way of assessing its quality(the
technical review)

• Myth 3: The only deliverable work product for a successful project is the working
program ((e.g., models, documents, plans)

• Myth 4: Software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down.(Better quality leads to reduced
rework. And reduced rework results in faster delivery times.)
 28

PROCESS MODELS
• A process is defined as a collection of work activities, actions, and tasks that are
performed when some work product is to be created.
• Each framework activity is populated by a set of software engineering actions.
• Each software engineering action is defined by a task set that identifies the work
tasks that are to be completed, the work products that will be produced, the
quality assurance points that will be required, and the milestones that will be
used to indicate progress.

Process Flow—describes how the frame work activities and the actions
and tasks that occur within each framework activity are organized with respect
to sequence and time
29
 30

PROCESS FLOW
• Linear Process Flow
• Iterative Process Flow
• Evolutionary Process Flow
• Parallel Process Flow
 31
• 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
 32

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 (e.g.,
modeling for one aspect of the software might
be executed in parallel with construction of
another aspect of the software)
 33

1. DEFINING A FRAMEWORK
ACTIVITY
• 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.
 34

2. IDENTIFYING A TASK SET

• A task set defines the actual work to be done to accomplish the objectives of a
software engineering action.
TASK SET FOR REQUIREMENT GATHERING FOR SMALL PROJECT
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
 TASK SET FOR REQUIREMENT GATHERING FOR BIG PROJECT
35
1. Make a list of stakeholders for the project.
2. Interview each stakeholder separately to determine overall wants and needs.
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the system.
12. Discuss methods for validating the system.
 3. PROCESS PATTERNS 36

• 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.

• A pattern might be used to describe a problem (and solution) associated with a

complete process model (e.g., prototyping).

• Patterns can be used to describe a problem (and solution) associated with a framework
activity (e.g., planning) or

• Pattern can be an action within a framework activity (e.g., project estimating).

A pattern template provides a consistent means for describing a pattern.

TEMPLATE FOR DESCRIBING 37
A PROCESS PATTERN
• Proposed by Ambler
• 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.
 38

PATTERN TYPE
1. Stage pattern —defines a problem associated with a framework activity for the
process. A stage pattern incorporates multiple task patterns that are relevant to the
stage (framework activity).
An example of a stage pattern might be EstablishingCommunication. This pattern
would incorporate the task pattern RequirementsGathering and others.
2. Task pattern —defines a problem associated with a software engineering action or
work task and relevant to successful software engineering practice (e.g.,
RequirementsGathering 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 SpiralModel or Prototyping.
 39

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?

For example, the Planning pattern (a stage pattern) requires that

(1) Customers and software engineers have established a collaborative communication;
(2) successful completion of a number of task patterns [specified] for
the Communication pattern has occurred; and
(3) the project scope, basic business requirements, and project constraints are known.
 40
PROBLEM.
The specific problem to be solved by the pattern

SOLUTION.
• Describes how to implement the pattern successfully.
• Describes how the initial state of the process (that exists before the pattern is
implemented) is modified as a consequence of the initiation of the pattern.
• 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. 41

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?

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.
 42

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 is
mandatory once the deployment activity is under way.
43
PROCESS ASSESSMENT AND 44

IMPROVEMENT
Assessment attempts to understand the current state of the software
process with the intent of improving it.
• 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.
 45
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 46
MODELS
• Prescriptive process models were originally proposed to bring order to the chaos
of software development

• They prescribe a set of process elements—framework activities, software

engineering actions, tasks, work products, quality assurance, and change control
mechanisms for each project.

• Each process model also prescribes a process flow (also called a work
flow)—that is, the manner in which the process elements are interrelated to one
another.
 47

PRESCRIPTIVE
PROCESS
MODELS

LINEAR INCREMENTAL EVOLUTIONAR

CONCURRENT
PROCESS PROCESS Y PROCESS
MODEL
MODEL MODEL MODEL

WATERFALL
PROTOTYPING
MODEL

V MODEL SPIRAL MODEL

 48

I)LINEAR PROCESS MODEL

1.1) WATERFALL MODEL

Work flows from communication through deployment in a reasonably linear fashion.

 49

LIMITATIONS OF WATERFALL
MODEL
• Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly. As a
result, changes can cause confusion as the project team proceeds.
• 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.
• 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
 50

1.2)V MODEL

The V-model
illustrates
how verification
and
validation
actions are
associated with
earlier
engineering
actions.
 51

II) INCREMENTAL PROCESS

MODEL
• A process model that is designed to produce the software in increments.
• Combines elements of linear and parallel process flows.
• Applies linear sequences in a staggered fashion as calendar time progresses.
• Each linear sequence produces deliverable “increments” of the software in a
manner that is similar to the increments produced by an evolutionary process
flow.
• Eg: Development of word processing software with each increment of modified
version
• First increment is often a core product. That is, basic requirements are addressed
but many supplementary features remain undelivered.
 52

INCREMENTAL PROCESS
MODEL
III) EVOLUTIONARY PROCESS 53

MODEL
3.1) PROTOTYPING
• When your customer has a legitimate need, but is clueless about the details, develop a
prototype as a first step.
• A quick design focuses on a representation of those aspects of the software that
will be visible to end users
 54
PROTOTYPING PARADIGM
 55

PROTOTYPING
• Define the rules of the game at the beginning
• i.e, All stakeholders should agree that the prototype is built
to serve as a mechanism for defining requirements.
• It is then discarded (at least in part), and the actual software
is engineered with an eye toward quality.
LIMITATIONS OF PROTOTYPING 56

1. 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.

2. 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. The less-than-ideal
choice has now become an integral part of the system.
 57

3.2) SPIRAL MODEL.

• Couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model
• A risk-driven process model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems
• Features:-
i) a cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
ii) a set of anchor point milestones for ensuring stakeholder commitment to feasible
and mutually satisfactory system solutions.

(milestones—a combination of work products and conditions that are attained along the
path of the spiral)
 58

SPIRAL MODEL.
 59

IV) CONCURRENT MODEL

• The concurrent model is often more appropriate for product engineering
projects where different engineering teams are involved.
• Each activity, action, or task on the network exists simultaneously with other
activities, actions, or tasks.
60
 61

SPECIALIZED PROCESS
MODELS
• Specialized process models take on many of the characteristics of one or more of
the traditional models

I. Component-Based Development
II. Formal methods model
III. Aspect-Oriented Software Development
 62

COMPONENT-BASED
DEVELOPMENT
• Integrate Commercial off-the shelf (COTS) software components.
• Eg of COTS: payment gateway
• Constructs applications from prepackaged software components

• Begins with the identification of candidate components.

• Candidate components can be designed as either conventional software

modules or object-oriented classes or packages of classes.
 COMPONENT-BASED 63

DEVELOPMENT
–STEPS INVOLVED
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.
 64

FORMAL METHODS MODEL

• Encompasses a set of activities that leads to formal mathematical specification of
computer software.
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected
more easily through the application of mathematical analysis
• Clean Room Engineering is a variation of formal methods model
 65

LIMITATIONS OF FORMAL
METHODS MODEL
• 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.
 66

ASPECT-ORIENTED
SOFTWARE DEVELOPMENT
• Aspectual requirements define those crosscutting concerns that have an impact
across the software architecture.
• Provides a methodological approach for defining, specifying, designing and
constructing aspect
• Eg of aspects: security, memory requirement etc
CASE STUDY I-THE DEFECT 67

MANAGEMENT PROCESS AT
VAULT
• The amount of customers impacted by bugs in their document
management system has risen, according to Vault, a software
development firm. Currently, their main method for receiving problem
reports from clients is via email. Vault intends to replicate its defect
management procedure, which entails problem reporting, classification,
job assignment, and follow-up, in order to address this problem. Vault
can increase customer satisfaction and optimise their defect management
process by employing a more complex and perhaps automated solution.
CASE STUDY 2 — SOFTWARE 68

DEVELOPMENT AT SERENE
AEROSPACE SYSTEMS
• Building sophisticated data transmission and storage systems for
spacecraft is Serene Aerospace Systems’ area of expertise. The
sophisticated and multi-step development techniques used by Serene are
necessary to meet the systems’ complexity and reliability requirements.
Finding sufficient competent personnel for each project has grown to be
difficult as a result of the company’s expansion. Serene intends to
address this issue by modelling its development procedures to make
them more approachable for project managers and developers with less
experience. This will guarantee their software development initiatives’
efficiency and consistency.
 69

CASE STUDY 3 — SOFTWARE

CUSTOMIZATION AT FOSTER
• Enterprise Resource Planning (ERP) system customization is the main
emphasis of Foster Inc. for small and medium-sized businesses. Foster
has successfully customised its system for over 250 customers using a
faster customisation approach. However, Foster intends to launch a
modelling effort to further optimise this procedure. Foster aspires to
maximise product quality and project predictability through the
explanation of their customised process, ensuring customer pleasure.
CASE STUDY 4 — SOFTWARE 70

CONSULTANCY OF
MILLENNIUM
• An IT consulting company called Millennium Pvt Ltd advises regional
businesses on how to solve business difficulties using the right software. The
advising department frequently suggests system changes to current clients, while
the maintenance department is separate from it. Millennium intends to model
their procedure in order to optimise this revenue-generating activity. They will
be able to collect client IT status updates in a fast and correct manner as a result,
which will improve their proposals for system changes
CASE STUDY 5 — ONLINE 71

BANKING OPTION FOR RURAL

INTERNET BANK (RIB)
• For non-technical rural bank customers, Rural Internet Bank (RIB)
specialises in developing useful banking platforms. RIB receives
around 1000 unique requirements each month since their apps require
localization and customization. Due to a lack of experienced staff,
however, their requirement engineering process finds it difficult to match
up with quality assurance criteria. RIB intends to model their
requirements management procedures in order to address this. Interns
will be more easily hired into UX/UI and BA/QA roles as a result, which
will enhance the way they handle requirements and the overall quality of
the system.