Software Engineering (AL-403) Unit 5 Notes

How unit 5 is examined

Maintenance, configuration management, re-engineering and project management; the marks sit in maintenance types, SCM, COCOMO estimation, risk management, resources and SQA.

Need and Types of Maintenance

High weight

Definition. Software maintenance is the modification of a software product after delivery to correct faults, improve performance or other attributes, or adapt it to a changed environment.

Key points.

Software in a real environment must change because user needs, business rules, hardware, operating systems and laws keep changing, and unchanged software becomes progressively less useful.
Lehman's laws of software evolution state that a used system must continually change (continuing change), that its complexity grows unless work is done to reduce it (increasing complexity), and that its quality appears to decline unless it is adapted.
Repeated patching raises entropy (software ageing), so each change becomes costlier and riskier.
Corrective maintenance fixes faults found after release, such as a wrong interest calculation or a crash.
Adaptive maintenance changes the software for a new environment, such as a new OS version, database or tax rule.
Perfective maintenance adds or improves features and performance at the user's request, such as a faster search or a new report; it is the largest share of maintenance effort (about 50-60%).
Preventive maintenance restructures or documents code to make future changes easier and avoid faults, for example refactoring a module.
The maintenance process runs change request, impact analysis, design, implementation, regression testing and release.

Type	Trigger	Example
Corrective	Fault report	Fix divide-by-zero
Adaptive	Environment change	Port to new OS
Perfective	User wish	Add export to PDF
Preventive	Future risk	Refactor and document

Answer frame. Open with the definition; draw the table; develop points 1-3 for "why change", then 4-7 with an example each, then 8; close with "maintenance keeps software useful".

Asked: [7 marks] (May 2019) Discuss briefly on software maintenance activities. Asked: [7 marks] (Jun 2020, Jun 2026) Explain why a software system used in a real world environment must change or become progressively less useful? / Explain the need for software maintenance with suitable examples. Asked: [7 marks] (Jun 2022, Jun 2026) What is the purpose of maintaining the software? Explain the different types. / Explain the need for software maintenance and its types with suitable examples.

Software Configuration Management (SCM)

Definition. Software configuration management is the discipline of identifying, organising and controlling changes to software work products throughout the life cycle so that the product stays consistent and traceable.

Key points.

SCM is needed because many people change many files at once, and without control changes are lost, overwritten or released untested.
A configuration item (SCI) is any work product placed under control, such as the SRS, design, source file, test case or manual.
A baseline is a formally reviewed and approved version of one or more SCIs that can be changed only through formal change control.
Configuration identification names and labels every SCI and baseline with a unique identifier and version number.
Version control keeps every version of each SCI in a repository so any earlier version can be recovered.
Change control evaluates each change request, approves or rejects it, and then implements and verifies it.
Configuration status accounting (reporting) records what changed, when, why and by whom.
Configuration audit checks that the change was made as approved and that the baseline is complete and consistent.
Tools include Git, SVN, CVS and Perforce; benefits are traceability, less rework, safe parallel work and controlled releases.

Example. A new fee field is requested: the change board approves it, the developer checks out fees.c 1.3, edits it to 1.4, tests it, and the audit confirms the baseline.

Answer frame. Open with the definition and need; draw the loop Identification, Version control, Change control, Status accounting, Audit; develop points 2-8 in that order; add the example and tools; close with the benefits.

Asked: [14 marks] (Dec 2020) Write short notes on: a) SCM b) Object oriented analysis c) Re-engineering Asked: [7 marks] (Jun 2020, Jun 2024, Dec 2024, Jun 2026) Explain software configuration management. / Explain SCM in detail. Asked: [7 marks] (Jun 2023, Jun 2025) Discuss about SCM function in software engineering with suitable example. Asked: [7 marks] (Jun 2024, Dec 2024, Jun 2025) Explain briefly about SCM. / What is SCM? Describe its major activities.

Software Change Management

Definition. Software change management is the process of requesting, evaluating, approving, implementing and verifying changes to a software system in a controlled way.

Key points.

