Software Engineering with Agile Methodology (AD-403) Notes

How unit 2 is examined

This unit covers design (concepts, UML, architecture, metrics) and testing (principles, activities, levels, test case design); Testing Levels carries the most marks, and architecture, UML, metrics, principles, activities and test case design are each asked once.

The Software Design Process

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. Software design is the process that converts the SRS (what the system must do) into a blueprint (how it will do it) from which code can be written.

Key points.

Design moves from the SRS to architectural (high-level) design, then to detailed (low-level) design.
High-level design fixes modules and their interfaces; low-level design fixes data structures and algorithms inside each module.
Each design decision must trace back to a requirement and be reviewed before coding starts.

<mark>Design is the process of turning requirements into a blueprint for construction.</mark>

Design Concepts and Principles

Definition. Design concepts are the basic ideas that guide a good design: abstraction, modularity, cohesion, coupling, information hiding and refinement.

Key points.

Abstraction hides detail and shows only what is essential; modularity divides the software into separately named, independently built modules.
Cohesion is how strongly the elements inside one module belong together; high cohesion is good.
Coupling is how dependent modules are on each other; low coupling is good.
Information hiding keeps a module's internal decisions secret behind its interface, so changes stay local.

<mark>A good design has high cohesion and low coupling.</mark>

Software Modeling and UML

Definition. UML (Unified Modeling Language) is a standard graphical language for specifying, visualising, constructing and documenting the artefacts of a software system.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u2-01" viewBox="0 0 600 194" width="600" height="194" role="img" aria-label="UML architecture. Things are structural or behavioural; relationships are dependency, association, generalisation, realisation."><style>#dsfig-u2-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u2-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u2-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u2-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u2-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u2-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u2-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u2-01 .t{fill:#16181D;font-weight:500}#dsfig-u2-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u2-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u2-01 .dot{fill:#16181D}#dsfig-u2-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u2-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u2-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u2-01 .ah{fill:#454C5A}#dsfig-u2-01 .ah.hi{fill:#2340B8}#dsfig-u2-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u2-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u2-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u2-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u2-01 .e{stroke:#B1B7C3}html.dark #dsfig-u2-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u2-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u2-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u2-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u2-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u2-01 .t{fill:#E6E8ED}html.dark #dsfig-u2-01 .t.inv{fill:#0F1115}html.dark #dsfig-u2-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u2-01 .dot{fill:#E6E8ED}html.dark #dsfig-u2-01 .ann{fill:#8FA3FF}html.dark #dsfig-u2-01 .lbl{fill:#858D9C}html.dark #dsfig-u2-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u2-01 .ah{fill:#B1B7C3}html.dark #dsfig-u2-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u2-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u2-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u2-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah7" 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="ahh7" 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><line class="e" x1="323.8" y1="37" x2="162" y2="101"/><line class="e" x1="323.8" y1="37" x2="363.5" y2="101"/><line class="e" x1="323.8" y1="37" x2="485.5" y2="101"/><line class="e" x1="162" y1="101" x2="47.5" y2="165"/><line class="e" x1="162" y1="101" x2="158" y2="165"/><line class="e" x1="162" y1="101" x2="276.5" y2="165"/><rect class="n" x="251.3" y="22" width="145" height="30" rx="8"/><text class="t" x="323.8" y="37" dy=".35em" text-anchor="middle">UML architecture</text><rect class="n" x="93.5" y="86" width="137" height="30" rx="8"/><text class="t" x="162" y="101" dy=".35em" text-anchor="middle">Building blocks</text><rect class="n" x="14" y="150" width="67" height="30" rx="8"/><text class="t" x="47.5" y="165" dy=".35em" text-anchor="middle">Things</text><rect class="n" x="97" y="150" width="122" height="30" rx="8"/><text class="t" x="158" y="165" dy=".35em" text-anchor="middle">Relationships</text><rect class="n" x="235" y="150" width="83" height="30" rx="8"/><text class="t" x="276.5" y="165" dy=".35em" text-anchor="middle">Diagrams</text><rect class="n" x="334" y="86" width="59" height="30" rx="8"/><text class="t" x="363.5" y="101" dy=".35em" text-anchor="middle">Views</text><rect class="n" x="409" y="86" width="153" height="30" rx="8"/><text class="t" x="485.5" y="101" dy=".35em" text-anchor="middle">Common mechanisms</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">UML architecture. Things are structural or behavioural; relationships are dependency, association, generalisation, realisation.</figcaption></figure>

Key points.

Building blocks are things, relationships and diagrams; things are structural (class, interface, component, node) or behavioural (interaction, state machine).
Relationships link things: dependency, association, generalisation and realisation.
Structural diagrams are class, object, component and deployment; behavioural diagrams are use case, sequence, activity and state chart.
Views show the system from different angles: use case, design, process, implementation and deployment view.
Common mechanisms (specifications, adornments, notes, extensibility such as stereotypes) keep models consistent.

