× back
← Previous Topic

Software Project Management

In the dynamic realm of Software Engineering, efficient and effective project management stands as a cornerstone for successful software development. This unit delves into the multifaceted domain of Software Project Management, exploring key elements that form the management spectrum—encompassing the intricate interplay between people, products, processes, and projects. From the pivotal aspects of cost estimation, project scheduling, and staffing to the meticulous considerations of software configuration management, quality assurance, and risk management, the course offers a comprehensive examination of the managerial responsibilities inherent in guiding software development endeavors. Furthermore, the exploration extends to Computer-Aided Software Engineering (CASE), shedding light on its broad scope, integral role in the software life cycle, and diverse applications in areas such as documentation, project management, internal interface, reverse software engineering, and the architecture of the CASE environment. Aspiring software engineers will gain a profound understanding of the pivotal role played by management in navigating the intricate landscape of software development, ensuring successful project outcomes in a rapidly evolving technological landscape.

The Management Spectrum - The Four Ps (People, Product, Process, Project)

Effective software project management encompasses four critical components known as the Four Ps: People, Product, Process, and Project. Addressing these elements is vital in software project planning and product development. Let's delve into each of the 4 Ps in software project planning:

The People

People are at the core of software engineering, and recognizing the human factor is vital for project management success. The People Capability Maturity Model (People-CMM) defines key practice areas, including staffing, communication, work environment, performance management, training, compensation, competency analysis, career development, team culture development, and others. Roles in software project planning may include project manager, team leaders, stakeholders, analysts, and other IT professionals, requiring adept management skills.

The Product

Establishing product objectives and scope, considering alternative solutions, and identifying technical and management constraints are crucial steps before project planning. Objectives define the overall goals for the product, while scope identifies the primary data, functions, and behaviors of the product. Collaboration among software developers and stakeholders is essential in this phase to ensure a comprehensive understanding of the product's objectives and scope.

The Process

The software process serves as the framework for development, encompassing a small number of framework activities applicable to all software projects. These activities include documentation, implementation, deployment, and interaction phases. Each step in the process contributes to a well-organized and structured approach to software development, ensuring the quality and reliability of the final product.

The Project

Project planning is an indispensable phase for managing the complexities of software development. Project managers play a critical role in guiding team members, ensuring alignment with project goals, addressing issues, monitoring costs and budgets, and maintaining adherence to deadlines. The success of the project hinges on effective project management, emphasizing collaboration, adaptability, and meticulous planning.

Cost Estimation

Cost estimation is a crucial aspect of software project management that involves predicting the resources and financial investment required for the successful completion of a software development project. It aims to provide accurate and reliable forecasts, enabling project managers and stakeholders to make informed decisions about budgeting, scheduling, and resource allocation. Various techniques, both empirical and heuristic, are employed to estimate costs, each with its strengths and limitations. Empirical techniques, such as expert judgement and Delphi estimation, leverage the insights of experienced professionals. On the other hand, heuristic techniques like COCOMO (Constructive COst estimation MOdel) use systematic models to refine estimates based on project characteristics. Effective cost estimation contributes to better project planning, risk management, and overall project success.

A. Empirical Estimation Techniques

Empirical estimation techniques are user-friendly and provide reasonably accurate estimates.
Empirical estimation techniques often involve analyzing data from previous projects that are similar in nature to the one being estimated. This can include factors such as the size of the project, complexity, team expertise, and other relevant variables.
Two widely used techniques include:

  • (i) Expert Judgement

    In this technique, an expert analyzes the problem thoroughly and makes educated guesses about the problem size. The expert estimates costs for different components (modules or subsystems) and combines them for an overall estimate. However, this method has shortcomings such as susceptibility to human errors, individual bias, potential oversight of factors, and the lack of relevant experience or knowledge by the expert.

  • (ii) Delphi Cost Estimation

    Delphi estimation involves a team of experts and a coordinator. Each estimator receives a copy of the software requirements specification (SRS) document and a form for recording cost estimates. Estimators anonymously submit their individual estimates to the coordinator, who compiles a summary of responses. This summary is shared with the estimators, and the process is iterated for several rounds. The purpose is to prevent undue influence and bias. While time-consuming, Delphi estimation overcomes significant shortcomings of the expert judgement technique.

B. COCOMO - A Heuristic Estimation Technique

