GTU 3171609 Software Project Management Summer 2025 Solved Paper & Solutions

Software Project Management is the activity of planning, organising, monitoring and controlling a software project so that it is finished on time, within budget and with the quality the customer wants.

• It covers scope, schedule, cost, quality, people, risk and communication.
• A software project is harder to manage than other projects, because the product is invisible, requirements change often, and the work is complex.
• The person who does this is the project manager.

Software can be categorised in several ways.

By type of software

• System software: operating systems, compilers and drivers.
• Application software: word processors, banking and shopping apps.
• Embedded software: software inside a machine, such as a washing machine or a car.
• Web and mobile apps: software that runs in a browser or on a phone.

By the way the project is run

1. Compulsory or voluntary users: in a compulsory system, users must use it, for example a payroll system. In a voluntary system, users choose whether to use it, for example a game.
2. Information systems or embedded systems: an information system supports office work. An embedded system controls a machine and works in real time.
3. Objective-based or product-based: an objective-based project meets a business goal. A product-based project builds a product for many buyers.

Each category needs a different management approach.

A project goes through a set of phases from its start to its end. The usual project management life cycle has five phases. Each phase ends with a review before the next one starts, so the stakeholders can decide whether to continue.

The five phases

1. Initiation: the project is defined. The business need and the feasibility are studied, the objectives and the scope are stated, and the project manager and the stakeholders are named. The result is a project charter.
2. Planning: the work is planned in detail. The team makes the work breakdown structure, the schedule, the cost and effort estimates, the risk plan, the quality plan and the resource plan. This is the baseline against which progress is measured.
3. Execution: the plan is carried out. The team analyses, designs, builds and tests the software, and the manager leads the people and coordinates the work.
4. Monitoring and control: this runs in parallel with execution. The manager compares actual progress with the plan, checks cost, schedule and quality, manages changes and risks, and takes corrective action.
5. Closure: the product is handed over and the customer accepts it. The team releases the resources, completes the documents, and records the lessons learned.

Monitoring and control continues throughout execution and may send the project back to planning when the plan has to change.

PERT (Programme Evaluation and Review Technique) is a method of scheduling that uses three time estimates for each activity, because the duration is uncertain.

• Optimistic time $a$, most likely time $m$ and pessimistic time $b$.
• Expected time: $t_e = \dfrac{a + 4m + b}{6}$.
• Variance: $\sigma^2 = \left(\dfrac{b - a}{6}\right)^2$.

Example: for an activity, $a = 2$, $m = 4$ and $b = 12$ days.

The activity is planned for 5 days. The project duration is the sum of the expected times along the critical path.

Software prototyping is the building of a quick, working model of the software, so that users can see and try it before the real system is built. It is used when the requirements are unclear.

Steps

1. Gather the basic requirements.
2. Build a quick design and the prototype.
3. The user tries the prototype and gives feedback.
4. The prototype is refined until the user is satisfied.
5. The final product is built.

Types

• Throwaway prototype: used only to understand requirements, then discarded.
• Evolutionary prototype: improved step by step until it becomes the final system.

Advantages: it reduces misunderstanding, gives early feedback, and lowers the risk of building the wrong product.

Disadvantages: users may think the prototype is the finished product, and poor quick designs may remain in the final system.

Role of cost estimation

Cost estimation predicts the effort (in person-months), time and money needed for a project. It is done before and during the project.

• It helps the customer and the company to agree on a price and to decide whether to start.
• It is the basis of the schedule, staffing and budget.
• It shows the risk of a project early, so it can be controlled.
• It is used to track the project, since the actual cost is compared with the estimate.
• An estimate is never exact, so it is improved as more is known about the project.

COCOMO model

COCOMO (Constructive Cost Model) was proposed by Barry Boehm. Basic COCOMO estimates effort $E$ in person-months and development time $D$ in months from the size of the software in thousands of lines of code (KLOC).

It gives three categories (modes) of project.

• Organic: small teams, a familiar problem and a relaxed environment, usually under 50 KLOC. $a = 2.4$, $b = 1.05$, $c = 2.5$, $d = 0.38$.
• Semi-detached: a mix of experienced and new people and a medium-size system, between organic and embedded. $a = 3.0$, $b = 1.12$, $c = 2.5$, $d = 0.35$.
• Embedded: tight hardware, software and operating limits, and a complex system. $a = 3.6$, $b = 1.20$, $c = 2.5$, $d = 0.32$.

Example: an organic project of 32 KLOC.

The team size is about $91.3 / 13.9 = 6.6$, so about 7 people.

Intermediate and detailed COCOMO add cost drivers such as product, hardware, personnel and project attributes.

The steps of project planning are:

1. Define scope and objectives: state what the project must deliver.
2. Identify the activities and products: break the work into tasks.
3. Estimate effort and cost: find the time, people and money for each task.
4. Identify risks: list what can go wrong and plan for it.
5. Allocate resources: assign people and tools to tasks.
6. Schedule the activities: set the order and the dates.
7. Review and publish the plan: the stakeholders check and accept it.

Software Configuration Management (SCM) is the discipline of identifying, organising and controlling the changes to the software and its related items, such as code, documents and test data, throughout the life of the project.

Main activities

• Identification of the configuration items and baselines.
• Version control of each item.
• Change control of the requests to change a baseline.
• Status accounting and audit, which report and check the state of the items.