Answer frame. Open with the UML definition; draw the block diagram above; develop building blocks, then diagrams, then views; close with UML being the industry standard for modelling.

Asked: [7 marks] (Jun 2023) Explain UML architecture.

Architectural Design

Definition. Architectural design defines the overall structure of a system: its major components, their responsibilities and how they interact.

Key points.

It is the first design step after requirements and gives the skeleton on which detailed design rests.
Decisions cover the components, their interfaces, data storage, communication and the style used.
It determines quality attributes such as performance, security, scalability and maintainability.
Styles include layered, client-server, pipe-and-filter, repository and MVC; an ATM is layered as UI, business logic and database.

Answer frame. Open with the definition; list the decisions; briefly name styles and views; close with the layered example and its importance.

Asked: [7 marks] (Jun 2024) Explain briefly about Architectural Design.

Architectural Views and Styles

Definition. An architectural view describes the architecture from one stakeholder's viewpoint; the 4+1 model gives logical, process, development and physical views tied together by scenarios.

Steps.

Understand the requirements and quality goals.
Choose an architectural style.
Identify the components and their responsibilities.
Define interfaces and connectors between them.
Evaluate the design against quality attributes and refine it.

Key points.

The logical view shows the classes and packages that provide the functionality.
The process view shows runtime processes, concurrency and communication.
The development view shows the code organisation into modules and layers.
The physical view maps software onto hardware nodes and networks.

Answer frame. Open with the definition; give the five steps; explain the four views in order; close with an example and importance.

Asked: [7 marks] (Jun 2025) Explain the architectural design process and the different architectural views.

User Interface Design

Definition. UI design creates the screens and controls through which users interact with software, aiming at usability.

Key points.

Golden rules: keep the user in control, reduce memory load, and keep the interface consistent.
Give clear feedback for every action and helpful error messages.
UI design follows analysis of users, tasks and environment, then prototyping and usability evaluation.

<mark>A good interface is simple, consistent and gives the user control.</mark>

Function oriented Design

Definition. Function-oriented design decomposes a system top-down into functions, each refined into sub-functions, sharing data through a common data store.

Key points.

The result is shown as a structure chart of modules and their calls.
Data flow diagrams (DFDs) drive the decomposition.
Functions are centred on processing, unlike object-oriented design, which is centred on objects.

<mark>Function-oriented design is top-down functional decomposition.</mark>

SA/SD Component Based Design

Definition. Structured analysis (SA) models what the system does using DFDs; structured design (SD) converts them into a structure chart of modules.

Key points.

SA produces DFDs, a data dictionary and process specifications.
SD uses transform or transaction analysis to derive the structure chart.
Component-based design builds software from reusable, independently deployable components with clear interfaces.

<mark>SA/SD turns DFDs into a structure chart.</mark>

Design Metrics

Definition. Design metrics are quantitative measures of a design's quality, used to judge complexity, maintainability and testability before coding.

Formula. $$V(G)=E-N+2$$ $$\text{Fan-out}=\text{modules called by a module};\ \text{Fan-in}=\text{modules calling it}$$

Key points.

Cyclomatic complexity $V(G)=E-N+2$ counts independent paths in a flow graph; a value above 10 signals a risky module.
Fan-in and fan-out measure structure: high fan-out means a module controls many others and is highly coupled.
Cohesion and coupling rate module independence; good design has high cohesion and low coupling.
Metrics matter because they predict maintenance effort, locate error-prone modules and compare design alternatives.

Asked: [7 marks] (Jun 2025) Describe any two software design metrics and their importance.

Software Static and Dynamic analysis

Definition. Static analysis examines code without running it; dynamic analysis observes the program while it executes.

Key points.

Static analysis includes reviews, inspections, walkthroughs and tools such as lint; it finds syntax faults, dead code and standard violations.
Dynamic analysis includes testing and profiling; it finds runtime errors, memory leaks and performance bottlenecks.
Static analysis can be applied early, dynamic analysis needs executable code.

<mark>Static analysis checks code without executing it; dynamic analysis runs it.</mark>

Code inspections

Definition. Code inspection (Fagan inspection) is a formal, peer-led review of code against a checklist to find defects before testing.

Key points.

Roles are moderator, author, reader, recorder and inspectors.
Stages are planning, overview, preparation, meeting, rework and follow-up.
Inspections find defects early and cheaply, but only find faults, not fix them in the meeting.

<mark>Inspection is a formal peer review that finds defects early.</mark>

Software Testing, Fundamentals

Definition. Software testing is executing a program with the intent of finding errors and checking that it meets its requirements.

Key points.