Constructive COst estimation MOdel (COCOMO), proposed by Boehm, outlines a three-stage process for project estimation, refining the initial estimate to a more accurate one. COCOMO employs both single and multivariable estimation models at different stages:

  • 1. Basic COCOMO

    Initial estimates are made in this stage, considering factors such as application program understanding, team size, and experience.

  • 2. Intermediate COCOMO

    This stage refines the estimate further, accounting for a mix of experienced and inexperienced staff with potentially limited experience.

  • 3. Complete COCOMO

    The final stage involves a comprehensive estimation process, especially suitable for projects strongly coupled to hardware or subject to strict operational regulations.

Boehm classifies software development projects into three categories:

  • Organic

    Characterized by a well-understood application program, a small development team, and experienced team members.

  • Semidetached

    Consists of a mixture of experienced and inexperienced staff, with team members having limited experience.

  • Embedded

    Applicable to projects strongly coupled to hardware or subject to strict operational procedures, with team members potentially having limited experience.

Basic COCOMO Model

The basic COCOMO model provides an approximate estimate of project parameters, aiding in effective project planning. The estimation model is expressed by the following formulas:

Effort = a1 × (KLOC)^a2 PM
Tdev = b1 × (Effort)^b2 Months

Where:
- KLOC: Size of the software product in Kilo Lines of Code.
- a1, a2, b1, b2: Constants for each category of software products.
- Tdev: Estimated time to develop the software in months.
- Effort: Total effort required to develop the software product, expressed in person months (PMs).

Effort is represented by the area under the person-month curve, as illustrated in the figure:

Person-month curve
Fig. Person-month curve

It's important to note that an effort of 100 PM doesn't imply 100 persons working for 1 month or 1 person working for 100 months. Instead, it denotes the area under the person-month curve.

Every line of source text is considered as one LOC (Line of Code), regardless of the actual number of instructions on that line. For estimating development effort based on code size, the formulas for the three classes of software products are:

  • Organic: Effort = 2.4(KLOC)^1.05 PM
  • Semi-detached: Effort = 3.0(KLOC)^1.12 PM
  • Embedded: Effort = 3.6(KLOC)^1.20 PM

Estimation of development time for each class follows these formulas:

  • Organic: Tdev = 2.5(Effort)^0.38 Months
  • Semi-detached: Tdev = 2.5(Effort)^0.35 Months
  • Embedded: Tdev = 2.5(Effort)^0.32 Months

As an example, if the size of an organic type software product is estimated to be 32,000 lines of source code and the average salary of software engineers is Rs. 15,000/- per month, the effort required to develop the software product and the nominal development time can be calculated using the basic COCOMO estimation formula for organic software:

Effort = 2.4 × (32)^1.05 = 91 PM
Nominal development time = 2.5 × (91)^0.38 = 14 months
Cost required to develop the product = 14 × 15,000 = Rs. 210,000/-

Project Scheduling

The project manager plays a crucial role in ensuring the timely completion of tasks and implementing corrective actions whenever there is a risk of schedule deviation. To effectively schedule project activities, a software project manager follows these steps:

  1. Identify all major activities.
  2. Break down each activity into tasks.
  3. Determine the dependencies among different tasks.
  4. Establish time estimates for the tasks.
  5. Represent the information in the form of an activity network.
  6. Determine task starting and ending dates.
  7. Determine the critical path, which is a chain of tasks determining the project's duration.
  8. Allocate resources to tasks.

The initial step involves identifying all activities necessary for project completion, with a deep understanding of project details aiding in this process. Activities are then broken down into logical subactivities, with the smallest units called tasks, assigned to different developers.

Once activities are broken down, determining task dependencies is crucial. Dependencies dictate the order in which tasks are carried out. If Task A relies on the results of Task B, Task A must be scheduled after Task B, and A is considered dependent on B.

Activity Networks

An activity network visually represents project activities, their estimated durations, and interdependencies. Two equivalent representations are in use:

  • Activity on Node (AoN): Each activity is a rectangular node showing its duration, with directional edges indicating inter-task dependencies.
  • Activity on Edge (AoE): Tasks are associated with edges, marked with task duration. Nodes represent project milestones.

Critical Path Method (CPM)

CPM and PERT, developed in the late 1950s, are operation research techniques. The Critical Path is a sequence of dependent tasks that must be performed in order, taking the longest time to complete.

Staffing in Software Projects

Staffing plays a critical role in the success of software projects. The composition of a project team, particularly the selection of team members, has a profound impact on the overall productivity and outcome of the project. Project managers are tasked with the responsibility of choosing individuals with the right skills, knowledge, and qualities to ensure effective collaboration and successful project delivery.

1. Team Member Selection:

