UNIT - 1

21CSC303J- Software Engineering Project Management

Even 2024-25

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by
Roger Pressman.
SOFTWARE ENGINEERING

• Some realities:
• to understand the problem before a software solution is developed
• design becomes a essential activity
• software should exhibit high quality
• software should be maintainable

2
SOFTWARE ENGINEERING

• The IEEE definition:

• Software Engineering: The application of a systematic, disciplined,
quantifiable approach to the development, operation, and
maintenance of software

3
 THE EVOLVING ROLE OF
SOFTWARE
● 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, a network of computers that are
accessible by local hardware
● 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)

4
Changing Nature of Software

1.System software: Infrastructure software come under this category

like compilers, operating systems, editors, drivers, etc. Basically
system software is a collection of programs to provide service to
other programs.
2. Real time software: These software are used to monitor, control
and analyze real world events as they occur. An example may be
software required for weather forecasting. Such software will gather
and process the status of temperature, humidity and other
environmental parameters to forcast the weather.

5
 Changing Nature of Software

3. Embedded software: This type of software is placed in “Read-Only- Memory

(ROM)”of the product and control the various functions of the product. The
product could be an aircraft, automobile, security system, signalling system,
control unit of power plants, etc. The embedded software handles hardware
components and is also termed as intelligent software .
4. Business software : This is the largest application area. The software designed
to process business applications is called business software. Business software
could be payroll, file monitoring system, employee management, account
management. It may also be a data warehousing tool which helps us to take
decisions based on available data. Management information system, enterprise
resource planning (ERP) and such other software are popular examples of
business software

6
 Changing Nature of Software

5. Personal computer software :The software used in personal computers are

covered in this category. Examples are word processors, computer graphics,
multimedia and animating tools, database management, computer games etc.
This is a very upcoming area and many big organisations are concentrating their
effort here due to large customer base.
6. Artificial intelligence software: Artificial Intelligence software makes use of
non numerical algorithms to solve complex problems that are not amenable to
computation or straight forward analysis. Examples are expert systems,
artificial neural network,signal processing software etc.

7
Changing Nature of Software

8. Web based software: The software related to web applications

come under this category. Examples are CGI, HTML, Java, Perl,
DHTML etc.

8
A LAYERED TECHNOLOGY

tools

methods

process model

a “quality” focus

Software Engineering
9
• 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
• Software engineering methods provide the technical
how-to’s for building software.

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

11
THE ESSENCE OF PRACTICE

• Polya suggests:
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).

12
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?

13
PLAN THE SOLUTION

• Have you seen similar problems before? Are there patterns that
are familiar 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?
14
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?
Has the design and code been reviewed, or better?

15
EXAMINE THE RESULT

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

16
HOW IT ALL STARTS

• SafeHome:
• Every software project is precipitated by some business need—
• the need to correct a defect in an existing application;
• the need to the need to adapt a ‘legacy system’ to a
changing business environment;
• the need to extend the functions and features of an
existing application, or
• the need to create a new product, service, or system.

17
Process Models

18
 WHAT / WHO / WHY IS PROCESS
MODELS?

• What: a series of predictable steps--- a road map that helps you create a timely, high-quality
results.
• Who: Software engineers and their managers, clients also
• Why: Provides stability, control, and organization to an activity that can if left uncontrolled,
become quite chaotic.
• What Work products: Programs, documents, and data

19
WHAT / WHO / WHY IS PROCESS
MODELS?

• What are the steps: The process you adopt depends on the software that
you are building. One process might be good for aircraft avionic system,
while an entirely different process would be used for website creation.

• How to ensure right: A number of software process assessment

mechanisms can be used to determine the maturity of the software
process. However, the quality, timeliness and long-term feasibility of the
software are the best indicators of the efficacy of the process you use.

20
 DEFINITION OF 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
• An action encompasses a set of tasks that produce a major work
product
• A task focuses on a small, but well-defined objective that produces a
tangible outcome.

21
 PROCESS FRAMEWORK(Phases)

• Communication
• Planning
• Modeling
• Construction
• Deployment

Umbrella activities
e.g. Risk management, Measurement, Reviews, SCM

