Software Engineering Quiz Prep Summary

1. Software Testing

Definition: Operating a system/component under specified conditions, observing results, and evaluating
aspects of the system.

Goals: - Ensure the program works as intended. - Discover defects before deployment.

Types of Testing: - Manual Testing: Includes Unit, Integration, System, and User Acceptance Testing. -
Automation Testing: Uses tools to simulate manual steps (e.g., load tests, code auditing).

Testing Levels: - Development Testing: During development. - Release Testing: Before release. - User
Testing: Performed by users (Alpha, Beta, Acceptance Testing).

Testing Strategies: - Big Bang Testing: Entire software tested after integration. - Incremental Testing:
Components tested individually and then integrated.

White Box vs Black Box Testing: - Black Box: No internal code visibility. Focuses on input-output. - White
Box: Internal logic tested. Requires code knowledge.

Stubs & Drivers: - Stubs: Simulate lower-level modules (used in Top-Down Testing). - Drivers: Simulate
higher-level modules (used in Bottom-Up Testing).

Regression Testing: Ensures new code doesn’t break existing functionality.

Test Case Writing: 1. Test Case ID 2. Test Description 3. Preconditions 4. Test Data 5. Steps to Execute 6.
Expected Result 7. Actual Result/Postconditions 8. Pass/Fail Criteria

2. Software Quality Assurance (SQA)

Definition: Degree to which software meets requirements and satisfies user expectations.

SQA vs QC: - SQA: Prevents defects through planned activities. - QC: Identifies defects in completed
products.

Software Defect Terminology: - Error: Human mistake in code. - Fault: Manifestation of an error in code. -
Failure: Software behaves incorrectly when a fault is activated.

Defect Origins: - Requirement misunderstandings. - Design/coding errors. - Incomplete testing. -

1
Quality Standards: - CMM: Maturity levels of software processes (1–5). - ISO 9000: Quality management
systems. - IEEE 1061: Metrics for software quality evaluation.

Review Types: - Formal Reviews: Structured sessions to detect issues and approve documents. - Peer
Reviews: Inspections (more formal) and walkthroughs (less formal). - Expert Opinions: External evaluations
when internal expertise is limited.

3. Software Project Management (SPM)

Why Projects Fail: - Poorly Defined Requirements: Ambiguous or incomplete requirements cause scope
creep and incorrect implementations. - Unplanned Changes: Without a change management strategy,
changes can derail timelines and inflate costs. - Inadequate Resources: Not having enough skilled team
members, time, or budget can prevent successful delivery. - Lack of Stakeholder Involvement: When
users and sponsors aren’t actively engaged, requirements become misaligned with actual needs.

Project Lifecycle Phases: - Initiation: Define the project goals, constraints, and feasibility. - Planning: Set
out the roadmap, assign roles, estimate cost/time, and define risk strategies. - Execution: Actual
development of software based on plans. - Monitoring & Control: Track progress, manage changes, and
ensure project stays on course. - Closure: Finalize all activities, deliver the product, release resources, and
evaluate performance.

Management Spectrum (4 Ps): - People: Core to any project’s success. Encompasses leadership,
communication, and team skills. - Product: The software system being built; must be clearly defined in
terms of scope and objectives. - Process: Chosen methodology (Agile, Waterfall, etc.) that governs how
tasks are performed. - Project: Planning and managing resources, schedule, and deliverables to build the
product.

Team Structures: - Closed Paradigm: Traditional hierarchy; tasks assigned top-down. - Open Paradigm:
Flexible structure encouraging innovation. - Random Paradigm: Informal structure; relies on individual
initiative. - Synchronous Paradigm: Independent work with minimal communication; suited for modular
problems.

Avoiding Toxicity: - Avoid chaotic work conditions, ensure clarity of roles, maintain morale, and use a
suitable process model.

Communication Methods: - Formal, Impersonal: Documents, reports, milestones. - Formal,

4. Project Scheduling

Common Causes for Project Delay: - Unrealistic Deadlines: Imposed without consultation or estimation. -
Changing Requirements: No buffer included in the schedule for scope adjustments. - Underestimation:

2
Misjudging the effort or resources required. - Unforeseen Risks: Technical or human challenges not
planned for. - Poor Communication: Misalignment among team members causing rework. - Weak
Monitoring: Management failing to identify delays early.

Scheduling Fundamentals: - Compartmentalization: Breaking the project into manageable tasks and
subtasks. - Interdependency: Understanding which tasks depend on others and sequencing them logically.
- Time Allocation: Assigning appropriate durations and scheduling for each task. - Effort Validation:
Ensuring resource allocation doesn't exceed team capacity at any point. - Defined Responsibilities:
Assigning tasks to specific team members for accountability. - Defined Outcomes: Each task should result
in a clear deliverable or milestone. - Milestones: Key checkpoints (e.g., design approval) that validate
progress.

Task Network (Activity Network): - A visual graph showing task sequences, parallel activities, and
dependencies. - Critical Path: Longest sequence of dependent tasks. Any delay here delays the entire
project.

Timeline Chart (Gantt Chart): - Visual schedule with tasks shown as bars across calendar dates. -
Concurrent tasks stack vertically. - Milestones marked with diamonds.

Effort Distribution (40-20-40 Rule): - 40% Analysis & Design: Understanding and structuring the problem.
- 20% Coding: Actual software development. - 40% Testing: Verification, validation, and bug fixing. - This
ensures robust planning and quality control over rushed development.

This summary captures all key concepts and terminology required for your quiz based on the lecture slides.
Let me know if you'd like practice questions or flashcards!