2. Importance of Good Developers:

3. Qualities of a Good Software Engineer:

4. Sackman's Experiment [1968]:

Selecting the right team members with the requisite skills and qualities is fundamental to the success of software projects. Effective collaboration among skilled individuals can significantly enhance productivity and contribute to the timely and successful completion of projects.

Software Configuration Management

Software configuration management (SCM) is crucial for maintaining the state of project deliverables throughout the software life cycle. It involves controlling and tracking changes to software artifacts, ensuring the integrity of the software configuration and facilitating the development process.

1. Definition of Software Configuration:

2. Objects and Changes in Software Configuration:

Software Configuration Management Activities:

  • Configuration Identification: Deciding which parts of the system should be monitored.
  • Configuration Control: Ensuring that changes to the system occur smoothly.

Configuration Identification Details:

  • Objects are classified into three categories: controlled, precontrolled, and uncontrolled.
  • Controlled objects are under configuration control, precontrolled objects will be under control, and uncontrolled objects are not subject to control.
  • Typical controllable objects include requirements specification documents, design documents, source code, test cases, etc.

Configuration Control Details:

  • Configuration control: The process of managing changes to objects.
  • Directly affects day-to-day operations of developers.
  • Developers get private copies of modules to make changes.
  • Only one person can reserve a module at any time.
  • Once an object is reserved, others cannot reserve it until the reserved module is restored.

Quality Assurance

Software quality assurance (SQA) is a comprehensive approach that encompasses various processes and tasks to ensure the quality of software development. It includes quality assurance planning, oversight, record-keeping, analysis, reporting, and adherence to standards.

SQA Tasks, Goals, and Metrics

Software quality assurance involves tasks, goals, and metrics related to both software engineers and the SQA group responsible for quality assurance planning. Modern SQA is data-driven, emphasizing solid technical methods, technical reviews, and well-planned software testing.

A. SQA Tasks

  • Prepares an SQA plan for a project, identifying tasks, audits, reviews, and standards.
  • Participates in the development of the project’s software process description, ensuring compliance.
  • Reviews software engineering activities to verify compliance with the defined software process.
  • Audits selected work products, identifies deviations, and reports results to the project manager.
  • Ensures deviations in software work and work products are documented and handled.
  • Records noncompliance and reports to senior management, tracking items until resolution.

B. Goals, Attributes, and Metrics

Specific SQA activities are performed to achieve pragmatic goals:

  • Requirements quality: Ensuring correctness, completeness, and consistency of the requirements model.
  • Design quality: Assessing every element of the design model for high quality and adherence to specifications.
  • Code quality: Ensuring source code and related work products conform to coding standards.
  • Quality control effectiveness: Analyzing resource allocation for achieving high-quality results.

Risk Management

Every project faces numerous risks, and effective risk management is crucial for ensuring the success of a project. The project manager needs to identify potential risks and formulate plans to address them.

Risk Management Approaches

Risk management approaches can be broadly classified into reactive and proactive approaches.

Reactive Approaches

Reactive approaches take action only after an unfavorable event occurs, focusing on preventing future occurrences of similar events.

Proactive Approaches

Proactive approaches aim to identify possible risks early in the project. Actions are taken to eliminate or reduce the risks, and plans are made to mitigate their impact if unavoidable.

Risk Identification

Early identification of risks is crucial for effective risk management. Risks are categorized into project risks, technical risks, and business risks.

  • Project risks: Project risks concern various forms of budget, schedule, personnel, resource, and customer-related problems. An important project risk is schedule slippage.
  • Technical risks: Technical risks concern potential design, implementation, interfacing, testing, and maintenance problems. Technical risks also include ambiguous specification, incomplete specification, changing specification, and technical uncertainty.
  • Business risks: This type of risks includes the risk of building an excellent product that no one wants, losing budgetary commitments, etc.

Risk Assessment

Risk assessment involves rating each risk based on its likelihood of occurrence and the consequence of associated problems. Prioritization is done using the formula: p = r × s (where p is the priority, r is the probability, and s is the severity).

Risk Mitigation

Three main strategies for risk mitigation are:

  • Avoid the risk by modifying project constraints.
  • Transfer the risk through third-party development or insurance.
  • Risk reduction by planning ways to cover potential damage.

Boehm’s Top 10 Risks and Counter Measures