22
A GENERIC PROCESS MODEL

23
 A GENERIC PROCESS MODEL

• a generic process framework for software engineering defines five framework

activities-communication, planning, modeling, construction, and deployment.
• Communication: to gather requirements that help define software features
and functions.
• Planning: describes 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.

24
 A GENERIC PROCESS MODEL

• Modeling : create a “sketch” of the thing so that you’ll understand the big
picture. If required, you refine the sketch into greater and greater detail in an
effort to better understand the problem and how you’re going to solve it.
• Construction. This activity combines code generation and the testing that is
required to uncover errors in the code.

25
 A GENERIC PROCESS MODEL

• Deployment: The software is delivered to the customer who evaluates the

delivered product and provides feedback based on the evaluation.
• In addition, a set of umbrella activities- project tracking and control, risk
management, quality assurance, configuration management, technical reviews,
Measurement , Reusability management and Work product preparation and
production are applied throughout the process.

26
 A GENERIC PROCESS MODEL

• 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 to
monitoring the software engineering processes and methods used to ensure
quality.

27
 A GENERIC PROCESS MODEL

• Technical reviews—assesses software engineering work products in an

effort to uncover and remove errors before they are propagated to the next
activity.
• Software configuration management— is the task of tracking and
controlling changes in the software throughout the software process
• Reusability management—defines criteria for work product reuse and
establishes mechanisms to achieve reusable components.

28
 A GENERIC PROCESS MODEL

• Work product preparation and production—encompasses the

activities required to create work products such as models, documents, logs,
forms, and lists..
• Measurement—defines and collects process, project, and product measures
that assist the team in delivering software that meets stakeholders’ needs

29
TYPES OF
PROCESS FLOW

1) Linear Process Flow

2) Iterative Process Flow
3) Evolutionary Process Flow
4) Parallel Process Flow

30
30
 PROCESS FLOW CONTD…

1) Linear process flow executes each of the five activities in sequence.

2) An iterative process flow repeats one or more of the activities before
proceeding to the next.
3) An evolutionary process flow executes the activities in a circular manner.
Each circuit leads to a more complete version of the software.
4) A parallel process flow executes one or more activities in parallel with
other activities

31
IDENTIFYING A TASK SET

• Before you can proceed with the process model, a key

question: what actions are appropriate for a framework
activity given the nature of the problem, the characteristics
of the people and the stakeholders?
• A task set defines the actual work to be done to accomplish
the objectives of a software engineering action.

32
 IDENTIFYING A TASK SET

• For example, a small software project requested by one person with simple
requirements, the communication activity might encompass little more than
a phone call with the stakeholder. Therefore, the only necessary action is
phone conversation, the work tasks of this action 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.

33
 EXAMPLE OF A TASK SET FOR
ELICITATION(IS A TECHNIQUE USED TO GATHER INFORMATION)

• The task sets for Requirements gathering action for a simple project may
include:
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.

34
The task sets for Requirements gathering action for a big project may include:

1. Make a list of stakeholders for the project.

2. Interview each stakeholders 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.
35
PROCESS MODELS

• Prescriptive Process Models

• Specialized Process Models (component based- Not in
syllabus)
• Unified Process

36
 PRESCRIPTIVE MODELS

• Waterfall/V model
• Incremental
• Evolutionary
• Prototyping
• Spiral

37
 THE WATERFALL
MODEL

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.

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, culminating in
ongoing support of the completed software 38
THE WATERFALL MODEL

• When to select?
• There are times when the requirements for a problem are well
understood—when work flows from communication through
deployment in a reasonably linear fashion.
• (problems: 1. rarely linear, iteration needed. 2. hard to state
all requirements explicitly. Blocking state. 3. code will not
be released until very late.)

39
WATERFALL MODEL (CONTD)

When do you choose this Advantages

model?
1. Simple
• Requirements are well 2. Easy to understand even
defined for non technical
• Well understood customers
• Well defined enhancements 3. Oldest, widely used
to existing system 4. Base for all other models
by including feed back
loops, iterations etc.
Disadvantages
• Real projects rarely follow this linear sequence.
• Difficult for customer to state all requirements at
one shot
• Customer must have patience.
40
THE V-MODEL
A variation of waterfall model depicts
the relationship of quality assurance
actions to the actions associated with
communication, modeling and early
code construction activates.

