What is a project?

 A sequence of connected and related activities

(requirement engineering, system engineering,
coding, testing, documentation, controlling, …)
that must be completed by a specific time, within
budget, and according to specification.

 A temporary endeavor undertaken to create a

unique product or service
Software Projects vs Other Projects

 Invisibility – progress is not immediately

visible
 Complexity – financially software products
contain more complexity than other
engineered artefacts.
 Flexibility the ease with which software can
be changed is usually seen as one of its
strengths.
Characteristics distinguishing projects:

 Planning is required
 Specific objectives are to be met or specified
product is to be created.
 Work is carried out for someone other than
yourself
 Work involves several specialisms
 Work is carried out in several phases
 Resources available for use on the project are
constrained
 The project is large or complex
Project stakeholders

 Every project has stakeholders.

 These are the people who have a stake or
interest in the project. Must be identified as
early as possible in order to establish
adequate communication channels with
them from the start.
Project stakeholders
 Maybe:
 Internal to the project – controlled by project leader
 External to the project team but within the same
organisation e.g. assistance of users to carry out system
testing. Commitment has to be negotiated.
 External to both the project team and the organization
e.g. contractors who will carry out work for the project.
The relationship is likely to be based on a legally binding
contract.
 Different types of stakeholders have different objectives
and the job of a successful project leader is to recognize
these different interests and be able to reconcile them.
Therefore the project leader needs to be a good
communicator and negotiator.
Software Project Management

 A software project has a specific duration,

consumes resources and produces work
products.
 Every software project must have a
manager who leads the development team
and is the interface with the initiators,
suppliers and senior management.
 All technical and managerial activities
required to deliver the deliverables to the
client.
Software Project Management

Project management:
is the application of knowledge, skills, tools
and techniques to project activities to meet
project requirements
Software project management: is the
process of planning, organising, staffing,
monitoring, controlling and leading a
software project
Duties of the Project Manager

 Produces the Software Project Management

Plan (SPMP)
 Defines the organisational roles and allocates
staff to them.
 Controls the project by informing staff of their
part in the plan
 Leads the project by making the major
decisions and by motivating staff to perform
well.
 Monitors the project by measuring progress
and reports progress to initiators and senior
managers.
The Project Manager

 Negotiating:
 Involves conferring with others to come to
terms with them or reach an agreement.
Agreements may be negotiated directly or with
assistance.
 Negotiation areas may include scope, cost, and
schedule objectives, changes to scope, cost, or
schedule, contract terms and conditions.
 Innovating – coming up with new solutions
 Communication: Report progress
Software Project Management Plan
(SPMP)

 The controlling document for a software

project.
 Specifies the technical and managerial
approaches to develop the software product.
 Companion document to requirements analysis
document: Changes in either may imply changes
in the other document.
 SPMP may be part of project agreement.
Project Management Knowledge Areas

 Describes project management knowledge

and practice in terms of the various
component processes.
 9 knowledge areas
Project Management Knowledge
Areas
1. Project Integration Management
 Describes the processes required to ensure that the
various elements of the project are properly
coordinated.
 It consists of project plan development, project plan
execution, and integrated change control.

2. Project Scope Management

 Describes the processes required to ensure that the
project includes all the work required, and only the work
required, to complete the project successfully.
 It consists of initiation, scope planning, scope definition,
scope verification, and scope change control.
Project Management Knowledge Areas

3. Project Time Management

 Describes the processes required to ensure timely
completion of the project.
 It consists of activity definition, activity
sequencing, activity duration estimating, schedule
development, and schedule control.
4. Project Cost Management
 Describes the processes required to ensure that
the project is completed within the approved
budget.
 It consists of resource planning, cost estimating,
cost budgeting, and cost control.
Project Management Knowledge Areas

5. Project Quality Management

 Describes the processes required to ensure that the
project will satisfy the needs for which it was undertaken.
 It consists of quality planning, quality assurance, and
quality control.

6. Project Human Resource Management

 describes the processes required to make the most
effective use of the people involved with the project.
 It consists of organizational planning, staff acquisition,
and team development.
Project Management Knowledge Areas

7. Project Communications Management:

 Describes the processes required to ensure timely and
appropriate generation, collection, dissemination, storage, and
ultimate disposition of project information.
 It consists of communications planning, information
distribution, performance reporting, and administrative
closure.

8. Project Risk Management

 Describes the processes concerned with identifying, analyzing,
and responding to project risk.
 It consists of risk management planning, risk identification,
qualitative risk analysis, quantitative risk analysis, risk
response planning, and risk monitoring and control.
Project Management Knowledge Areas

