Software Project Management

  • Uploaded by: Kiruthivasaan
  • 0
  • 0
  • May 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Software Project Management as PDF for free.

More details

  • Words: 2,508
  • Pages: 60
Software Project Management

Definition:  Software

project management is an activity of organizing, planning and scheduling software projects.  Goal: To

deliver the project on time and on schedule.

Activities in Software project management, Project

planning Project Scheduling Risk management

Objectives:  To

explain the main tasks undertaken by project managers  To introduce software project management and to describe its distinctive characteristics  To discuss project planning and the planning process  To show how graphical schedule representations are used by project management  To discuss the notion of risks and the

Management

Planning

Organizing

Staffing

Directing

Selecting and training people for positions or roles in the organization. Arranging the relationships among work units for the accomplishment of objectives and the granting of responsibility and authority to obtain these objectives. Predetermining a course of action for accomplishing organizational objectives.

Controlling

Establishing, measuring, and evaluating performance of activities toward planned objectives.

Creating an atmosphere and environment that will assist and motivate people to achieve desired end results.

How it should go? Requirements  Analysis Design Implementation System Testing Delivery and Installation

Measures & Measurements: 

Definitions: Measurement

empirical world.

Measure

is a mapping from the world to formal, relational

is a number or symbol assigned to an entity by the mapping in order to characterize an attribute.

Direct and Indirect measurement: 

Direct Measurement of an attribute of an entity involves no other attribute or entity o Example: o

 Length

of a physical object can be measured without reference to any other object or attribute

 Indirect

Measurement

of an attribute of an entity involves other attributes or entities o Example: o

 Density

of a physical object can be measured in terms of mass and volumes.

Software Metrics 

Definition: 

Metric is a quantitative measure of degree to which a system, component or process possesses a given attribute. “A handle or guess about a given attribute.” E.g.,

Number of errors found per person hours expended

Normalization for software metrics: 

The process of combining of metrics coming from different projects depends on the size and complexity of the software.

 There

are two approaches for normalization, Size

oriented Function oriented

Why Measure Software? 

Determine the quality of the current product or process

 Predict

qualities of a product/process

 Improve

quality of a product/process

Motivation for Metrics: 

Estimate the cost & schedule of future projects

 Evaluate

the productivity impacts of new tools and techniques

 Establish

productivity trends over time

 Improve

software quality

 Forecast

future staffing needs

 Anticipate

and reduce future maintenance

Size Measure:  It

is derived by considering the size of software that has been produced.  It is built on past experiences of organisations.  It is a direct measure of software.  It is based on the lines of code computation.  The size oriented measure is not universally accepted method.

A simple set of size measure that can be developed as, Size= Kilo lines of code Effort = person/month Productivity = KLOC/person-month Quality=no.of faults/KLOC Documentation= pages of documentation/KLOC

Software cost estimation  The

process of predicting the resources required for s/w development process.  Objectives: To

introduce the fundamentals of software costing and pricing To describe three metrics for software productivity assessment To explain why different techniques should be used for software estimation To describe the principles of the COCOMO 2 algorithmic cost estimation

The Software Cost Components are,  Hardware

and Software costs  Travel and software training costs  Effort costs  Cost of building  Costs of networking  Costs of shared facilities such as library,staff

Estimation techniques: 

There is no simple way to make an accurate estimate of the effort required to develop a software system Initial

estimates are based on inadequate information in a user requirements definition. The software may run on unfamiliar computers or uses new technology. The people in the project may be unknown.  Project

cost estimates may be selffulfilling

Various Estimation Techniques: Algorithmic cost modelling  Expert judgement  Estimation by analogy  Parkinson’s law  The cost is determined by available resources rather than by objective assessment.  Pricing to win  The project costs whatever the customer ready to spend on it. 

Two approaches were,  Top

down – we start estimation at the system level and assess the overall system functionality and focuses on how it is delivered.

 Bottom

up – We start at the component level and estimate the effort required for each component.

Function Point Model Based on functionality of the delivered application.  Program characteristics were 

external

inputs and outputs; user interactions; external interfaces; files used by the system.  These

are generally independent of the programming language used.

Function Point Model  Function

points are derived using,

Countable

measures of the software requirements domain Assessments of the software complexity.  How

to calculate function points?

No.of

user inputs No.of user outputs No.of user inquiries No.of files No.of external interfaces

• ADVANTAGES: •Independent of programming language •Based on the data which can be obtained in early stage of the project. • DISADVANTAGES: • FPs are very subjective. They depend on the estimator. • Automatic function-point counting is impossible. • Many aspects of this method are not validated.

