1 3/9/2016

CMP 351

Project Management
 2 3/9/2016

Project
 Projects can be defined as temporary rather than permanent social
systems or work systems that are constituted by teams within or
across organizations to accomplish particular tasks under time
constraints
 A project is a temporary endeavor designed to produce a unique
product, service or result with a defined beginning and end
 3 3/9/2016

ICT Project
 This is a temporary endeavour undertaken to create a product or
service that includes a significant ICT component such as the
implementation of a new system or substantial modifications to an
existing one.
 4 3/9/2016

Project Management
 Project management is the discipline of planning, organizing,
motivating, and controlling resources to achieve specific goals.
 It is the application of knowledge, skills, tools and techniques to a
broad range of activities in order to meet the requirements of a
particular project
 Usually undertaken to meet unique goals and objectives, typically
to bring about beneficial change or added value.
 5 3/9/2016

Project Management Constraints

 Funding/Budget
 Scope
 Time
 Quality
 Optimizing the allocation of necessary inputs and integrating them to
meet pre-defined objectives.
 6 3/9/2016

Basic Phases of Project Management

 The process of directing and controlling a project from start to finish
may be further divided into 5 basic phases:
 Project conception and initiation
 Project definition and planning
 Project launch or execution
 Project performance and control
 Project close
 7 3/9/2016

Project Conception and Initiation

 An idea for a project will be carefully examined to determine whether
or not it benefits the organization.
 During this phase, a decision making team will identify if the project
can realistically be completed
 8 3/9/2016

Project Definition and Planning

A project plan, and/or project scope may be put in writing, outlining
the work to be performed.
 During this phase, a team should prioritize the project, calculate a
budget and schedule, and determine what resources are needed.
 9 3/9/2016

Project launch or execution

 Resources' tasks are distributed and teams are informed of
responsibilities. This is a good time to bring up important project related
information.
 10 3/9/2016

Project Evaluation
 Afterproject tasks are completed and the client has approved the
outcome, an evaluation is necessary to highlight project success
and/or learn from project history.

 Projects and project management processes vary from industry to

industry
 11 3/9/2016

Project performance and control

 Project managers will compare project status and progress to the
actual plan, as resources perform the scheduled work. During this
phase, project managers may need to adjust schedules or do what is
necessary to keep the project on track.
 12 3/9/2016

Unified Process
 13 3/9/2016

Unified Process
 The Unified Software Development Process or Unified Process is a
popular iterative and incremental software development process
framework.
 The Unified Process is not simply a process, but rather an extensible
framework which should be customized for specific organizations or
projects. The Rational Unified Process is, similarly, a customizable
framework.
 14 3/9/2016

Unified Process
 The Unified Process divides the project into four phases:
 Inception
 Elaboration
 Construction
 Transition
 15 3/9/2016

Unified Process

Profile of a typical project showing the relative sizes of the four phases of the Unified Process.
 16 3/9/2016

Inception Phase
 Inception is the smallest phase in the project, and ideally it should be
quite short
 Goal of inception phase should be:
 Establish a justification
 Establish the project scope and boundary conditions
 Outline the key requirements that will drive the design tradeoffs
 Identify risks
 Prepare a preliminary project schedule and cost estimate
 17 3/9/2016

Elaboration Phase
 During the Elaboration phase the project team is expected to capture a
healthy majority of the system requirements.
 The primary goals of Elaboration are to address known risk factors
and to establish and validate the system architecture.
 Common processes undertaken in this phase include the creation of
all necessary diagrams. E.g use case diagrams, conceptual diagrams and
package diagrams (architectural diagrams).
 18 3/9/2016

Use case
A use case diagram at its simplest is a representation of a
user's interaction with the system and depicting the
specifications of a use case. A use case diagram can portray
the different types of users of a system and the various ways
that they interact with the system.
 19 3/9/2016

Use case diagrams

20 3/9/2016
21 3/9/2016
 22 3/9/2016

Conceptual Diagrams
A conceptual diagram is a visual representation of how a
system works
23 3/9/2016
 24 3/9/2016

Construction Phase
 Construction is the largest phase in the project. In this phase the
remainder of the system is built on the foundation laid in Elaboration.
System features are implemented in a series of short, time boxed
iterations. Each iteration results in an executable release of the
software.
 25 3/9/2016

Transition Phase
 The final project phase is Transition. In this phase the system is
deployed to the target users.
 Feedback received from an initial release (or initial releases) may
result in further refinements to be incorporated over the course of
several Transition phase iterations.
 The Transition phase also includes system conversions and user
training.
 26 3/9/2016

Requirement Analysis
 Requirement analysis in systems engineering and software
engineering, encompasses those tasks that go into determining the
needs or conditions to meet for a new or altered product, taking
account of the possibly conflicting requirements of the various
stakeholders, analyzing, documenting, validating and managing
software or system requirements
 27 3/10/2016

 "...Requirements definition is a careful assessment of the

needs that a system is to fulfil...must say why a system is
needed, based on current and foreseen conditions,
which may be internal operations or an external
market...must say what system features will serve and
satisfy this context...must also say how the system is to be
constructed...”
 28 3/9/2016

Requirement Cont’
 Requirements analysis is critical to the success of a systems or
software project. The requirements should be documented, actionable,
measurable, testable, traceable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system
design.
 3 major activities
 Eliciting Requirements
 Analysing Requirements
 Recording Requirements
 29 3/9/2016

Eliciting Requirements
 The project definition - business process documentation, and
stakeholder interviews. This is sometimes also called requirements
gathering.
 30 3/9/2016