9. Project Procurement Management

 Describes the processes required to acquire
goods and services from outside the
performing organization.
 It consists of procurement planning,
solicitation planning, solicitation, source
selection, contract administration, and
contract closeout.
Project Management Processes
 Project management processes describe, organize, and
complete the work of the project.
 Generally fall into one of two major categories:
 Product-oriented processes specify and create the
project’s product. Product oriented processes are
typically defined by the project life and vary by
application area.
 Project management processes and product-oriented
processes overlap and interact throughout the project.
For example, the scope of the project cannot be defined in
the
absence of some basic understanding of how to create the
product.
Management Control

 Management – the process of setting

objectives for a system and then monitoring
the system to see what its true performance
is.
 The actual performance is compared with
objectives and remedial action can be taken
when a discrepancy is found between the
two.
Measurement

 Measures can be divided into:

 Performance measures – measure the
characteristics of a system that has been delivered.
Important when trying to specify unambiguously
the quality requirements of a proposed system.
Examples are reliability , mean time between
failures and usability , time to learn a package.
 Predictive measures – give characteristics of a final
system during its development e.g. errors found
per KLOC at different stages of the project may
help to predict the correctness and reliability of
the final system
Software Development Process

 The manager of a software development project

has to ensure that all of the project activities follow
a certain predefined process, i.e. that the activities
are organized as a series of actions conducing to a
desirable end
 The activities are usually organized in distinct
phases, and the process specifies what artifacts
should be developed and delivered in each phase.
 The process provides means for control and
guidance of the individual team members and the
team as a whole, as it offers criteria for tracing and
evaluation of the project's deliverables and
activities.
Process Models

 It is absolutely necessary to follow a certain

predefined process in software development. It
helps developers understand, evaluate, control,
learn, communicate, improve, predict, and
certify their work.
 Since processes vary with the project's size,
goals, and resources, as well as the level at
which they are applied (e.g., the organization
level, the team level, or the individual level), it
is always important to define, measure,
analyze, assess, compare, document, and
change different processes.
Process Models

 Help in the software development

 Guide the software team through a set of

framework activities

 Process Models may be linear, incremental

or evolutionary
Waterfall Model

 Proceeds through several phases in a

systematic and sequential manner.
 Once a certain phase is finished it is
considered closed, and the work proceeds
with the next phase.
 It is however a rigid in the sense that it
doesn’t comply with the reality of
everchanging requirements and technology.
 Waterfall model
.
Communication(
Initiation,
requirement
gathering)
Planning(Es
timation
,Scheduling,
etc)
Modeling
(Analysis and
Design)
Construction(
code and
testing)
Deployment(Del
ivery , Support
and feedback)
PROBLEMS IN WATERFALL MODEL

 Real projects rarely follow the sequential

flow since they are always iterative
 The model requires requirements to be
explicitly spelled out in the beginning,
which is often difficult
 A working model is not available until late
in the project time plan
2. Iterations

 Iterations in software development activities

and incremental development help reduce the
problem of rigidity of the model.
 Used when initial requirements are reasonably
well-defined and compelling need to provide
limited functionality quickly
 Functionality expanded further in later
releases
 Software is developed in increments
 The Incremental Model
Communication Increment # n
Software functionality and features

Planning
Modeling Communication
Planning
Modeling
Construction Analysis
design
Construction
Code
test
Deployment
Delivery
Support
feedback

Deployment delivery of
nth increment
Increment#2

Communication
Planning
Modeling
Construction
Increment # 1 Deployment
Analysis
design Code
test
Delivery
Support
Delivery of
feedback
2nd increment

Communication
Planning
Modeling
Analysis Construction Deployment
design Code
test
Delivery
Support
feedback
delivery of
1ST increment

Project calendar time

THE INCREMENTAL MODEL

 Software released in increments

 1st increment constitutes Core product
 Basic requirements are addressed
 Core product undergoes detailed evaluation by
the customer
 As a result, plan is developed for the next
increment
Plan addresses the modification of core product
to better meet the needs of customer
 Process is repeated until the complete product
is produced
THE RAD MODEL
(Rapid Application Development)
 An incremental software process model.
 Having a short development cycle: Creates a
fully functional system within a very short
span time of 60 to 90 days.
 High-speed adoption of the waterfall model
using a component based construction
approach.
 The RAD Model
Team # n
Modeling
Business modeling
Data modeling
Process modeling

Construction
Team # 2 Component reuse
automatic code
generation
Communication Modeling testing

Business modeling
Data modeling
Process modeling