Testing shows the presence of defects, not their absence.
Exhaustive testing is impossible, so tests are chosen by risk and priority.
Test early: planning starts with requirements, since early defects cost least to fix.
Defects cluster: a few modules hold most faults (the Pareto principle).
Repeating the same tests wears out (pesticide paradox), so test cases must be reviewed and refreshed.
Testing is context dependent, and a bug-free system can still fail user needs (absence-of-errors fallacy).

Asked: [7 marks] (Jun 2024) What are the testing principles the software engineer must apply while performing the software testing?

Software Test Process

Definition. The test process is the set of planned activities that verify software quality from planning to closure.

Key points.

Test planning defines scope, approach, resources, schedule and exit criteria.
Test design derives test cases and test data from requirements.
Test environment setup prepares hardware, software and data.
Test execution runs the cases and compares actual with expected results.
Defect reporting and tracking logs each failure until it is fixed and retested.
Test closure evaluates exit criteria and records lessons learned.

Asked: [7 marks] (Jun 2024) What are the various testing activities? Discuss.

Testing Levels

Definition. Software testing is running software to find defects and confirm it meets requirements. A test case is a set of inputs, preconditions, steps, expected result and actual result/status used to check one behaviour, identified by a test case ID.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u2-02" viewBox="0 0 467 80" width="467" height="80" role="img" aria-label="Testing levels: Unit, Integration, System, Acceptance"><style>#dsfig-u2-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u2-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u2-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u2-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u2-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u2-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u2-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u2-02 .t{fill:#16181D;font-weight:500}#dsfig-u2-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u2-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u2-02 .dot{fill:#16181D}#dsfig-u2-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u2-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u2-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u2-02 .ah{fill:#454C5A}#dsfig-u2-02 .ah.hi{fill:#2340B8}#dsfig-u2-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u2-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u2-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u2-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u2-02 .e{stroke:#B1B7C3}html.dark #dsfig-u2-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u2-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u2-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u2-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u2-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u2-02 .t{fill:#E6E8ED}html.dark #dsfig-u2-02 .t.inv{fill:#0F1115}html.dark #dsfig-u2-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u2-02 .dot{fill:#E6E8ED}html.dark #dsfig-u2-02 .ann{fill:#8FA3FF}html.dark #dsfig-u2-02 .lbl{fill:#858D9C}html.dark #dsfig-u2-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u2-02 .ah{fill:#B1B7C3}html.dark #dsfig-u2-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u2-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u2-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u2-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah8" 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="ahh8" 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(#ah8)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah8)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah8)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">U</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">I</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">S</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">A</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Testing levels: Unit, Integration, System, Acceptance</figcaption></figure>

Key points.

Unit testing checks the smallest units (functions, classes) in isolation, done by developers using white-box methods, drivers and stubs.
Integration testing checks that combined modules exchange data correctly; approaches are top-down, bottom-up, big-bang and sandwich.
System testing checks the complete integrated software against the SRS, covering functional, performance, security and usability tests.
Acceptance testing is done by the customer to decide whether to accept the product; it has alpha (at developer site) and beta (at user site) forms.
Each level catches defects that earlier levels cannot, so all four are needed; example: testing a login function (unit), login with database (integration), the whole shopping site (system), and the client trial (acceptance).

Answer frame. Open by defining software testing, its objective and a test case with its attributes; draw the level chain; explain each level with who tests it, what and how; close with an example for each level.

Asked: [7 marks] (Jun 2023, Jun 2025) What is Test case? What are the different levels of Testing? / Define software testing and explain the levels of testing.

Test Criteria

Definition. Test criteria are the rules that decide what to test and when testing is complete.

Key points.

Coverage criteria include statement, branch, condition and path coverage.
Completion criteria include a coverage target, a defect rate below a limit, or the deadline and budget being reached.
Exit criteria are recorded in the test plan.

<mark>Test criteria say what to cover and when to stop.</mark>

Test Case Design

Definition. Test case design is deriving a small set of inputs and expected outputs that find the most faults with the least effort.

Key points.

Equivalence partitioning divides inputs into classes treated alike and tests one value per class; age 18-60 valid gives classes below 18, 18-60 and above 60.
Boundary value analysis tests at the edges, such as 17, 18, 60 and 61.
A decision table lists condition combinations and the action for each, for example login valid/invalid user and password.
State transition testing checks the moves between states, for example an ATM card going from idle to PIN entry to locked after three wrong tries.

Asked: [7 marks] (Jun 2025) Write a short note on Test Case Design techniques with examples.

Test Oracles

Definition. A test oracle is the mechanism that decides whether a program's output for a test is correct.

Key points.

Oracles include the specification, a previous version, a reference implementation and human judgement.
The oracle problem is that computing the expected result is hard for complex programs.
Automated tests need an oracle to give pass or fail.

<mark>An oracle tells the tester what the correct output should be.</mark>

Test Techniques

Definition. Test techniques are systematic ways of choosing test cases: black-box, white-box and grey-box.

Key points.

Black-box testing uses only the specification: equivalence partitioning, boundary value analysis and decision tables.
White-box testing uses the code structure: statement, branch and path coverage and control flow testing.
Grey-box testing mixes the two.

<mark>Black-box tests functions; white-box tests code structure.</mark>

Testing Frameworks

Definition. A testing framework is a set of tools, libraries and rules that helps write, run and report automated tests.

Key points.

Examples are JUnit, TestNG, pytest and Selenium.
A test harness runs tests with drivers and stubs and collects results.
Automation makes regression testing fast and repeatable.

<mark>A framework automates writing, running and reporting tests.</mark>

Test Plan

Definition. A test plan is a document that describes the scope, approach, resources and schedule of testing (IEEE 829).

Key points.

Contents include test items, features to test, approach, pass/fail criteria, deliverables, risks and schedule.
It names the responsibilities of the team and the test environment.
The test strategy is the higher-level approach; the plan applies it to one project.

<mark>A test plan states what, how, who and when of testing.</mark>

Test Metrics

Definition. Test metrics are measures of the progress, coverage and quality of testing.

Formula. $$\text{Defect density}=\frac{\text{defects}}{\text{KLOC}}$$

Key points.

Test coverage is the percentage of code or requirements exercised by tests.
Defect density and defect removal efficiency show product quality and test effectiveness.
Pass rate and test execution progress show project status.

<mark>Defect density is defects per thousand lines of code.</mark>

Testing Tools

Definition. Testing tools are software that automates or supports testing activities.

Key points.

Selenium and QTP (UFT) automate functional UI tests; JMeter and LoadRunner do performance tests.
Static tools such as lint and SonarQube analyse code without running it; Jira and Bugzilla track defects.
Tools give speed and repeatability but cost effort to set up and maintain.

<mark>Tools automate repetitive testing and defect tracking.</mark>

Last-minute revision

Design turns the SRS into a blueprint; high-level design gives modules, low-level design gives algorithms.
Good design: high cohesion, low coupling.
UML building blocks: things, relationships, diagrams; structural and behavioural diagrams.
4+1 views: logical, process, development, physical plus scenarios.
Cyclomatic complexity $V(G)=E-N+2$.
Static analysis does not run code; dynamic analysis does.
Seven testing principles include: testing shows presence of defects, exhaustive testing impossible, early testing, defect clustering, pesticide paradox.
Test activities: plan, design, environment, execute, report, close.
Levels: unit, integration, system, acceptance; alpha at developer site, beta at user site.
Test case design: equivalence partitioning, boundary value, decision table, state transition.
Defect density = defects / KLOC.

Memory hooks

Levels: "UISA" - Unit, Integration, System, Acceptance.
4+1 views: "L-P-D-P" plus scenarios.
Cohesion in, coupling out: keep cohesion high, coupling low.
Test process: "PDEREC" - Plan, Design, Environment, Execute, Report, Close.
Boundary testing: test just below, on and just above each edge.

Coverage checklist

The Software Design Process: no past questions.
Design Concepts and Principles: no past questions.
Software Modeling and UML: UML architecture (Jun 2023).
Architectural Design: Architectural Design briefly (Jun 2024).
Architectural Views and Styles: design process and views (Jun 2025).
User Interface Design: no past questions.
Function oriented Design: no past questions.
SA/SD Component Based Design: no past questions.
Design Metrics: two design metrics (Jun 2025).
Software Static and Dynamic analysis: no past questions.
Code inspections: no past questions.
Software Testing, Fundamentals: testing principles (Jun 2024).
Software Test Process: testing activities (Jun 2024).
Testing Levels: test case, levels of testing (Jun 2023, Jun 2025).
Test Criteria: no past questions.
Test Case Design: techniques with examples (Jun 2025).
Test Oracles: no past questions.
Test Techniques: no past questions.
Testing Frameworks: no past questions.
Test Plan: no past questions.
Test Metrics: no past questions.
Testing Tools: no past questions.

Account

Software Engineering with Agile Methodology (AD-403) - Unit 2 Short Notes

How unit 2 is examined

The Software Design Process

Design Concepts and Principles

Software Modeling and UML

Architectural Design

Architectural Views and Styles

User Interface Design

Function oriented Design

SA/SD Component Based Design

Design Metrics

Software Static and Dynamic analysis

Code inspections

Software Testing, Fundamentals

Software Test Process

Testing Levels

Test Criteria

Test Case Design

Test Oracles

Test Techniques

Testing Frameworks

Test Plan

Test Metrics

Testing Tools

Last-minute revision

Memory hooks

Coverage checklist