Analyzing requirements
 Determining whether the stated requirements are clear, complete,
consistent and unambiguous, and resolving any apparent conflicts.
 31 3/9/2016

Recording requirements
 Requirements may be documented in various forms, usually including a summary
list and may include language documents and process specifications.
 32 3/9/2016

 Requirements analysis can be a long and tiring process during which

many delicate psychological skills are involved. New systems change
the environment and relationships between people, so it is important
to identify all the stakeholders, take into account all their needs and
ensure they understand the implications of the new systems.
 33 3/9/2016

Stakeholder interviews
 Stakeholder interviews are a common technique used in requirement
analysis. Though they are generally focused upon the perspectives
and perceived needs of the stakeholder, often this perspective has the
general advantage of obtaining a much richer understanding of the
stakeholder's unique business processes, decision-relevant business
rules, and perceived needs.
 34 3/9/2016

Joint Requirements Development

(JRD) Sessions
 Requirements often have cross-functional implications that are
unknown to individual stakeholders and often missed or incompletely
defined during stakeholder interviews. These cross-functional
implications can be elicited by conducting JRD sessions in a
controlled environment, facilitated by a trained facilitator
 35 3/10/2016

Types of Requirements
 Requirements
are categorized in several ways. The following are
common categorizations of requirements that relate to technical
management
 36 3/10/2016

Customer Requirements
 Statements of fact and assumptions that define the expectations of the
system in terms of mission objectives, environment, constraints, and
measures of effectiveness and suitability (MOE/MOS). The
customers are those that perform the eight primary functions of
systems engineering, with special emphasis on the operator as the
key customer.
 37 3/10/2016

Customer Requirements
 Operational distribution or deployment: Where will the system be used?
 Mission profile or scenario: How will the system accomplish its mission
objective?
 Performance and related parameters: What are the critical system
parameters to accomplish the mission?
 Utilization environments: How are the various system components to be
used?
 Effectiveness requirements: How effective or efficient must the system be in
performing its mission?
 Operational life cycle: How long will the system be in use by the user?
 Environment: What environments will the system be expected to operate in
an effective manner?
 38 3/10/2016

Types of Requirements cont

 Architectural Requirements
 Architectural requirements explain what has to be done by identifying the
necessary system architecture of a system.

 Structural Requirements
 Structural requirements explain what has to be done by identifying the necessary
structure of a system.

 Behavioral Requirements
 Behavioral requirements explain what has to be done by identifying the
necessary behavior of a system.
 39 3/10/2016

Types of Requirements cont

 Functional Requirements
 Functional requirements explain what has to be done by identifying the
necessary task, action or activity that must be accomplished. Functional
requirements analysis will be used as the top-level functions for
functional analysis.

 Non-functional Requirements
 Non-functional requirements are requirements that specify criteria that
can be used to judge the operation of a system, rather than specific
behaviors.
 40 3/10/2016

Types of Requirements cont

 Performance Requirements
 The extent to which a mission or function must be executed; generally
measured in terms of quantity, quality, coverage, timeliness or readiness.
During requirements analysis, performance (how well does it have to be
done) requirements will be interactively developed across all identified
functions based on system life cycle factors; and characterized in terms
of the degree of certainty in their estimate, the degree of criticality to
system success, and their relationship to other requirements.
 41 3/10/2016

Types of Requirements cont

 Design Requirements
 The “build to,” “code to,” and “buy to” requirements for products
and “how to execute” requirements for processes expressed in
technical data packages and technical manuals.

 Derived Requirements
 Requirements that are implied or transformed from higher-level
requirement. For example, a requirement for long range or high
speed may result in a design requirement for low weight.
 42 3/10/2016

Requirements Analysis Issues

 Stakeholderissues
 Engineer/Developer Issues
 43 3/10/2016

Stakeholder Issues
Ways users can inhibit requirements gathering:
 Users do not understand what they want or users don't have a clear idea of their
requirements
 Users will not commit to a set of written requirements
 Users insist on new requirements after the cost and schedule have been fixed
 Communication with users is slow
 Users often do not participate in reviews or are incapable of doing so
 Users are technically unsophisticated
 Users do not understand the development process
 Users do not know about present technology
This may lead to the situation where user requirements keep changing even when system
or product development has been started.
 44 3/10/2016

Engineer/Developer Issues
 Engineer/developer starts coding/implementation immediately before they really
understand the whole requirement from analyst, which usually causes lots of defect
fixing or reworking in test/verification phase.
 Technical personnel and end-users may have different vocabularies. Consequently,
they may wrongly believe they are in perfect agreement until the finished product is
supplied.
 Engineers and developers may try to make the requirements fit an existing system
or model, rather than develop a system specific to the needs of the client.
 Analysis may often be carried out by engineers or programmers, rather than
personnel with the domain knowledge to understand a client's needs properly
 45 3/10/2016

Why are Requirements Important?

 Causes of failed software Projects (Standish Group study)
 Incomplete requirements 13.1%
 Lack of user involvement 12.4%
 Lack of resources 10.6%
 Unrealistic expectations 9.9%
 Lack of executive support 9.3%
 Changing requirements & specifications 8.8%
 Lack of planning 8.1%
 System no longer needed 7.5%
Failures to understand the requirements lead the developers to build the wrong system.
 46 3/10/2016

Agile Software Development

 An innovative philosophy and methodology comprised of systems
development practices, techniques, values, and principles intended
for use in developing systems in a dynamic way
 47 3/10/2016

Agile Model Process