Construction
Planning Team # 1 Component reuse
automatic code
generation
testing
Modeling
Business modeling Deployment
Data modeling integration
Process modeling delivery
feedback

Construction
Component reuse
automatic code
generation
testing
THE RAD MODEL

 Multiple software teams work in parallel on different

functions
 Modeling encompasses three major phases: Business
modeling, Data modeling and process modeling
 Construction uses reusable components, automatic
code generation and testing
Problems in RAD
 Requires a number of RAD teams
 Requires commitment from both developer and
customer for rapid-fire completion of activities
 Requires modularity
 Not suited when technical risks are high
EVOLUTIONARY PROCESS MODELS

 Software evolves over a period of time

 Business and product requirements often
change as development proceeds making a
straight-line path to an end product unrealistic
 Evolutionary models are iterative and as such
are applicable to modern day applications
Types of evolutionary models
 Prototyping
 Spiral model
 Concurrent development model
 PROTOTYPING
 Mock up or model( throw away version) of a
software product
 Used when a customer defines a set of
objectives but does not identify input, output, or
processing requirements
Developer is not sure of:
 efficiency of an algorithm
 adaptability of an operating system
 human/machine interaction
Evolutionary Models: Prototype
Quick
Communication Plan

Modeling
Quick design

Construction
Deployment of prototype
delivery &
feedback
STEPS IN PROTOTYPING

 Begins with requirement gathering

 Identify whatever requirements are known
 Outline areas where further definition is
mandatory
 A quick design occur which leads to the
construction of prototype
 Prototype is evaluated by the customer
 Requirements are refined
 Prototype is turned to satisfy the needs of
customer
LIMITATION OF PROTOTYPING

 In a rush to get it working, overall software

quality or long term maintainability are
generally overlooked

 Use of inefficient algorithm

THE SPIRAL MODEL

 An evolutionary model which combines the

best feature of the classical life cycle and the
iterative nature of prototype model
 Include new element : Risk element
 Starts in middle and continually visits the
basic tasks of communication,
planning,modeling,construction and
deployment
Evolutionary Models: The Spiral
THE SPIRAL MODEL
1.COMMUNICATION
*Tasks required are establish effective communication between
developer
2.PLANNING
*Estimation
*Scheduling
*Risk analysis
3. MODELING
*Analysis
*Design
4. CONSTRUCTION
*Code
*Test
5. DEPLOYMENT
*Delivery
*Feedback
THE SPIRAL MODEL

 Realistic approach to the development of

large scale system and software
 Software evolves as process progresses
 Better understanding between developer
and customer
 The first circuit might result in the
development of a product specification
 Subsequent circuits develop a prototype
 And sophisticated version of software
 THE CONCURRENT DEVELOPMENT
MODEL

Also called concurrent engineering

Constitutes a series of framework activities, software
engineering action, tasks and their associated states
All activities exist concurrently but reside in different
states
Applicable to all types of software development
Event generated at one point in the process trigger
transitions among the states
A FINAL COMMENT ON
EVOLUTIONARY PROCESS
 Difficult in project planning
 Speed of evolution is not known
 Does not focus on flexibility and
extensibility (more emphasis on high
quality)
 Requirement is balance between high
quality and flexibility and extensibility
 THE UNIFIED PROCESS
 Evolved by Rumbaugh, Booch, Jacobson
 Combines the best features their OO models
 Adopts additional features proposed by other
experts
 Resulted in Unified Modeling Language(UML)
 Unified process developed Rumbaugh and Booch
 A framework for Object-Oriented Software Engineering
using UML
PHASES OF UNIFIED PROCESS

 INCEPTION PHASE

 ELABORATION PHASE

 CONSTRUCTION PHASE

 TRANSITION PHASE
The Unified Process (UP)
.
UNIFIED PROCESS WORK PRODUCTS

 Tasks which are required to be completed during

different phases
 Inception Phase
*Vision document
*Initial Use-Case model
*Initial Risk assessment
*Project Plan
 Elaboration Phase
 *Use-Case model
*Analysis model
*Software Architecture description
*Preliminary design model
*Preliminary model
UNIFIED PROCESS WORK PRODUCTS

 Construction Phase
*Design model
*System components
*Test plan and procedure
*Test cases
*Manual
 Transition Phase
*Delivered software increment
*Beta test results
*General user feedback
SOFTWARE REQUIREMENTS

 IEEE defines Requirement as :

1. A condition or capability needed by a user to
solve a problem or achieve an objective

2. A condition or capability that must be met