It prevents uncontrolled changes that break working software.
Each change follows a request, impact analysis, approval, implementation, testing and release.
Only approved changes enter the baseline.
It is a core part of SCM.

Version Control

Definition. Version control records every change to files in a repository so that earlier versions can be recovered and many people can work in parallel.

Key points.

Each saved change is a revision with author, time and message.
Branches allow parallel work and merges combine it, with conflicts resolved by hand.
Centralised systems (SVN, CVS) use one server; distributed systems (Git) give every user a full copy.
It supports rollback, comparison and collaboration.

Change control and Reporting

Definition. Change control is the formal procedure by which a change request is evaluated, authorised and implemented, and reporting records its history.

Key points.

A change request describes the change, reason and priority.
The Change Control Board (CCB) assesses effort, cost and risk and approves or rejects it.
The approved change is checked out, made, tested and checked in, creating a new version.
Status reports list change requests and their state to keep everyone informed.

Program Comprehension Techniques

Definition. Program comprehension is the process by which a maintainer builds a mental understanding of what existing code does and how it is organised.

Key points.

It is needed because maintainers must change legacy code that has poor or missing documentation.
Top-down comprehension starts with the overall purpose and refines it into hypotheses about sub-parts until they match the code.
Bottom-up comprehension reads statements, groups them into chunks and builds up to the program's purpose.
Opportunistic (integrated) comprehension mixes both as clues appear; tools such as browsers, cross-references and call graphs support it.

Asked: [7 marks] (Jun 2022) What are the different program comprehensions?

Re-engineering

Definition. Re-engineering is examining and altering an existing system to reconstitute it in a new form, by reverse engineering followed by restructuring and forward engineering.

Key points.

Forward engineering builds a system from requirements to code, whereas re-engineering improves an existing system whose code is old but still valuable.
Inventory analysis lists all applications with age, size, business value and maintenance cost to choose candidates.
Document restructuring creates or updates documentation only where it is needed.
Reverse engineering recovers design and specifications from the existing code.
Code restructuring changes poor control structure into structured code without changing behaviour.
Data restructuring reorganises the data structures and database.
Forward engineering then uses the recovered design to build the improved system.
Benefits are lower maintenance cost, better structure and longer life; the cost is time and effort with some risk.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u5-01" viewBox="0 0 596 80" width="596" height="80" role="img" aria-label="Re-engineering cycle: Inv inventory analysis, Doc document restructuring, Rev reverse engineering, Cod code restructuring, Dat data restructuring, Fwd forward engineering"><style>#dsfig-u5-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u5-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u5-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u5-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u5-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u5-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u5-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u5-01 .t{fill:#16181D;font-weight:500}#dsfig-u5-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u5-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u5-01 .dot{fill:#16181D}#dsfig-u5-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u5-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u5-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u5-01 .ah{fill:#454C5A}#dsfig-u5-01 .ah.hi{fill:#2340B8}#dsfig-u5-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u5-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u5-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u5-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u5-01 .e{stroke:#B1B7C3}html.dark #dsfig-u5-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u5-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u5-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u5-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u5-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u5-01 .t{fill:#E6E8ED}html.dark #dsfig-u5-01 .t.inv{fill:#0F1115}html.dark #dsfig-u5-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u5-01 .dot{fill:#E6E8ED}html.dark #dsfig-u5-01 .ann{fill:#8FA3FF}html.dark #dsfig-u5-01 .lbl{fill:#858D9C}html.dark #dsfig-u5-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u5-01 .ah{fill:#B1B7C3}html.dark #dsfig-u5-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u5-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u5-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u5-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah17" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh17" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L122.2,40" marker-end="url(#ah17)"/><path class="e" d="M162.2,40 L225.4,40" marker-end="url(#ah17)"/><path class="e" d="M265.4,40 L328.6,40" marker-end="url(#ah17)"/><path class="e" d="M368.6,40 L431.8,40" marker-end="url(#ah17)"/><path class="e" d="M471.8,40 L535,40" marker-end="url(#ah17)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Inv</text><circle class="n" cx="143.2" cy="40" r="18"/><text class="t" x="143.2" y="40" dy=".35em" text-anchor="middle">Doc</text><circle class="n" cx="246.4" cy="40" r="18"/><text class="t" x="246.4" y="40" dy=".35em" text-anchor="middle">Rev</text><circle class="n" cx="349.6" cy="40" r="18"/><text class="t" x="349.6" y="40" dy=".35em" text-anchor="middle">Cod</text><circle class="n" cx="452.8" cy="40" r="18"/><text class="t" x="452.8" y="40" dy=".35em" text-anchor="middle">Dat</text><circle class="n" cx="556" cy="40" r="18"/><text class="t" x="556" y="40" dy=".35em" text-anchor="middle">Fwd</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Re-engineering cycle: Inv inventory analysis, Doc document restructuring, Rev reverse engineering, Cod code restructuring, Dat data restructuring, Fwd forward engineering</figcaption></figure>