Team first moves down the left side of

the V to refine the problem
requirements. Once code is generated,
the team moves up the right side of the
V, performing a series of tests that
validate each of the models created as
the team moved down the left side.
41
THE INCREMENTAL MODEL

42
INCREMENTAL MODEL (CONTD)
When do we use this model?
• Requirements are reasonably well defined
• But overall scope precludes linear flow
• Difficult deadlines
• Constraints in staffing
• Manage technical risks.
• Compelling need to provide limited set of functionality to users quickly.

Steps
• First increment is a core product
• Core product used/reviewed by the customer
• A plan for the next increment is laid. Modification of the core product for
additional functionality
• Process is repeated following the delivery of each increment, until the complete
product is produced. 43
THE INCREMENTAL MODEL

• When initial requirements are reasonably well defined, but the

overall scope of the development effort prevent a purely linear
process.
• A compelling need to expand a limited set of new functions to a later
system release.
• It combines elements of linear and parallel process flows. Each linear
sequence produces deliverable increments of the software.
• The first increment is often a core product with many supplementary
features. Users use it and evaluate it with more modifications to
better meet the needs. 44
 THE INCREMENTAL MODEL

• This process is repeated following the delivery of each increment,

until the complete product is produced
• When to use?
• Incremental development is particularly useful when staffing is
unavailable for a complete implementation by the business deadline
that has been established for the project.

45
 THE INCREMENTAL MODEL

• 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.
• In addition, increments can be planned to manage technical risks

46
INCREMENTAL MODEL (CONTD)

Advantages Disadvantages
1. Early feedback is there on the 1. Requires expertise
core product.
planning both at
2. Reduced risk management and technical
3. Effective solution since user level
evaluates core product at
each increment level
2. Client dependent,
customer should accept
4. Complexity is reduced
phased deliverables

47
 EVOLUTIONARY MODELS
• Software system evolves over time as requirements often change as
development proceeds. Thus, a straight line to a complete end product is not
possible. However, a limited version must be delivered to meet competitive
pressure.
• Usually a set of core product or system requirements is well understood, but
the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to accommodate
a product that evolved over time.
• It is iterative that enables you to develop increasingly more complete version
of the software.
48
• Two types are introduced, namely Prototyping and Spiral models.
EVOLUTIONARY MODELS:
PROTOTYPING
Steps
• Begins with communication
Quick
plan • A quick plan for prototyping and
communication modeling occur.
Modeling • Quick design focuses on a
Quick design
representation of those aspects
the software that will be visible to
end users. ( interface and output).
• Design leads to the construction
Deployment ofConstruction
a prototype which will be
delivery &
feedback Construction deployed
of prototype and evaluated.
of prototype
• Stakeholder’s comments will be
used to refine requirements.
49 49
 EVOLUTIONARY MODELS:
PROTOTYPING
• When to use: Customer defines a set of general objectives but does not identify detailed
requirements for functions and features. Or Developer may be unsure of the efficiency of an
algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the objective,
identify whatever requirements are known, outline areas where further definition is
mandatory. A quick plan for prototyping and modeling (quick design) occur. Quick design
focuses on a representation of those aspects the software that will be visible to end users. (
interface and output). Design leads to the construction of a prototype which will be
deployed and evaluated. Stakeholder’s comments will be used to refine requirements.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for
the actual system, and developers get to build something immediately. However, engineers
may make compromises in order to get a prototype working quickly. The less-than-ideal
choice may be adopted forever after you get used to it. 50
EVOLUTIONARY MODELS:
PROTOTYPING
Advantages Disadvantages
• Provides working model. • Customer - not aware that only interface
• Customer is highly satisfied with such a
or appearance is concentrated much and
modeling at initial stages long term quality is at stake

• Developer gains business insight, reducing • False expectations from customer that end
ambiguity
s/m is finished or will have the same
• Great involvement of users behavior/pace of the prototype

