Software Project Management

Software maintenance
The typical life span for a software product is 1 to 3 years in development and 5 to 15 years in use (maintenance). The distribution of effort between development and maintenance has been variously reported as 40/60, 30/70 and even 10/90. This is not surprising when it is understood that maintenance comprises all activities following initial release of a software product.
Software maintenance involves three types of activities
1. enhancing the capabilities of the product
2. adapting the product to new processing environments
3. correcting bugs.

Distribution of effort in software life cycle.
Analysis and design 16% Implement 8%
Test 16% Adapt 12%
Enhance 36% Fix 12%

Project size categories
Trivial projects :- A trivial software project involves one programmer working perhaps part time, for a few days or a few weeks and results in paprogram of less than 500 statements, packaged in 10 to 20 subroutines. Such programs are often personal software; they are developed for the exclusive use of the programmer and are usually discarded after a few months.

Small projects :- A small project employs one programmer for 1 to 6 months and results in a product containing 1000 and 2000 lines of source code packaged in perhaps 25 to 50 routines. A small project requires little interaction among programmers or between programmers and customers. Standardized techniques and notations, standardized documents, and systematic project reviews should be used even on small projects, but the degree of formality will be much less than is required on larger projects.

Medium size projects :- A project of medium size requires two to five programmers working for 1 to 2 years and results in 10,000 to 50,000 lines of source code packaged in 250 to 1000 routines. Medium size programs include assemblers, compilers, small management information systems, inventory systems and process control applications. Development of medium size projects required interaction among programmers and communication with customers. Thus, a certain degree of formality is required in planning, documents & project reviews.

Large projects :- A large project requires 5 to 10 programmers for a period of 2 to 3 years and results in a system of 50,000 to 1,00,000 source statements, packaged in several subsystems. It often has significant interactions with other programs and software systems. For example large compilers, small time-sharing systems, database packages, real time control system etc.

Very large projects :- It requires 100 to 1000 programmers for a period of 4 to 5 years and results in software of 1 million source instructions. It normally consists of several sub systems. For example large operating systems, large database systems, military command and control systems.

Extremely Large projects :- 2000 to 5000 programmers for periods of up to 10 years and results in 1 million to 10 million lines. It involves real time processing, telecommunications, multitasking and distributed data processing. For example air traffic control, ballistic missile defense etc.

Factors that influence quality and productivity
1. Individual ability
2. Team communication product complexity
3. Appropriate notations
4. Systematic approaches
5. Change control
6. Level of technology
7. Required reliability
8. Available time
9. Problem understanding
10. Stability of requirements
11. Required skills
12. Facilities and resources
13. Adequacy of training
14. Management skills ( page 23 ) management problems / methods to solve the problems.
15. Appropriate goals
16. Rising expectations

Quality attributes
Portability :- The ease with which software can be transferred from one computer system or environment to other.
Reliability :- The ability of a program to perform a required function under stated conditions for a stated period of time.
Efficiency :- The extent to which software performs its intended functions with minimum consumption of computing resources.
Robustness :- The extent to which software can continue to operate correctly despite the introduction of invalid inputs.

Factors to be considered in project planning
Estimation techniques to be used
Life cycle model, control functions
Organizational structure
Level of formality in specifications, test plans.
Level of verification and validation
Level of quality assurance required
Follow-up of maintenance responsibilities
Tools to be developed and used
Personnel recruitment and training

Outline of user's manual
Product overview and rationale
Terminology and basic features
Summery of display and report formats
Outline of the manual
Getting started
Sign-on
Help mode
Sample run
Modes of operations
Commands / dialogues / reports
Advanced features
Command syntax and system options

Format of project legacy
Project description
Initial expectations
Current status of the project
Remaining areas of concern
Activities / time log
Technical lessons learned
Managerial lessons learned
Recommendations for future projects

SPM for MCM - II
What is Software Engineering?
Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates.

Who is a Programmer?
Programmer is an individual who is concerned with the details of implementing, packaging and modifying algorithms and data structures written in particular programming languages.

Software is
1. Instructions that when executed provide desired function and performance
2. Data structures that enable the programs to adequately manipulate information
3. Documents that describe the operations and use of the programs.

What is a Computer Software?
Computer software includes the source code and all the associated documents and documentation that constitute the software product. Requirements documents, design specifications, source code, test plans, principles of operations, quality assurance procedures, software problem reports, maintenance procedures, user's manuals, installation instructions and training aids are components of computer software.

Software is a logical rather than a physical system element. It has many different characteristics that differ considerably from those of hardware
1. Software is developed or engineered, it is not manufactured in the classical sense.
2. Software doesn't wear out
3. Most software is custom-built, rather than being assembled from existing components.

Normally software is of two types i.e. system software and application software. It is difficult to develop meaningful generic categories for software applications … still
1. System software
2. Real - time software
3. Business software
4. Engineering and scientific software
5. Embedded software
6. Personal computer software
7. Artificial intelligence software