Basis	Reverse engineering	Re-engineering
Meaning	Recovering design from code	Rebuilding a system in improved form
Purpose	Understanding	Improvement
Process	Analysis only	Reverse, restructure, forward
Output	Models, documents	New working system
Direction	Code to design	Code to design to new code
Example	UML from old C code	Rewrite COBOL app in Java

Answer frame. Open with the definition; draw the cycle; develop points 2-8 in order; for the difference question give the table with a definition line each; close with "re-engineering extends the life of a legacy system".

Asked: [7 marks] (Nov 2023) Write the difference between reverse engineering and re-engineering. Asked: [7 marks] (Dec 2024) What is Re-Engineering and discuss about steps involved in Re-Engineering?

Reverse Engineering

Definition. Reverse engineering is the process of analysing a finished system to recover its design and specification, moving from code to a higher level of abstraction.

Key points.

Its purpose is to understand legacy systems that lack documentation, so they can be maintained or re-engineered.
Redocumentation produces documents, such as flow charts and call graphs, at the same abstraction level without new interpretation.
Design recovery uses domain knowledge and code analysis to rebuild the design, data model and architecture.
Specification recovery goes higher still and rebuilds requirements.
The steps are to collect information, extract structure with tools, abstract it into models, and review it for completeness.
Tools include code browsers, cross-referencers, call-graph generators and UML extractors.
It is used in maintenance, migration, legacy systems and checking that code matches its design.

Answer frame. Open with the definition; draw the ladder code, design, requirements; develop points 2-7; close with the uses. For the combined question add the re-engineering steps and table.

Asked: [7 marks] (Dec 2020) Explain Reverse engineering. Asked: [7 marks] (Jun 2026) Explain Reverse Engineering and Re-engineering in detail.

Tool Support

Definition. Tool support means CASE and maintenance tools that automate analysis, configuration, testing and documentation work.

Key points.

Upper CASE tools help analysis and design, and lower CASE tools help coding and testing.
Maintenance tools include reverse engineering tools, static analysers and restructurers.
SCM tools such as Git manage versions and changes.
They raise productivity and consistency but need training and cost.

Project Management Concepts

Definition. Software project management is planning, organising, monitoring and controlling people, process and product so that software is delivered on time, within budget and with quality.

Key points.

The four Ps are people, product, process and project.
People are the most important factor, and the product's scope must be fixed first.
The process framework selects tasks and milestones, and the project applies them.
Activities are estimation, scheduling, risk management, tracking and quality control.

Feasilibility Analysis

Definition. Feasibility analysis is a study made before development to decide whether the proposed project is technically, economically and operationally worth carrying out.

Key points.

Technical feasibility checks whether the required technology, hardware, skills and performance are available.
Economic feasibility compares development cost with expected benefits using cost-benefit analysis, payback period and return on investment.
Operational feasibility checks whether users and the organisation will accept and use the system.
Legal feasibility checks licences, contracts, privacy and regulations.
Schedule feasibility checks whether the system can be delivered by the needed date.
The process is to study the problem, propose alternatives, assess each type, compare cost and benefit, and give a decision in a feasibility report.
Example: an online exam system is feasible if benefits exceed cost and users accept it; otherwise it is dropped.