• Reduce risks • Inappropriate choices of technology

Construction
• Various of prototype
iterations to
a prototype that is to
be discarded is expensive

51
EVOLUTIONARY MODELS:
THE SPIRAL
How it works?

• Series of evolutionary releases

• Earlier releases – prototype, later
implementation
• First circuit - specification, next
prototype and sophisticated versions
• Each pass
• Project plan, Cost, schedule, number of
future iterations adjusted
• Risk is evaluated

52
 EVOLUTIONARY MODELS:
THE SPIRAL
• It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model
and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of
software intensive systems.

• Two main distinguishing features: one is cyclic approach for incrementally growing a system’s degree of definition
and implementation while decreasing its degree of risk. The other is a set of anchor point milestones for
ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.

• A series of evolutionary releases are delivered. During the early iterations, the release might be a model or
prototype. During later iterations, increasingly more complete version of the engineered system are produced.

• The first circuit in the clockwise direction might result in the product specification; subsequent passes around
the spiral might be used to develop a prototype and then progressively more sophisticated versions of the
software. Each pass results in adjustments to the project plan. Cost and schedule are adjusted based on
feedback. Also, the number of iterations will be adjusted by project manager.

• Good to develop large-scale system as software evolves as the process progresses and risk should be
understood and properly reacted to. Prototyping is used to reduce risk.
53
• However, it may be difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise.
EVOLUTIONARY MODELS:
THE SPIRAL
Advantages Disadvantages

• Applies throughout lifecycle

• Difficult to convince customers that it is
• Concept Development
controllable
• New Prod Development
• Demands considerable risk assessment
• Product Enhancement
expertise
• Risk is considered at each pass
• Major risk is not uncovered/managed,
• Uses prototyping as risk reduction
problem will occur
mechanism
• Customer and developer understand
and better react to risks

54
 THREE CONCERNS ON
EVOLUTIONARY PROCESSES
• First concern is that prototyping poses a problem to project planning because of
the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the
process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility rather
than on high quality. We should prioritize the speed of the development over
zero defects. Extending the development in order to reach high quality could
result in a late delivery of the product when the opportunity niche has
55
disappeared.
 THE RATIONAL UNIFIED PROCESS

• RUP is a method of managing OO Software Development

• It can be viewed as a Software Development Framework which is
extensible and features:
• Iterative Development
• Requirements Management
• Component-Based Architectural Vision
• Visual Modeling of Systems
• Quality Management
56
• Change Control Management
 RUP FEATURES

• Online Repository of Process Information and Description

in HTML format
• Templates for all major artifacts, including:
• RequisitePro templates (requirements tracking)
• Word Templates for Use Cases
• Project Templates for Project Management

• Process Manuals describing key processes

57
THE PHASES

58
 AN ITERATIVE DEVELOPMENT
PROCESS...
• Recognizes the reality of changing requirements
• Caspers Jones’s research on 8000 projects

• 40% of final requirements arrived after the analysis phase, after

development had already begun
• Promotes early risk mitigation, by breaking down the system into mini-projects
and focusing on the riskier elements first
• Allows you to “plan a little, design a little, and code a little”
• Encourages all participants, including testers, integrators, and technical writers to
be involved earlier on
• Allows the process itself to modulate with each iteration, allowing you to correct
errors sooner and put into practice lessons learned in the prior iteration
• Focuses on component architectures, not final big bang deployments
 AN INCREMENTAL DEVELOPMENT
PROCESS...

• Allows for software to evolve, not be produced in one huge effort

• Allows software to improve, by giving enough time to the evolutionary
process itself
• Forces attention on stability, for only a stable foundation can support
multiple additions
• Allows the system (a small subset of it) to actually run much sooner than
with other processes
• Allows interim progress to continue through the stubbing of functionality
• Allows for the management of risk, by exposing problems earlier on in the
development process 60
 GOALS AND FEATURES OF EACH
ITERATION
• The primary goal of each iteration is to slowly chip away at the risk facing the
project, namely:
• performance risks
• integration risks (different vendors, tools, etc.)
• conceptual risks (ferret out analysis and design flaws)
• Perform a “miniwaterfall” project that ends with a delivery of something tangible in
code, available for scrutiny by the interested parties, which produces validation or
correctives

