Module 4

Introduction to Software Project Management

 INTRODUCTION
• Is Software Project Management (SPM) is different from other
projects.
• To answer this we need look some key ideas (Planning, monitoring
and control of software projects).
• All projects are meetings same Objectives.
• S/W project should satisfy real needs.
• To do so we must identify the Project’s Stakeholder and their
Objectives.
• The objectives (should be met in the aim of Project management)
• Project Objective Status (know by present status)
 1.2 WHY SOFTWARE PROJECT MANAGEMENT IMPORTANT?
• More Technically oriented students Feel (away from Code).
• Why its important to become familiar with Project Management?
• First, there is a question of money.
• Lot of money stake with ICT (information and communication and
Technology) Projects.
• UK 2002-203 (spent more on ICT Projects than Roads about Pounds 2.3
billion as opposed to 1.4 billion).
• Pounds 800 spent on ICT, means (Mismanagement means, can’t spend on
other good things Viz Hospitals etc).
• Unfortunately (Projects are not always successful).
• In US, 2003, out of 13.522 projects only a third of projects are successful.
• 82% of projects were late and 43% exceeded their budget.
• The reason (Mis-management of Projects).
• National Audit Office in UK identified (factors causing project failure
as “lack of skills and proven approach to project management and
risk management”.
 1.3 WHAT IS A PROJEC?
• Dictionary definition of Project (Planned Activity).
• Planned means (how to carryout a task before we start).
• Planning is (essence, thinking carefully about something before).
• Activities of Project (Routine maintenance, procedures documented
for consistency).
• The activities that benefit mot conventional project management lie
between two extremes as shown in figure 1.1.
• There is a boundary between the non-routine project and routine
job.
• First time you do a routine task, it will be like project.
• Project to develop a system consist of large element routines
consists of factors as follows:.
• The more, any of the factors apply to a task and the task will be more
difficult.
• Project size is important.
• 20 developers size is difficult compared to 10, lot of coordination is
required.
• The Techniques and issues for equal relevance to larger projects and
smaller projects.
• The advantage of group containing various specialists is focused on
single important task is better.
• Expertise built-up is lost during the project may lost when the team
is eventually disrupts the project.
 1.4 SOFTWARE PROJECT VERSUS OTHERS TYPES OF PROJECT
• Many techniques in general project management apply to S/W project
Management.
• Fred Brooks identified some characteristics of S/w Projects which makes
particularly difficult.
• Invisibility: Progress in software project is not immediately visible. SPM
can be seen as the process of making invisible visible.
• Complexity: Per dollar, pound or euro spent, software products contain
more complexity than other engineered artifacts.
• Conformity, software system has to conform to the requirement of human
clients.
• Flexibility, one strength of software is its flexible and easy to change.
 1.5 CONTRACT MANAGEMENT AND TECHNICAL PROJECT MANAGEMENT
• In-house Projects users and developers (work for same organization).
• Increasingly, organization give ICT development to outside developers.
• Here organization appoint (project manager)
• Project manages (technical oriented decisions to outside contractor).
• PM doesn’t worry (when project is within budget and time).
• PM deal with (more technical issues)
 1.6 ACTIVITES COVERED BY SOFTWARE PROJECT MANAGMENT
• S/w Project not only concerned (actual writing of software).
• When S/W application brought (“off the shelf”) (No S/W writing).
• But still (many activities associated with S/W will present).
• Three Successive Processes that bring a new system into being, Figure
1.2.
1. Feasibility Study:
• Assess whether (project is worth starting).
• Check it have (Valid Business case) (Gathered Requirements).
• Requirement Elicitation (Complex and Difficult).
• Stakeholders (May know aim, but not means of achievement).
• Development and operational Cost (Value of Benefits).
• Examining (Potential S/W developments).
• Assess (programme of development made).
2. Planning:
• If Feasibility study viable (start project plan).
• Larger project (we wont do detail planning at beginning).
• Create (outline plan for whole project and detail one for first stage).
• Will have more details (after first earlier stages of project to plan).
3. Project Execution:
• Now (project can be executed).
• Execution of Project contains ( Design and Implementation of sub-
phases).
• Design (making decision about product, external appearance to S/W
(user interface or internal architecture).
• Plan gives details (Activities carried out to create product).
• Planning decisions influenced by (Design decisions).
• S/W Product with 5 Major Component require (5 sets of Activities to
create them).
• Figure 1.3 shows the typical sequence of software activities
recommended in the ISO 12207.
• Figure 1.3 shows the typical sequence of software activities
recommended in the ISO 12207.
• Development (one part of project).
• S/W development carried out with following (Activities).
1. Requirement Analysis: (Requirement Elicitation or requirement
gathering) relate to (functions ex. dispatching ambulance in response to
emergency telephone call).
• Transaction time depend on H/W and S/W performance as well as
speed of human operation.
• Training to Operators (to use Computer efficiently).
• System Requirement and software requirement are two different
things.
• Resource requirement relate to application development Cost.
2. Architecute design:
• Each requirements be (identified).
• Components can be (S/W, H/W, work process).
• S/w components developed (In isolation).
• If we extend legacy software, need old architecture to connect with
new architecture.
3. Detailed Design:
• Each software components are made up of number of S/W units that
can be coded and tested.
• Detailed design of each units carried out separately.
4 Code and test: writing code and debugging individuals units through
testing.
5 Integration: combining different software and hardware components
and testing.
6 Qualification testing: Tested to check all requirements are fulfilled.
7 Installation: Installation of S/W into hardware platforms and User
training (Ex. Setting up paraments).
8 Acceptance Support: Includes correction of any errors, implementing
agreed extensions and improvements.
 1.7 PLANS, METHODS AND METHODLOGIES
• Plan based on (idea of method of work).
• Ex. For testing,
• plan is to Analyse the requirements for S/W.
 1.8 SOME WAYS TO CATEGORIZING SOFTWARE PROJECTS
• Projects differ due to (different technical products).
• Need to Identify (Characteristics of project which effect the project).
• Projects are (planned and managed).
• Other factors of Project are discussed below:
• Changes to the Characteristics of software projects:
• Characteristics of Project (Undergone drastic changes).
• Earlier (each S/W written entirely from scratch, due to reusable codes
not available).
• Now a days (every programming language support Reuse of Code).
• Ex. Customizing and extending existing code, efficiently and dynamically
linking Library routines and support for frameworks.
• Compulsory Versus Voluntary users:
• Business systems require compulsory techniques to use the system.
• Computer gaming users can use it, but its voluntary.
• Information System Versus Embedded Ssytems:
• Information systems enables staff to carry out office processes.
• Embedded Systems controls machines (Ex. Control Air-conditioning).
• A Stock control system would be an information system.
• Some systems have (elements of Both, stock control system controls
an automated warehouse).
• Generic: OS
• Domain based: BANCS – TCS , FINACLE – Infosys.
• Software Product versus services
• All the S/W products are broadly classified into software product
development Projects as shown in Figure 1.4.
• 2 broad classes are Generic software Product and Domain-Specific
software Product.
• Generic product sold to broad spectrum of customers and said to have
horizontal market.
• Examples Microsoft’s Windows operating system and oracle
corporations Oracle Data base Management software.
• Domain-Specific software sold to specific customers and said to have
vertical market.
• Ex. Banking, Telecommunication, finance and accounts and medicals.
• Domain based: BANCS – TCS , FINACLE – Infosys and AspenPlus Aspen
corporation in the chemical process simulation.
• Software product Versus Services:
• All types of Software Projects are (Broadly Classified into S/W Product development projects and S/W Services
Projects).
• 2 Broad Classes of Software projects can be classified into sub-classes as shown in figure 1.4.
• Out sourced projects
• When developing a large project, its good to outsource some parts of
the work from other companies or to other companies.
• Lack of expertise and cost of product developed by other company will
criteria for outsourcing.
• Outsourced projects are small in size and can be completed in few
months.
• Conventional project with outsourced project management is
challenging.
• Indian companies exceled in executing outsourced software projects
and earned good reputation through out the world.
• Now Indian companies are concentrating on product development as
well.
• Objective-driven develoment
• Projects may be distinguished in between produce a product or meet
the certain objectives.
• Many software projects have two stages.
• 1. Objective driven projects.
• 2. Project created as software product.
• Object-driven software developed on the basis of Fixed fees and can be
Implementation, stage based on an agreed requirement.