Answer frame. Open with the definition and purpose; list the five types as points 1-5; give the process and criteria; close with the example decision.

Asked: [7 marks] (Jun 2024, Jun 2025) What do you understand by Feasibility Analysis? Explain. / Explain software project feasibility analysis and its types. Asked: [14 marks] (Nov 2023) Write a short note on any two: a) Structured methods b) White-Box Testing c) Feasibility Analysis d) Test Case Design

Project and Process Planning

Definition. Project planning is deciding in advance what work is to be done, by whom, when and with what resources, to meet the project goals.

Key points.

Planning matters because it gives a schedule, allocates resources and exposes risks before they cause damage.
Its activities are scope definition, estimation, scheduling, staffing, risk planning and quality planning.
The process model is chosen first, then its tasks are laid on a timeline.
The outputs are the SRS and the project plan.

Asked: [7 marks] (Dec 2020) Explain what is project planning. Why it is important?

Resources Allocations

Definition. Resource allocation is assigning people, hardware, software and time to project tasks so that the schedule and budget are met.

Key points.

Human resources are chosen by skill and experience and assigned to tasks in the work breakdown structure.
Hardware and software resources are the development machines, licences and test environments that tasks need.
Reusable components are a resource: reusing tested modules saves effort.
Each resource is scheduled with start and end dates, so that it is not booked for two tasks at once.
Over-allocation is removed by levelling, which delays tasks, since adding people to a late project makes it later (Brooks's law).
The allocation is tracked and revised as the plan changes.

Answer frame. Define resources; list types; explain scheduling and levelling; close with the effect on cost and delivery.

Asked: [14 marks] (Dec 2024) Write short notes on any two: i) Resource Allocation ii) Component Assembly Model iii) SA/SD Component Based Design iv) Testing frameworks

Software efforts, Schedule, and Cost estimations

Definition. COCOMO (Constructive Cost Model, Boehm) estimates software effort in person-months and development time from the size in KLOC.

Formula. Effort and time for the Basic model:

$$E = a\,(KLOC)^b \text{ person-months}, \qquad D = c\,E^{d} \text{ months}, \qquad N = E/D$$

Mode	a	b	c	d
Organic	2.4	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

Key points.

Cost estimation predicts the effort, time and money a project needs, and schedule is derived from effort.
Organic projects are small teams on familiar problems, semi-detached are of mixed experience, and embedded have tight hardware and operational constraints.
Basic COCOMO uses only size and mode, Intermediate multiplies effort by 15 cost drivers (effort adjustment factor), and Detailed applies drivers phase by phase.
The steps are to estimate KLOC, choose the mode, compute E, compute D, and compute the average staff N.
Cost equals effort times the monthly salary.

Example. A 32 KLOC organic project: $E = 2.4 \times 32^{1.05} = 91.3$ PM; $D = 2.5 \times 91.3^{0.38} = 13.9$ months; $N = 91.3/13.9 = 6.6$ persons. Answer: E = 91.3 PM, D = 13.9 months, about 7 persons. The same size as embedded gives 230.4 PM in 14.3 months.

Answer frame. Open by defining estimation and COCOMO; give the formula table; list the three models and modes; work the example; close with the limitation that it depends on the KLOC estimate. For the short note "Schedule and Cost Estimation", give the definition, formula and one line on the example.

Asked: [7 marks] (Jun 2020, Dec 2020) Explain cost estimation COCOMO model with example. / How can we estimate the cost of software using COCOMO Model? Asked: [14 marks] (Jun 2024) Write short notes on any two: a) Schedule and Cost Estimation b) RUP c) Traceability d) Design Principles

Project Scheduling and Tracking

Definition. Project scheduling divides the work into tasks with durations and dependencies on a timeline, and tracking compares actual progress with that schedule.

Key points.

A Gantt chart shows tasks as bars against time, and PERT and CPM show dependencies, where CPM finds the critical path that fixes the minimum project duration.
Tracking uses milestones, status meetings and reviews to see what is complete.
Earned value compares the budgeted value of work done with cost and plan, to detect delay or overspend early.
Tracking supports project control by triggering corrective action.
Slack (float) is the delay a non-critical task can absorb.