Advantages

• It controls changes, so nothing changes without approval.
• It keeps every version, so the team can go back to an earlier working version.
• Many developers can work on the same product without overwriting each other.
• It reduces errors and confusion over which version is the latest.
• It gives a clear history of who changed what and why.

A Gantt chart is a bar chart that shows the project schedule. The tasks are listed down the left side and the time runs across the top. Each task is a horizontal bar that starts and ends on its start and end date, so the length of the bar is the duration of the task.

Features

• It shows the start and finish of each task and the overall project length.
• It shows which tasks overlap and which come one after the other.
• Milestones can be marked, and progress can be shown by shading the bar.
• It is easy to read for managers and customers.

Example

A small project of 9 weeks.

• Requirements take weeks 1 to 2.
• Design takes weeks 3 to 4, after requirements.
• Coding takes weeks 5 to 7.
• Testing takes weeks 8 to 9.

Use and limits

The chart is drawn when the project is planned and kept on the wall or on the screen of the team.

The manager updates the chart as the work goes on, and compares the plan with the actual progress. A Gantt chart does not show the dependencies between tasks clearly, and it does not give the critical path. For that, a network diagram such as PERT or CPM is used.

The Software Quality Assurance (SQA) activities are:

1. Applying technical methods.
2. Conducting formal technical reviews.
3. Testing the software.
4. Enforcing standards.
5. Controlling change.
6. Measurement.
7. Record keeping and reporting.

Formal technical review (FTR): a planned meeting of developers and reviewers, usually 3 to 5 people, who examine a work product such as a design or the code. They find errors early, check that the product meets the standards, and record the problems. The author fixes them, and the review is repeated if needed. Finding a fault here costs far less than finding it after delivery.

Risk categorisation puts the risks of a project into groups, so that they can be identified and handled.

By the area affected

• Project risks: problems with budget, schedule, staff, resources and customers.
• Technical risks: problems with design, implementation, interfaces, testing and maintenance, and with new technology.
• Business risks: the product may not sell, may not fit the strategy of the company, may lose management support or may need a budget that is not available.

By how well they can be known

• Known risks: found by careful study of the project.
• Predictable risks: known from past projects, such as staff turnover.
• Unpredictable risks: hard to foresee, and they can still occur.

The manager lists the risks in each category, rates their probability and impact, and plans how to reduce them.

Re-engineering

Re-engineering is the process of examining an existing system and changing it to improve its quality and maintainability, without changing what it does. The old system is rebuilt in a better form.

Its activities are:

1. Inventory analysis: list the applications and decide which ones to re-engineer.
2. Document restructuring: write the missing documents.
3. Reverse engineering: recover the design from the code.
4. Code restructuring: clean up poorly structured code.
5. Data restructuring: improve the data design.
6. Forward engineering: build the improved system from the recovered design.

Reverse engineering

Reverse engineering is the process of analysing the existing software, usually its source code, to find its design and specification at a higher level of abstraction. It is done when the documents are lost or out of date.

• It recovers the data design, the architectural design and the procedural design of the program.
• Tools read the code and produce structure charts, data flow diagrams and data dictionaries.
• It does not change the software. It only gives information about it.

Difference

Critical Path Analysis finds the longest path through the network of activities of a project. This path decides the shortest time in which the project can be finished. The activities on it are critical: they have no float, so a delay in any one of them delays the whole project.

Example: A takes 3 days. B (4 days) and C (2 days) follow A. D (3 days) follows B and C.

• Path A, B, D: $3 + 4 + 3 = 10$ days.
• Path A, C, D: $3 + 2 + 3 = 8$ days.

The critical path is A, B, D and the project takes 10 days. C has 2 days of float.

Stress is the mental and physical strain that a person feels under too much pressure. In IT projects it comes from tight deadlines, long hours, changing requirements, unclear goals, heavy workload, conflicts in the team and fear of failure.

Significance in IT projects

• Lower productivity: stressed people work slowly and lose focus.
• More defects: tired people make more mistakes, so quality drops.
• Staff turnover: burnout makes people leave, and the knowledge goes with them.
• Poor team spirit: stress causes conflict and poor communication.
• Health problems: long stress harms the health of the staff.

Control: the manager sets realistic schedules, avoids constant overtime, communicates clearly and supports the team.

Software maintenance is the modification of software after delivery to correct faults, improve performance and adapt it to a changing environment. Maintenance often costs more than the original development, so it needs an orderly process. A standard maintenance process has the following phases, and each change request passes through all of them in order.

Phases

The phases of the figure are explained below.

1. Problem identification and classification: a request for change is received, given an identity, classified (corrective, adaptive, perfective or preventive) and given a priority.
2. Analysis: the team studies the request, checks the feasibility, finds the effect of the change on the system and estimates cost and effort. It is approved or rejected here.
3. Design: the modification is designed, using the existing documents and code, and the tests that will be needed are planned.
4. Implementation: the code is changed and unit tested, and the documents are updated.
5. System testing: the changed system is tested as a whole, including regression testing, to check that the change has not broken old features.
6. Acceptance testing: the customer tests the modified system against the requirements.
7. Delivery: the new version is installed, the users are trained, and the documents and records are updated. The configuration records are also updated, so the new version can be traced later.