Software Engineering Exam Study Notes PDF

Study Notes for Software Engineering Exam 1. Agile and Scrum Agile Overview: ​ Definition: Agile is a flexible software development method that focuses on iterative progress, collaboration, and adapting to change. ​ Core Values (Agile Manifesto): 1.​ Individuals and interacti...

Study Notes for Software Engineering Exam 1. Agile and Scrum Agile Overview: ​ Definition: Agile is a flexible software development method that focuses on iterative progress, collaboration, and adapting to change. ​ Core Values (Agile Manifesto): 1.​ Individuals and interactions over processes and tools. 2.​ Working software over comprehensive documentation. 3.​ Customer collaboration over contract negotiation. 4.​ Responding to change over following a plan. ​ 12 Principles of Agile: 1.​ Customer Satisfaction: Deliver valuable software quickly and continuously. 2.​ Welcome Changes: Even late-stage changes are embraced to meet customer needs. 3.​ Frequent Delivery: Deliver working software frequently (weeks, not months). 4.​ Measure Progress Through Working Software: Functional software is the primary indicator of progress. 5.​ Sustainable Development: Teams should maintain a constant pace indefinitely. 6.​ Face-to-Face Communication: Co-location and direct communication are most effective. 7.​ Motivated Individuals: Projects are built around trusted, motivated team members. 8.​ Attention to Technical Excellence: Focus on good design and technical quality. 9.​ Simplicity: Maximize the amount of work not done; simplicity is key. 10.​Self-Organizing Teams: Teams are given the freedom to organize their own work. 11.​Reflection and Adjustment: Regularly reflect on performance and adjust behavior to improve. 12.​Adaptability: Teams adapt to changing circumstances as needed. Scrum History: ​ Origins: Developed by Hirotaka Takeuchi and Ikujiro Nonaka in 1986. ​ Inspired By: Good practices in manufacturing (e.g., cameras, photocopiers). ​ Approach: Moves from a sequential to an iterative process where teams handle all aspects of development. Scrum Framework: ​ Definition: Scrum organizes development into short, focused periods (sprints) to deliver incremental improvements.  ​ Key Roles: ○​ Product Owner: Liaises with stakeholders, manages and prioritizes the backlog. ○​ Scrum Master: Facilitates Scrum practices, manages daily Scrum meetings, removes obstacles, and ensures team communication. Not a people or project manager. ○​ Developers: Self-organize to complete sprint goals. ​ Artifacts: ○​ Product Backlog: A dynamic list of features and tasks for the project, prioritized by the Product Owner. ○​ Sprint Backlog: Tasks planned for the current sprint, signed up for by developers (not assigned). ​ Meetings: ○​ Daily Scrum/Stand-up: A 15-minute meeting to review progress, plan the day, and discuss blockers. ○​ Sprint Review: Reviews completed work, demonstrates the product, and updates the backlog. ○​ Sprint Retrospective: Reflects on the sprint to identify improvements. Sprint Process: ​ Sprint Planning: ○​ Customer prioritizes work from the backlog and decides on new sprint tasks. ○​ Developers determine which tasks go into the sprint backlog. ​ Sprint Execution: ○​ Typically 1-4 weeks. ○​ Produces a deliverable, user-testable product version. ○​ Time-boxed; incomplete functions are excluded from the sprint deliverable. ​ Sprint Burn Down: ○​ Tracks sprint progress. ​ Release Burn Down: ○​ Tracks overall project progress across multiple sprints. Planning Poker: ​ Definition: A collaborative estimation technique integral to Agile (Scrum and XP). ​ Features: ○​ Consensus-based. ○​ Utilizes group intelligence. ○​ Reduces anchoring bias for more realistic estimates. 2. Extreme Programming (XP) Overview:  ​ Definition: Extreme Programming (XP) is a development method focused on writing high-quality software quickly while keeping teams and customers happy. It emphasizes teamwork and frequent updates. Key Practices: ​ Test-Driven Development (TDD): Write tests before writing the code to ensure it works as expected. ○​ Example: Before coding a login function, write a test to check if the login works correctly. ​ Pair Programming: Two developers work together on the same code. One types while the other reviews in real-time, catching errors early. ​ Continuous Integration: Regularly merge everyone’s code into one place to ensure everything works together. This avoids big problems later. ​ Small Releases: Deliver small updates to the software frequently (e.g., every 1-2 weeks) so users can see progress. ​ Simple Design: Keep the design as simple as possible to solve the current problem. Don’t overcomplicate things. ​ Customer Collaboration: Work closely with customers to make sure the software fits their needs and adapt quickly to feedback. Why XP is Effective: ​ Reduces bugs because of TDD and pair programming. ​ Users are happier because they see regular progress. ​ Developers work in a stress-free, well-organized way. 3. Software Cost Estimation and Project Management EQF and Bias: ​ EQF (Estimation Quality Factor): ○​ Shows how accurate your guesses are. ○​ Formula: EQF = 1 / Average(Deviation / Actual). ​ Bias: ○​ Checks if you’re overestimating or underestimating time and resources. ○​ Formula: Bias = (Average Estimate - Actual) / Actual. Chaos Report Findings: ​ Project Success Rates: ○​ Only 16% of projects are on time and budget. ○​ Successful projects involve user engagement, executive support, and clear requirements.  ​ Failure Factors: ○​ Poor planning (48%), incomplete requirements (51%), and lack of senior team members (42%). The Constraint Triangle: ​ Projects must balance time, cost, and quality. Enhancing one often compromises another. Mythical Man-Month: ​ Adding more people to a late project causes delays due to onboarding time and increased communication needs. Triage: ​ Definition: Prioritizing tasks or bugs based on severity and impact. ​ Categories: ○​ Must Do. ○​ Good to Do. ○​ Nice to Do. 4. Object-Oriented Design (OO) SOLID Principles: ​ Single Responsibility: Each class has one function. ​ Open/Closed: Classes should allow extension but not modification. ​ Liskov Substitution: Subclasses must work wherever their parent class is used. ​ Interface Segregation: Don’t force classes to implement unused methods. ​ Dependency Inversion: Depend on abstractions, not concrete implementations. Design Patterns: ​ Factory Pattern: ○​ Encapsulates object creation to increase flexibility. ○​ Example: Generating shapes like circles and squares. ​ Builder Pattern: ○​ Step-by-step creation of complex objects. ○​ Example: Building SQL queries. ​ Model-View-Controller (MVC): ○​ Separates data (Model), display (View), and logic (Controller) to improve maintainability. DRY Principle (Don’t Repeat Yourself): ​ Ensures data and logic are stored in one authoritative place. 5. Integrated Past Paper Questions and Answers Design Patterns: ​ MVC: ○​ Purpose: Splits the program into three parts: Model (data), View (UI), and Controller (logic). ○​ Benefits: ​ Easier to fix and update parts without breaking others. ​ Reuse the same Model for multiple Views. ​ Double-Checked Locking: ○​ Purpose: Stops multiple threads from creating the same resource. ○​ Benefits: ​ Saves memory and prevents bugs in multi-threaded programs. ​ Abstract Factory: ○​ Purpose: Creates families of related objects without mentioning their concrete types. Open/Closed Principle: ​ Definition: A class should be open to adding features but closed to modifying code.