Barry Boehm identified the top 10 risks in a project and suggested counter measures:

  1. Personnel shortfall: Hire top talent, job matching, and team building.
  2. Unrealistic schedules and budgets: Rely on experienced project managers.
  3. Developing the wrong functions: Use user surveys, prototypes, and user feedback.
  4. Developing the wrong user interface: Employ prototyping, scenarios, and user participation.
  5. Gold-plating: Implement requirements scrubbing, prototyping, and cost-benefit analysis.
  6. Continuing stream of requirements changes: Embrace incremental development.
  7. Shortfalls in externally-furnished components: Utilize benchmarking, inspections, and compatibility analysis.
  8. Shortfalls in externally performed tasks: Apply reference checking, audits, and competitive design.
  9. Real-time performance shortfalls: Use simulation, benchmarking, modeling, and prototyping.
  10. Straining computer science capabilities: Employ technical analysis, cost-benefit analysis, and prototyping.

Role of Management in Software Development

The project manager plays a crucial role in the success of any software development project. The key responsibilities include:

CASE

CASE and its Scope

Computer-Aided Software Engineering (CASE) tools provide automated support for various activities in software engineering. The scope of CASE tools is broad, encompassing a range of tasks associated with software development.

Key Definitions:

"A CASE tool is a form of automated support for software engineering."

"A CASE tool can mean any tool used to automate some activity associated with software development."

Several CASE tools are available, serving both phase-related tasks such as specification, structured analysis, design, coding, testing, etc., and non-phase activities like project management and configuration management.

The primary objectives of using CASE tools are:

CASE Support in Software Life Cycle

CASE tools play a crucial role in various phases of the Software Development Life Cycle (SDLC). The following highlights some of the key support areas provided by CASE tools:

Prototyping Support

Prototyping is essential for understanding the requirements of complex software products. An effective prototyping CASE tool should include the following features:

  • Graphics editor for creating GUI elements.
  • Integration with the CASE environment's data dictionary.
  • Ability to integrate with external user-defined modules.
  • User control over defining prototype states and running sequences.

Structured Analysis and Design

A CASE tool should support one or more structured analysis and design techniques, providing features such as:

  • Effortless drawing of analysis and design diagrams.
  • Hierarchical drawing of complex diagrams.
  • Easy navigation through different levels of hierarchy.
  • Completeness and consistency checking across the design and analysis at all levels.

Code Generation

During the code generation phase, a CASE tool is expected to:

  • Support the generation of module templates in popular languages.
  • Include essential details like copyright message, module description, author name, and creation date.
  • Automatically generate records, structures, and class definitions from the data dictionary.
  • Generate database tables and code for the user interface based on prototype definitions.

Test CASE Generator

The CASE tool for test case generation should feature:

  • Support for both design and requirement testing.
  • Generation of test set reports in ASCII format for direct import into the test plan document.

Documentation

The documentation process is a crucial aspect of software development, encompassing the creation and organization of deliverable documents that provide a comprehensive understanding of the project. An effective CASE tool supporting documentation should enable graphical organization, seamless incorporation of text and diagrams, integration with desktop publishing packages, and the ability to export content to standard forms. This ensures clarity and accessibility in conveying project details and facilitates collaboration among team members and stakeholders.

Documentation Support

  • Organize deliverable documents graphically
  • Incorporate text and diagrams
  • Integrate with desktop publishing packages
  • Export text, graphics, tables, and data dictionary reports to DTP packages in standard forms

Project Management

  • Collect, store, and analyze information on software
  • Include estimated task duration, scheduled and actual task start and completion dates
  • Record dates and results of reviews

External Interface

  • Facilitate the exchange of information
  • Enhance reusability of designs

Reverse Engineering Support

  • Support generation of structure charts and data dictionaries from existing source codes
  • Include conversion tools from indexed sequential file structures, hierarchical and network databases to relational database systems

Architecture of CASE Environment

The architecture of a modern CASE (Computer-Aided Software Engineering) environment plays a pivotal role in facilitating the software development process. The entire system is designed to enhance collaboration, streamline tasks, and improve the overall efficiency of the development lifecycle. A fundamental component of this architecture is the user interface, providing a unified and consistent framework. This ensures seamless interaction between users and the diverse array of tools integrated into the environment. The Object Management System and Repository form the backbone, translating logical entities like specifications and designs into a cohesive structure within the storage management system, known as the repository.

The architecture of a modern CASE environment is illustrated in the figure below:

Architecture of a modern CASE environment
Architecture of a modern CASE environment.

User Interface

Object Management System and Repository

Different CASE tools represent the software product through entities such as specifications, designs, text data, project plans, etc. The object management system maps these logical entities into the underlying storage management system, known as the repository.