• Each iteration is risk-driven

• The result of a single iteration is an increment--an incremental improvement of the

61
system, yielding an evolutionary approach
 THE DEVELOPMENT PHASES

• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase

62
THE UNIFIED PROCESS (UP)
elaboration

inception

63
 INCEPTION PHASE

• Overriding goal is obtaining buy-in from all interested parties

• Initial requirements capture
• Cost Benefit Analysis
• Initial Risk Analysis
• Project scope definition
• Defining a candidate architecture
• Development of a disposable prototype
• Initial Use Case Model (10% - 20% complete)
• First pass at a Domain Model 64
 ELABORATION PHASE

• Requirements Analysis and Capture

• Use Case Analysis
• Use Case (80% written and reviewed by end of phase)
• Use Case Model (80% done)
• Scenarios
• Sequence and Collaboration Diagrams
• Class, Activity, Component, State Diagrams
• Glossary (so users and developers can speak common vocabulary)
• Domain Model
• to understand the problem: the system’s requirements as they exist
within the context of the problem domain
65
• Risk Assessment Plan revised
• Architecture Document
 CONSTRUCTION PHASE

• Focus is on implementation of the design:

• cumulative increase in functionality
• greater depth of implementation (stubs fleshed out)
• greater stability begins to appear
• implement all details, not only those of central
architectural value
• analysis continues, but design and coding predominate

66
 TRANSITION PHASE

• The transition phase consists of the transfer of the system to the user
community
• It includes manufacturing, shipping, installation, training, technical
support and maintenance
• Development team begins to shrink
• Control is moved to maintenance team
• Alpha, Beta, and final releases
• Software updates
• Integration with existing systems (legacy, existing versions, etc.)
67
AGILE PROCESS MODEL

68
THE MANIFESTO FOR
AGILE SOFTWARE DEVELOPMENT
“We are uncovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:
•Individuals and interactions over processes and tools
•Working software over comprehensive
documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.”

Kent Beck et al 69
70

WHAT IS “AGILITY”?
• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work performed
Yielding …
• Rapid, incremental delivery of software

70
 .

71

AGILITY AND THE COST OF CHANGE

71
 .

72

AN AGILE PROCESS
• Is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on
construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur

72
AGILITY PRINCIPLES - I
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to
and within a development team is face–to–face conversation.

73
AGILITY PRINCIPLES - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity – the art of maximizing the amount of work not
done – is essential.
11. The best architectures, requirements, and designs emerge from
self–organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

74
HUMAN FACTORS

• the process molds to the needs of the people and team, not the
other way around
• key traits must exist among the people on an agile team and the
team itself:
• Competence.
• Common focus.
• Collaboration.
• Decision-making ability.
• Fuzzy problem-solving ability.
• Mutual trust and respect.
• Self-organization.
75
EXTREME PROGRAMMING (XP)

• The most widely used agile process, originally proposed by

Kent Beck
• XP Planning
• Begins with the creation of “user stories”
• Agile team assesses each story and assigns a cost
• Stories are grouped to for a deliverable increment
• A commitment is made on delivery date
• After the first increment “project velocity” is used to help define
subsequent delivery dates for other increments
76
EXTREME PROGRAMMING (XP)
• XP Design
• Follows the KIS principle
• Encourage the use of CRC cards (see Chapter 8)
• For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the internal
program design
• XP Coding
• Recommends the construction of a unit test for a store before coding
commences
• Encourages “pair programming”
• XP Testing
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and excuted to assess 77
customer visible functionality
EXTREME PROGRAMMING (XP)

78
SCRUM

• Originally proposed by Schwaber and Beedle

• Scrum—distinguishing features
• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is
constructed
• Work occurs in “sprints” and is derived from a “backlog” of existing
requirements
• Meetings are very short and sometimes conducted without chairs
• “demos” are delivered to the customer with the time-box allocated

79
SCRUM

80
81

Project Initiation Management

82 Project Initiation