The COCOMO model:  COCOMO

stands for Constructive Cost

Model  An empirical model based on project experience.  Most widely used software estimation models in the world.  Well-documented, ‘independent’ model.  COCOMO predicts the efforts and schedule of a software product based

COCOMO has three different models that reflect the complexity,

Basic

model Intermediate model Detailed model  Similarly

there are three classes of software projects, Organic

mode Semi-detached projects Embedded projects

Basic Model  Estimates

the software development effort using only lines of code.  Basic COCOMO model is good for quick, early, rough order of magnitude estimates of software project.  Limitations: Accuracy

is limited. These factors are hardware constraints, personal quality and experience, modern techniques and tools.

Intermediate Model  Extension

of basic COCOMO model  It makes use of set of “ Cost driver attributes” to compute the cost of the software. Cost driver attributes

Product attributes Hardware attributesPersonnel attributesProject attribute

Merits : This model can be applied to almost

entire software product for easy and rough cost estimation during early stage. At the component level for obtaining more accurate cost estimation.

Limitations: Effort

multipliers are not dependent on phases. A product with many components are difficult to estimate.

Detailed COCOMO Model  Similar

to intermediate model  The experimentation with different development strategies is allowed in this model.  Four phases used were, Requirements

planning and product

design Detailed design Code and unit test Integrate test

The Delphi Method “

A method for the systematic collection and aggregation of informed judgements from a group of experts on specific questions or issues”.

 An

estimation technique intended to achieve a common agreement for estimating efforts.

 Be

familiar with its application to curriculum planning

 Appreciate

the benefits and problems of this process

The procedure is as follows,

 The

coordinator presents a specification and estimation form to each expert.  Co-ordinator calls a group meeting in which the experts discuss estimation issues.  Experts fill out forms anonymously.  Co-ordinator prepares and distributes a summary of the estimates.  Co-ordinator edits and summarizes the forms and repeat the above steps to satisfied all the forms.

Selection of expert panel

Formation of questions

Statement generation

Reduction and categorisation

Rating

Analysis and iteration

Benefits: •Good for discipline •Anonymous •Freedom from individual influence or dominance •Can reach consensus in hostile groups •Insulates from lobbying

Limitations: •Time consuming •Information only as good as experts •Drift to centre position •Needs good written communication skills •Possible manipulation •Best method for complex problems •Reliability as sole method

 The

Defining Task Network

task is a small unit of work.  The task network or an activity network is a graphical representation, with Nodes

corresponding to activities. Tasks or activities are linked if there is a dependency between them.  The

task network defn helps PM to understand the project work structure.  The PM should be aware of interdependencies among various tasks.

Technical risk

Scoping the product

Checking feasibility

Product Planning

Implementa tion

Proof of Product

Technical risk

Integration

Implementa tion

Customer feedback

Scheduling  While

scheduling the project, the project is split into no. of tasks & time & resources  Organize tasks concurrently to make optimal use of workforce.  Minimize task dependencies to avoid delays caused by one task waiting for another to complete.  Project Scheduling methods, Program

(PERT)

evaluation and review technique

With the help of PERT AND CPM the planner determine,  Critical

path  a chain of tasks that determines the duration of the project.  Time estimates for individual tasks by applying statistical model.  A Boundary time – The time required by particular task to accomplish.  Boundary time calculation helps in determining critical path. Provides

the PM to evaluate the progress of the individual tasks.

Time Line Chart  Purpose

– Emphasize the scope of individual task.  So set of tasks are given as input to the time line chart.  Also called as Gantt chart.  Developed for individual functions in the entire project.

TASK Software Development 1.Analysis 2.Design 3.Coding 4.Testing 5.Maintenance

Step 1

Step 2

Step 3

Step 4

Earned Value Analysis  EVA

is a technique of performing analysis of the software project.  It provides a common value scale of every task of software project.  The EVA acts as a measure for software project progress.  With the help of quantitative analysis made in EVA, we can know how much percentage of the project is completed.

The Earned Value Process

Define the Work

Plan the Work

Work the Plan

Collect Results Measure Performance Change Control

External Changes

Analyze Deviations Take Corrective Action

Benefits of using Earned Value:  Helps

in identifying the project performance.  Cost of performance.  Project scheduling difficulties.  Helps the project manager to take the appropriate corrective actions.

Error Tracking  Error

tracking is a process of assessing the status of the software project.  The software team performs the formal technical reviews to test the developed software  In this review various errors are identified and corrected.  Any errors that remain uncovered and are found in later tasks are called defects.