Asked: [7 marks] (Nov 2023) Write about project scheduling and tracking.

Risk Assessment and Mitigation

Definition. A risk is an uncertain event that, if it occurs, harms the project's cost, schedule or quality; risk management identifies, assesses and controls such events.

Key points.

Project risks threaten schedule and resources, technical risks threaten quality and implementation, and business risks threaten market value or funding.
Risk identification uses checklists, brainstorming, past project data and reviews to list the risks, such as staff turnover or changing requirements.
Risk analysis estimates the probability and impact of each risk, and exposure is probability times loss.
Prioritisation ranks risks by exposure so that the top few get attention.
Mitigation planning reduces probability or impact, for example by cross-training staff, and contingency planning prepares a fallback if the risk occurs.
Monitoring and control watch the risk indicators and trigger the plan; the whole is recorded in the RMMM (Risk Mitigation, Monitoring and Management) plan.
Example: for a key developer who may leave, mitigation is documentation, monitoring is morale checks, and contingency is a trained backup.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u5-02" viewBox="0 0 596 80" width="596" height="80" role="img" aria-label="Risk management cycle: Id identification, An analysis, Pr prioritisation, Pl mitigation planning, Mo monitoring and control"><style>#dsfig-u5-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u5-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u5-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u5-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u5-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u5-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u5-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u5-02 .t{fill:#16181D;font-weight:500}#dsfig-u5-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u5-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u5-02 .dot{fill:#16181D}#dsfig-u5-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u5-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u5-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u5-02 .ah{fill:#454C5A}#dsfig-u5-02 .ah.hi{fill:#2340B8}#dsfig-u5-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u5-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u5-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u5-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u5-02 .e{stroke:#B1B7C3}html.dark #dsfig-u5-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u5-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u5-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u5-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u5-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u5-02 .t{fill:#E6E8ED}html.dark #dsfig-u5-02 .t.inv{fill:#0F1115}html.dark #dsfig-u5-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u5-02 .dot{fill:#E6E8ED}html.dark #dsfig-u5-02 .ann{fill:#8FA3FF}html.dark #dsfig-u5-02 .lbl{fill:#858D9C}html.dark #dsfig-u5-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u5-02 .ah{fill:#B1B7C3}html.dark #dsfig-u5-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u5-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u5-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u5-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah18" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh18" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L148,40" marker-end="url(#ah18)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah18)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah18)"/><path class="e" d="M446,40 L535,40" marker-end="url(#ah18)"/><path class="e" d="M537,40 L61,40" marker-end="url(#ah18)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Id</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">An</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Pr</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">Pl</text><circle class="n" cx="556" cy="40" r="18"/><text class="t" x="556" y="40" dy=".35em" text-anchor="middle">Mo</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Risk management cycle: Id identification, An analysis, Pr prioritisation, Pl mitigation planning, Mo monitoring and control</figcaption></figure>

Answer frame. Open with the definition of risk and risk management; draw the cycle; develop points 2-6 in order; give the example; close with "risk management turns surprises into planned responses". For "how to identify risk", stress points 1-2.

Asked: [7 marks] (May 2019) List and explain the steps in Risk management process. Asked: [7 marks] (Nov 2023) What is risk and how to identify the risk in software engineering? Explain. Asked: [7 marks] (Nov 2023, Dec 2024) Explain the principles of risk assessment and mitigation. Asked: [7 marks] (Dec 2024) Discuss about Risk Assessment and Mitigation.

Software Quality Assurance(SQA)

Definition. Software quality assurance is a planned set of activities that ensures the software process and product conform to specified requirements and standards.

Key points.

Software quality is the degree to which software meets requirements and user expectations, described by attributes such as those of McCall (correctness, reliability, efficiency, usability, maintainability, portability) and ISO 9126.
The goals of SQA are defects prevented early, standards followed and a product the customer accepts.
SQA activities are reviews and inspections, audits, testing, standards enforcement, defect reporting and metrics collection.
Standards include ISO 9001 and the CMM.
Maintenance metrics measure how well software can be maintained: MTTR (mean time to repair), number of change requests, and the maintainability index.
MTTR is the average time to fix a fault, and a falling MTTR shows better maintainability.
Test metrics measure testing, such as test cases run, defects found per KLOC and test coverage.
Such metrics guide planning of maintenance effort and staff.