• Project initiation is the first step in starting a new project. During the project
initiation phase, you establish why you’re doing the project and what
business value it will deliver.

• Project initiation is the first phase of the project management life cycle and in
this stage, companies decide if the project is needed and how beneficial it
will be for them. The two metrics that are used to judge a proposed project
and determine the expectations from it are the business case and feasibility
study.
 83 Importance of Project Initiation

• Take major decisions that establish the direction and resource requirements, like
the project charter and selecting the project stakeholders, are made during this
phase. The stakeholders arrive at a clear objective to ensure everyone stays on the
same page in terms of how the project should proceed.
• There will be multiple checks during and after project execution to prevent
miscommunication and to ensure the project stays on track throughout its course.
However, precious time and resources might get wasted which is undesirable.
• Effective project management requires you to maximize benefits and minimize
costs while delivering ‘value’ to the customer. Having a clear project objective
helps you achieve all this.
84 Project initiation process-6 steps

1. Creating a business case

2. Conducting a feasibility study
3. Establishing a project charter
4. Identifying stakeholders and making a stakeholder register
5. Assembling the team and establishing a project office
6. Final review
85
 86 Project charter

A project charter demonstrates why your project is important, what it will entail, and who
will work on it—all through the following elements:

Why: The project’s goals and purpose

What: The scope of the project, including an outline of your project budget
Who: Key stakeholders, project sponsors, and project team members
87 Project Scope

Project scope is a way to set boundaries on your project and define

exactly what goals, deadlines, and project deliverables you’ll be
working towards. By clarifying your project scope, you can ensure
you hit your project goals and objectives without delay or overwork.
88 Benefits of defining your project
scope
• Ensure all stakeholders have a clear understanding of the boundaries of
the project
• Manage stakeholder expectations and get buy-in
• Reduce project risk
• Budget and resource plan appropriately
• Align your project to its main objectives
• Prevent scope creep (when project deliverables exceed the project scope)
• Establish a process for change requests (for complex projects)
89 Steps in defining project scope

1: Define the project goal and objectives

2: Identify the potential roadblocks
3: Incorporate additional project requirements
4: List necessary resources
5: Chart a project milestone schedule
6: Define the tasks and deliverables
7: Have a change management and control system
8: prepare and share the project scope statement
90 Project Objectives

Project objectives are what you plan to achieve by the end of your
project.
This might include deliverables and assets, or more intangible
objectives like increasing productivity or motivation.
Your project objectives should be attainable, time-bound, specific
goals you can measure at the end of your project.
91 Steps to follow in writing Project
Objectives
1. Set your project objectives at the beginning of your project
2. Involve your project team in the goal-setting process
3. Create brief, but clear, project objective statements
4. Make sure your objectives are things you can control (SMART-
Specific,Measurable,Achievable,Realistic,Time-bound)
5. Check in on your project objectives during the project’s lifecycle
 92 Example 1- Business project
objective
Bad: Launch new home page.
This project objective is missing many important characteristics. Though this objective is
measurable, achievable, and realistic, it’s not specific or time-bound. When should the home page
be live? What should the redesign focus on?
Good: Create net-new home page assets and copy, focusing on four customer stories and use
cases. Launch refreshed, customer-centric home page by the end of Q2.
This project objective is solid. It’s specific (create net-new home page assets and copy),
measurable (launch refreshed, customer-centric home page), achievable and realistic (focusing on
four customer stories and use cases), and time bound (by the end of Q2).
 93 Example 2- Non profit Project
Objective
Bad: Increase sustainability in our production process by 5%
Though this project objective is more specific than the previous bad example, it’s still lacking
several important characteristics. This objective is measurable (by 5%), but it’s not specific or
time-bound, since we don’t specify what “sustainability” means or by when the production process should
improve. As a result, we don’t really know if it’s achievable or realistic.
Good: Reduce operational waste by 5% and increase use of recycled products by 20% in the next 12
weeks.
This project objective builds upon the previous one, because we now have a specific objective. This
project objective also includes a way to measure the goal (by
5%... by 20%). The objective is a little ambitious, but the fact that it’s time-bound (in the next 12 weeks)
makes it both achievable and realistic.
94