Home Work ( write in details about above categories - Pressman - Page 15 )

What is Management
Planning, Staffing, Co-ordination, Decision Making, Control

System Development life cycle ( Discuss on your own )

Project Management
Project management focuses on project. A project is an undertaking that has beginning and end and is carried out to meet established goals within cost, schedule and quality objectives.

Project life cycle : Each project moves through a predictable life cycle of four phases.
1. Conceiving and defining the project
2. Planning the project
3. Implementing the project
4. Completing and evaluating the project.

Format of a project plan
Life cycle model ( terminologyies / milestones / work products )
Organizational structure ( team structure / work breakdown )
Preliminary staffing and resource requirements
Pert network / Gantt charts
Cost estimate
Project monitoring and control mechanisms
Tools and techniques to be used.
Programming languages
Testing requirements
Supporting documents required
Manner of demonstration and delivery
Trainging schedule and materials
Installation plan
Maintenance considerations
Method and time of delivery and payment
Sources of information

During project's life one must consider following basic parameters
1. Quality (Software quality chapter)
2. Cost (Estimation chapter)
3. Time

Time aspect of project
The objective when planning the time dimension is to determine the shortest time necessary to complete the project. The steps in planning the time aspect are
Begin with work break down structure.
Determine the time required to complete each sub unit.
Determine in what sequence the sub unit must be completed
Which sub units may be under way at the same time.
The above analysis will give you
The duration of each step
The earliest time at which the step may be started and
The latest time at which the step must be started.
A mathematical model can be used to estimate time
Tm : The most probable time
To : The optimistic (shortest) time - within which only 1% of simolar projects are completed.
Tp : The pessimistic (longest) time within which 99% of similar projects are completed.
Te : The calculated time estimate.

Formelae : Te = (To + 4 Tm + Tp) / 6
Till now we talked about general projects. Software Projects are not different from that. Software project revolves around three "P"s
1. People
2. Problem
3. Process

Before going to discuss the three "P"s one by one first let us study the Typical Software Plan
Introduction (Purpose / scope / objectives)
Estimation (Effort / cost / duration)
Risk management
Schedule - Work breakdown
Project resources

People
Considering the overall picture, people involved in software project can be categorized into following groups
1. Senior managers :- who defines the business issues that often have significant influence on the project.
2. Project managers (technical) :- responsible for planning, motivating, organizing and controlling the software practitioners.
3. Practitioners :- who deliver the technical skills.
4. Customers :- who specify the requirements.
5. End users :- who interact with the software once it is released.

Software Project - Team Leader
Motivation Organization Ideas or innovations
Problem solving Managerial identity Influence and team building

The Software Teams
Three generic team organization structures are used in software project such as
Democratic Decentralized (DD)
1. This software team has no permanent leader. Rather, "task co-ordinators are appointed for short duration.
2. Decisions on problems are made by group consensus.
3. Communication among team members is horizontal.
4. Informal atmospheres
5. Problems of complex nature are best handled by such teams.

Controlled Decentralized (CD)
1. It has a specific leader who co-ordinates specific task where secondary leaders are responsible for sub tasks.
2. Problem solving remains a group activity.
3. Communication among subgroups and individuals is horizontal. Vertical communication along the control hierarchy also occurs.
4. This structure is best suited for large projects.

Controlled Centralized (CC)
1. It is also called as Chief Programmer Team
2. This structure is characterized by heavy dependence on Chief Programmer as top level problem solving and internal team coordination are managed by team leader.
3. Vertical communication.
4. This is suited for problems which are well-understood.

Extra related with team building
Following points are taken into consideration at the time of team building
Difficulty of the problem
Size of the programs
Team lifetime (how long members will stay together)
Modularization of the problem
Required quality and reliability of the system
Rigidity of the delivery date
*** Also refer chart - Pressman - Page 63

Size of the Team
Programming team size should be small. It reduces communication problems, leads to egoless programming, and results in close relationships amongst the team members. A typical team should not have more than 8 members. If a large project demands more people, then there can be multiple teams.

Problem (The scope of the problem must be established and bounded. One have to consider following things while solving the problem)

Software scope : It can be defined by answering further questions.
1. Context :- how does the software to be built fit into a larger system, product or business context, and what constraint are imposed as the result of the context.
2. Information objectives :- What customer-visible data objects are produced as output from the software? What data objects are required for input.
3. Function and performance :- What function does the software perform to transform input data into output? Are any special performance characteristic to be addressed?