or possessed by a system or a system
component to satisfy contract, standard,
specification or formally imposed
documents
3. A documented representation of a condition
or capability as in 1 or 2
 SOFTWARE REQUIREMENTS
Encompasses both the User’s view of the requirements(
the external view ) and the Developer’s view( inside
characteristics)
 User’s Requirements --
Statements in a natural language plus diagrams,
describing the services the system is expected to
provide and the constraints
 System Requirements
--Describe the system’s function, services and
operational condition
SOFTWARE REQUIREMENTS
 System Functional Requirements
--Statement of services the system should provide
--Describe the behavior in particular situations
--Defines the system reaction to particular inputs
 Nonfunctional Requirements
- Constraints on the services or functions offered by the system

--Include timing constraints, constraints on the development

process and standards
--Apply to system as a whole
 Domain Requirements
--Requirements relate to specific application of the system
--Reflect characteristics and constraints of that system
FUNCTIONAL REQUIREMENTS

Should be both complete and consistent

 Completeness
-- All services required by the user should be
defined
 Consistent
-- Requirements should not have
contradictory definition
 NON-FUNCTIONAL REQUIREMENTS
Types of Non-functional Requirements
1.Product Requirements
 Specify product behavior
Include the following
 Usability
 Efficiency
 Reliability
 Portability
NON-FUNCTIONAL REQUIREMENTS

2.Organisational Requirements
Derived from policies and procedures
--Include the following:
Delivery
Implementation
Standard
NON-FUNCTIONAL REQUIREMENTS

3.External Requirements
 Derived from factors external to the system
and its development process
--Includes the following
 Interoperability
 Ethical
 Legislative
 Different types of non-functional
requirements Non-functional
requir ements

Product Organisational External

r equir ements requir ements r equir ements

Efficiency Relia bility Portability Inter oper ability Ethical

requir ements r equir ements requir ements requir ements r equir ements

Usability Deli very Implementa tion Standar ds Leg islati v e

r equir ements requir ements requir ements requir ements requir ements

Perfor mance Space Pri vacy Safety

requir ements r equir ements r equir ements requir ements
PROBLEMS FACED USING THE
NATURAL LANGUAGE
 1. Lack of clarity
-- Leads to misunderstanding because
of ambiguity of natural language
2. Confusion
-- Due to over flexibility,sometime difficult
to find whether requirements are same or
distinct.
3. Amalgamation problem
-- Difficult to modularize natural language
requirements
 The Software Requirements document
 Heninger suggests that there are 6 requirements
that requirement document should satisfy. It
should
 specify only external system behavior
 specify constraints on the implementation.
 Be easy to change
 Serve as reference tool for system maintainers
 Record forethought about the life cycle of the system.
 Characterize acceptable responses to undesired events
Purpose of SRS

 Communication between the Customer,

Analyst,system developers, maintainers, ..
 Firm foundation for the design phase
 Support system testing activities
 Support project management and control
 Controlling the evolution of the system
IEEE requirements standard

 Defines a generic structure for a

requirements document that must be
instantiated for each specific system.
 Introduction.
 General description.
 Specific requirements.
 Appendices.
 Index.
 IEEE requirements standard

1.Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview
2. General description
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific Requirements
- Functional requirements
-External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability,maintainability,
transferability/conversion
- Other requirements
 Appendices
 Index
Project Phases

 All projects are divided into phases.

 All phases together are known as the
Project Life Cycle.
 Each phase is marked by completion of
Deliverables
Project life cycle

 1. Software Concept/Concept Exploration

 2. Requirements Analysis
Involves finding out the details concerning what the
users require of the system that the project is to
implement.
 3. Architectural Design
 4. Detailed Design
 5. Coding and Debugging: Includes writing the actual
code
 6. System Testing
 7. Deployment and Maintenance.
Classic Mistakes

Types
a. People-Related
 Undermined motivation
 Weak personnel
 Uncontrolled problem employees
 Adding people to a late project
 Customer-Developer friction.
 Unrealistic expectations
 Lack of stakeholder participation
Classic Mistakes

b. Process-Related
 Optimistic schedules
 Insufficient risk management.
 Contractor failure
 Insufficient planning.
 Abandonment of plan under pressure.
Insufficient management controls.
 Omitting necessary tasks from estimates
Classic Mistakes

c. Product-Related
 Requirements gold-plating.
 Feature creep.
 Developer gold-plating.
 Push-pull negotiation
Classic Mistakes

d. Technology-Related
 Overestimated savings from new tools and
methods.
 Switching tools in mid-project.
 Lack of automated source-code control