Answer frame. Define quality, then SQA; list goals and activities as points 2-4; give maintenance metrics 5-6; for short notes do only the relevant lines. Close with "quality is built in, not tested in".

Asked: [14 marks] (Jun 2020) Write short notes: a) Software Quality Assurance b) Reverse Engineering c) Risk Assessment d) Test Metrics Asked: [7 marks] (Jun 2023) What is meant by software quality? Explain the metrics for maintenance.

Project Plan

Definition. A project plan is the document that records the scope, schedule, resources, cost, risks and quality arrangements of a project.

Key points.

It contains introduction, estimates, schedule, staffing, risk plan and SCM plan.
It is the baseline against which progress is tracked.
It is updated whenever the project changes.

Project Metrics

Definition. Project metrics are quantitative measures of a project's size, effort, cost, schedule and quality used for estimation and control.

Key points.

Size metrics are lines of code (KLOC) and function points.
Productivity is size per person-month, such as KLOC/PM.
Quality metrics include defects per KLOC.
Measurement helps future estimates and shows progress.

Last-minute revision

Maintenance types: corrective, adaptive, perfective (largest), preventive.
Lehman: continuing change and increasing complexity; entropy rises with patching.
SCM: identification, version control, change control, status accounting, audit.
A baseline changes only through formal change control.
Re-engineering: inventory, document restructuring, reverse engineering, code and data restructuring, forward engineering.
Reverse engineering recovers design from code: redocumentation, design recovery.
Feasibility types: technical, economic, operational, legal, schedule.
Basic COCOMO: E = a(KLOC)^b, D = cE^d; organic 2.4, 1.05, 2.5, 0.38.
32 KLOC organic: 91.3 PM, 13.9 months, 6.6 persons.
Risk steps: identify, analyse, prioritise, plan, monitor; exposure = probability x loss.
Critical path fixes the minimum project duration.

Memory hooks

CAPP for maintenance: Corrective, Adaptive, Perfective, Preventive.
IVCSA for SCM: Identify, Version, Change, Status, Audit.
Organic, Semi-detached, Embedded: 2.4, 3.0, 3.6 rising with difficulty.
Reverse is understanding; re-engineering is understanding plus rebuilding.
Risk cycle: Identify, Analyse, Prioritise, Plan, Monitor.

Coverage checklist

Need and Types of Maintenance: May 2019, Jun 2020, Jun 2022, Jun 2026
Software Configuration Management (SCM): Dec 2020 note, Jun 2020-Jun 2026 explains
Software Change Management
Version Control
Change control and Reporting
Program Comprehension Techniques: Jun 2022
Re-engineering: Nov 2023, Dec 2024
Reverse Engineering: Dec 2020, Jun 2026
Tool Support
Project Management Concepts
Feasilibility Analysis: Jun 2024, Jun 2025, Nov 2023
Project and Process Planning: Dec 2020
Resources Allocations: Dec 2024
Software efforts, Schedule, and Cost estimations: COCOMO, Jun 2024
Project Scheduling and Tracking: Nov 2023
Risk Assessment and Mitigation: four risk questions
Software Quality Assurance(SQA): Jun 2020, Jun 2023
Project Plan
Project Metrics

Account

Software Engineering (AL-403) - Unit 5 Short Notes

How unit 5 is examined

Need and Types of Maintenance

Software Configuration Management (SCM)

Software Change Management

Version Control

Change control and Reporting

Program Comprehension Techniques

Re-engineering

Reverse Engineering

Tool Support

Project Management Concepts

Feasilibility Analysis

Project and Process Planning

Resources Allocations

Software efforts, Schedule, and Cost estimations

Project Scheduling and Tracking

Risk Assessment and Mitigation

Software Quality Assurance(SQA)

Project Plan

Project Metrics

Last-minute revision

Memory hooks

Coverage checklist