Problem decomposition or Work Break down : It is also called as partitioning , it an activity that sits at the core of software requirements analysis. During the scoping activity there is no attempt to fully decompose the problem. Rather, decomposition is applied in two major areas i.e functionality that must be delivered and the process that will be used to deliver it.
It means breaking the project into smaller manageable activities. The structure is a typical tree structure. The decomposition is done until each leaf-node in the tree is small enough to allow the manager to estimate the size, difficulty and resource requirements. It also helps in preparing schedules through Gantt and PERT effort, Time and ultimately Cost estimation are facilitated by work breakdown structure.

Milestones : Important events in the project development are the initiation and termination of certain sub tasks, are called as milestones. A good milestone is characterized by finished documentation of that stage. A milestone may be "High level design complete" or "Preparation of test plan" etc. Milestones help in clearly identifying the stages of a project. A new concept is creeping called as inch-pebbles.

Charting techniques : Two commonly used methods for charting the project.
Gantt Chart : Introduced by henry Gantt, industrial engineer, in early 1900's. It is a horizontal bar chart that graphically displays the time relationship of the steps in a project. Each step of a project is represented by a line placed on the chart in the time period when it is to be undertaken. When completed, Gantt chart shows the flow of activities in sequence as well as those that can be under the way at the same time. Gantt charts are limited in their ability to show the interdependencies of activities. They are more useful in projects where the steps flow in simple sequence. (Refer Diagram - Mulay - page 17)

PERT & CPM : These techniques are useful in basic managerial functions of planning, scheduling and control.

Process
SDLC Approaches
Linear approach
Spiral model
Prototyping
4GT
RAD
Component assembly model
Concurrent development model

Project Estimation
Estimating the cost of a software product is one of the most difficult and error-prone tasks in software engineering. It is difficult to make an accurate cost estimate during the planning phase of software development because of large number of unknown factors.

Factors to be considered while estimating
Programmer Ability :
Time spend by programmers in the organization
Writing programs 13 % Reading programs and manuals 16%
Job communication 32% Personal 13 %
Miscellaneous 15 % Training 6% Mail 5%

Project Complexity (Relative term)
Project Size
The degree of uncertainty (Situational)
Availability of historical information (Situational)
Risk involved (by experience)
Required Quality aspects (Refer quality chapter)
Time available (Refer - Time aspect of project - Formula)
Level of technology

Project Size
Software sizing is project planners first major challenge. In the context of the project planning, size refers to a quantifiable outcome of the software project. Size can be measured in LOC (Lines Of Code)

Size categories for software products

Category Programmers Duration Product Size
Trivial 1 1-4 weeks 500 loc
Small 1 1-6 months 1k - 2k
Medium 2-5 1-2 years 5k - 50k
Large 5-20 2-3 years 50k - 100k
Very large 100-1000 4-5 years 1M
Extremely large 2000-5000 5-10 years 1M - 10 M

Cost estimation techniques
All these estimations techniques are having certain advangates and disadvantages. These techniques are normally selected depending upon the size of the project.

1. Estimation by analogy : This model uses historical data ( history and experience of previously developed software) to achieve some real figures to estimate.
2. Experts judgement : based on past experience or intution of experts in the field.
3. Delphi technique
4. Provide system definition to expert panel
5. Allow question form panelist
6. Do not allow discussions amongst panelist
7. Collect individual estimates
8. Find out average and deviation
9. If too much variation found amongst panelists restart from the first step of the technique by them the details about average opinion. This cycle is processed until the group reaches an agreement.
10. Pricing to win : Depends upon customers budget.
11. Top down estimation
12. Bottom up estimation

Four different approaches of sizing the project
Fuzzy logic sizing : use historical data and experience to size the project.
Function point sizing : Analyse the project - break down the project in modules - estimate function points for various modules.
Standard component sizing : Standard components such as files, screens, reports, validations, GUI standards are calculated - depend upon that LOC is calculated.
Change sizing : in case of reuse software components, the amount of change required in the code is calculated.

COCOMO

Chapter 4
Software Maintenance

There is only one thing, which is stable and that is "Change"

Changes in the existing system may be required because
Dynamism of the environment
Changes in the management
Technological factors
To remove deficiencies
To improve

Definition : Using today's technology for yesterday's programs for tomorrows success.

Maintenance is normally a problematic aspect as
Turnover
Documentation
Design ( as original design is not designed for maintenance )
Ignored tasks

Effects of maintenance is on :- data - code - documents.

Stages of Change
Un-freeze Change Freeze
Struggle - understand entire concept. - Design reviews - identify problem

The term maintenance or maintainability means
Understood - Correct - Adapt - Enhance

It is very difficult to quantify maintenance. Generally following things are taken into consideration at the time of calculating maintenance.
Problem recognition time Administration delay time
Maintenance tool arrangement time Problem analysis time
Change specification time Modification time
Local testing time Global testing time
Maintenance review time Total recovery time

Maintenance Plan - Steps
Request for change - request logs
Evaluate design
Plan for effective change
Assign responsibilities
Modify design
Recode
Review
Test and release