The defect removal efficiency can be defined as DRE= E / (E+D) Where, DRE is the defect removal efficiency E is the error D is the defect.

• DRE represents the effectiveness of quality assurance activities. • DRE helps the PM to assess the progress of the software project.

During error tracking activity following metrics are computed, 3. Errors per requirement specification page 4. Errors per component at the design level and at the code level 5. DRE-requirement analysis 6. DRE-architectural design 7. DRE-component level design 8. DRE-coding These error tracking metrics can also be used for better target review and testing resources.

SOFTWARE CHANGES  Software

changes is an unavoidable

process.  Software change occurs because of following reasons,  New

requirement emerge when the software is used.  The business environment changes.  Errors needs to be repaired.  New requirement must be accommodated.  The performance or reliability may have to be improved.

SPIRAL MODEL FOR SOFTWARE EVOLUTION IMPLEMENTATION SPECIFICATION

START RELEASE 1 RELEASE 2

OPERATION

VALIDATION

SOFTWARE CHANGES STRATEGIES

 SOFTWARE

MAINTENANCE:

The

changes are made in the software due to requirements.

 ARCHITECTURAL

TRANSFORMATION:

It

is the process of changing one architecture into another form.

 SOFTWARE New

RE-ENGINEERING:

features can be added to existing system and then it is reconstructed for better use.

Program Evolution Dynamics  Program

evolution dynamics is the study of the processes of system change.

 Lehman

and Belady proposed a number of laws which can be applied to all systems as they evolved.

LAW Continuing change Increasing Complexity Large program evolution Organizational stability Continuing growth

DESCRIPTION Program used in a real world environment needs to be changed After making changes, its structure tends to become complex Program evolution is a self regulating process. Over a programs life time its development and its independency is constant. User requirements and to satisfy their needs by adding functionalities to the system.

SOFTWARE MAINTENANCE  Software

maintenance is an activity program is modified after it has been put into use.

 It

is not preferred to apply major software changes to system’s architecture.

 Maintenance

is a process in which changes are implemented by either modifying the existing system’s

Need for Maintenance  Maintenance

is applicable to software developed using any software life cycle model.  The system changes and hence maintenance must be performed in,  Correct faults  Improve the design  Implement enhancement  Interface with other systems.  Replacement of old software by new software

Types of Maintenance  Corrective

maintenance – The maintenance for correcting the software faults.  Adaptive maintenance – The maintenance for adapting the changes in OS  Perfective maintenance – Modifying or enhancing the system to meet the new req  Preventive maintenance – Means

CHANGE REQUEST SYSTEM RELEASE

CHANGE MANAGEMENT

IMPACT ANALYSIS

CORRECTIVE MAINTENANCE

SYSTEM RELEASE CHANGE PLANNING IMPLEMENTATION

ADAPTIVE MAINTENANCE

PERFECTIVE MAINTENANCE

Issues in Software Maintenance  Technical

– Based on the limited understanding of system, testing and maintainability.  Management – includes organizational issues, staffing problem, process issue and outsourcing  Cost estimation – One of the major issues in software maintenance based on cost & experience.  Software maintenance measurement – Factors such as size effort, schedule,

ARCHITECTURAL EVOLUTION  Sometimes

Many Legacy Systems Need To Be Changed From A Centralized Architecture To A Distributed Architecture Like Client Server.  This process is called Architectural Evolution.  This cause changes to, Hardware

costs. Distributed system requires a fine user interface.

CASE TOOLS  Computer

aided software engineering

tools.  Automate the project management activities, manage all the work products.  The CASE tools assist to perform various activities such as analysis, design, coding and testing.  SE and PM make use of CASE tools.  CASE tools help SE to produce the high quality software efficiently.

Taxonomy of CASE Tools.  To

create an effective CASE environment various categories of tools can be developed.

 CASE By

Tools can be classified by,

function or use. By user type By stage in software engineering process.

The taxonomy of case tools were,

 Business

process engineering tools  Process modeling and management tools.  Project planning tools.  Risk analysis tools.  Project management tools.  Requirement tracing tools.  Metrics and management tools.  Documentation tools.  System software tools.  Quality assurance tools.

Contd. .  Data base management tools

Data base management tools  SCM tools.  Prototyping tools  Interface design and development tools.  Web development tools  Test management tools  Programming tools  Client/ Server testing tools  Re-engineering tools.

Related Documents


More Documents from "Kiruthivasaan"