Software Engineering Syllabus

Cheatsheet Content

Course Overview Subject: Software Engineering Course Code: COMP 401 Level: B.E./B.Sc 4th Year 1st Semester Credit Hours: 3 Objective: To provide comprehensive knowledge of software engineering principles, methodologies, and tools, enabling students to develop high-quality, reliable, and maintainable software systems effectively. Covers theoretical foundations and practical applications. Chapter 1: Introduction to Software Engineering (4 hrs) 1.1 Software and Software Engineering Fundamentals What is Software? Definition: Computer programs, data structures, and documentation. Dual role: Product and vehicle for delivering a product. Characteristics: Developed rather than manufactured, doesn't "wear out" but can deteriorate (legacy systems). What is Software Engineering? Definition: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. Goals: Produce high-quality software, on time, within budget, meeting user needs. Challenges: Managing complexity, ensuring quality, adapting to change, improving productivity. Evolution of Software Engineering Early years (1950s-1970s): Batch systems, individual programming. Structured programming era (1970s-1980s): Top-down design, modularity. Object-Oriented era (1980s-1990s): Reusability, encapsulation. Web and Agile era (2000s-Present): Rapid development, distributed systems. 1.2 Comparison: Hardware vs. Software Engineering Hardware Engineering: Focus: Physical components, manufacturing, wear-and-tear. Development: Tangible, often involves physical prototyping. Cost: Manufacturing cost often dominates. Software Engineering: Focus: Logical constructs, intellectual effort, no physical wear. Development: Abstract, logical design, code implementation. Cost: Development cost often dominates; maintenance is significant. Complexity: Often higher due to logical interdependencies and configurability. 1.3 Importance of Software Engineering Addressing Complexity: Provides frameworks to manage large, intricate systems. Ensuring Quality: Methods for reliability, performance, security, usability. Cost Control: Reduces development and maintenance costs through systematic approaches. Timeliness: Delivers systems within scheduled deadlines. Maintainability & Evolvability: Facilitates future changes and enhancements. Risk Management: Identifies and mitigates project risks. Scalability: Designs systems that can grow with demand. Chapter 2: Software Process Models (7 hrs) 2.1 Introduction to Software Process Models Definition: A simplified representation of a software process, showing its various activities, tasks, and deliverables, and the ordering of these activities. Purpose: Provides a framework for managing complex software development, improving predictability, efficiency, and quality. Generic Process Framework Activities: Communication, Planning, Modeling (Analysis, Design), Construction (Code, Test), Deployment. 2.2 Traditional Software Process Models Waterfall Model (Linear Sequential Model): Phases: Requirements, Design, Implementation, Verification, Maintenance. Characteristics: Strict sequential flow, document-driven, suitable for well-understood requirements. Advantages: Simple, easy to manage, clear documentation. Disadvantages: Inflexible, difficult to accommodate changes, late error detection. Waterfall Model Diagram: Requirements Design Implementation Verification & Maintenance V-Model (Verification and Validation Model): Extension of Waterfall, emphasizes testing activities corresponding to development phases. Verification (left side): Unit Design $\rightarrow$ Unit Test, System Design $\rightarrow$ System Test. Validation (right side): Requirements $\rightarrow$ Acceptance Test, Architectural Design $\rightarrow$ Integration Test. Advantages: Early test planning, clear traceability. Disadvantages: Still sequential, less flexible to changes. V-Model Diagram: Requirements System Design Module Design Coding Unit Testing Integration Test System Test Acceptance Test Evolutionary Process Models: Prototyping Model: Build a quick prototype, gather user feedback, refine, and then build the actual system. Types: Throwaway prototyping, evolutionary prototyping. Advantages: Reduces risk, clarifies requirements, user involvement. Disadvantages: Can lead to "quick and dirty" systems, scope creep. Spiral Model (Boehm): Risk-driven iterative approach, combining elements of waterfall and prototyping. Four phases per loop: Planning, Risk Analysis, Engineering, Evaluation. Advantages: Good for large, high-risk projects, handles changes well. Disadvantages: Complex, requires considerable risk assessment expertise. Spiral Model Diagram: Start Planning Risk Analysis Engineering Evaluation Component-Based Development (CBD): Focuses on building software systems by assembling pre-existing, reusable software components. Advantages: Faster development, increased reliability, reduced cost. Disadvantages: Component integration issues, dependency on third-party components. Formal Methods Model: Employs mathematical notation and proof techniques to specify and verify software. Advantages: High reliability, reduces ambiguity, strong error detection. Disadvantages: Requires specialized skills, high cost, not suitable for all projects. Unified Process (UP): Iterative and incremental, use-case driven, architecture-centric, and risk-driven. Phases: Inception, Elaboration, Construction, Transition. Workflows: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment. Advantages: Strong emphasis on architecture and risk, good for large teams. Disadvantages: Can be complex, heavy documentation. 2.3 Agile Development Agile Manifesto: Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan. Principles: Early and continuous delivery, welcoming change, frequent delivery, close daily cooperation, motivated individuals, face-to-face conversation, working software, sustainable development, technical excellence, simplicity, self-organizing teams, regular reflection. Advantages: Flexibility, quick response to change, increased customer satisfaction, higher quality. Disadvantages: Less documentation, can be challenging in large organizations, requires active customer involvement. 2.4 Specific Agile Methodologies Extreme Programming (XP): Values: Simplicity, Communication, Feedback, Courage, Respect. Practices: Pair programming, Test-Driven Development (TDD), Continuous Integration, Small Releases, Refactoring, Collective Code Ownership, On-site Customer. Feature-Driven Development (FDD): Process: Develop Overall Model, Build Feature List, Plan By Feature, Design By Feature, Build By Feature. Focus: Short iterations driven by "features" (small, client-valued functions). Lean Software Development: Principles (from Lean manufacturing): Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible, Empower the Team, Build Integrity In, See the Whole. Scrum: Roles: Product Owner: Defines product vision, manages Product Backlog. Scrum Master: Facilitates Scrum process, removes impediments. Development Team: Self-organizing, cross-functional, develops the increment. Events (Ceremonies): Sprint: Time-boxed iteration (typically 1-4 weeks). Sprint Planning: Team selects items from Product Backlog for the Sprint Backlog. Daily Scrum (Stand-up): Short daily meeting to synchronize activities. Sprint Review: Team presents completed work to stakeholders. Sprint Retrospective: Team inspects and adapts its process. Artifacts: Product Backlog: Prioritized list of all desired features. Sprint Backlog: Subset of Product Backlog selected for current sprint. Increment: Sum of all Product Backlog items completed during a sprint and previous sprints. Scrum Workflow Diagram: Product Backlog Sprint Planning Sprint Backlog Sprint (1-4 Weeks) Daily Scrum Dev Team Potentially Shippable Increment Sprint Review Retrospective Chapter 3: System Engineering (4 hrs) 3.1 Introduction to System Definition: A collection of interrelated components working together to achieve a common objective. Components: Hardware, software, data, people, processes. Properties: Emergent properties (properties of the whole not present in parts), decomposition, hierarchy. 3.2 System and its Environment System Boundary: Defines what is inside and outside the system. Interfaces: Points of interaction between the system and its environment or other systems. Context Diagram: A top-level DFD showing the system as a single process and its interactions with external entities. System Context Diagram: User Database External Sys System Under Development Input Output Data Req Write Data Send Request Stakeholders: Individuals or groups who have an interest in the system. 3.3 System Engineering Process Definition: A holistic, interdisciplinary approach to designing, realizing, and managing complex systems over their life cycles. Key Activities: System Requirements Definition: Defining overall system functionality and constraints. System Design: Decomposing the system into subsystems (hardware, software, human), allocating requirements. Subsystem Development: Engineering of individual subsystems. System Integration: Combining subsystems and verifying interfaces. System Validation: Ensuring the integrated system meets overall requirements. System Deployment & Operation: Installation, training, ongoing use. Role in Software Engineering: Software is often a component of a larger system; system engineering provides the context for software development. Chapter 4: Requirement Engineering (6 hrs) 4.1 Introduction to Requirement Engineering Definition: The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. Importance: Foundation for all subsequent development activities; errors here are costly to fix later. Challenges: Eliciting complete and unambiguous requirements, managing changing requirements, dealing with conflicting stakeholder needs. 4.2 Requirement Engineering Process Elicitation (Discovery): Gathering requirements from stakeholders. Techniques: Interviews, questionnaires, brainstorming, use cases, user stories, scenarios, ethnography, prototyping, observation. Specification (Documentation): Writing down requirements clearly and unambiguously. Software Requirements Specification (SRS) document. Natural language, structured natural language, design description languages, graphical notations (UML), mathematical specifications. Negotiation and Prioritization: Resolving conflicts and ranking requirements based on business value, technical feasibility, and risk. Modeling: Creating representations of the system's functions, data, and behavior. Requirement Engineering Process Flow: Elicitation Analysis Specification Validation Management 4.3 Requirement Validation Purpose: To check that the requirements define the system that the customer really wants. Techniques: Requirements Reviews: Systematic examination of the SRS by stakeholders. Prototyping: Building a mock-up to get early feedback. Test Case Generation: Deriving tests from requirements to expose problems. Automated Consistency Analysis: Using tools to check for contradictions. Characteristics of Good Requirements: Unambiguous, complete, consistent, verifiable, modifiable, traceable, prioritized. 4.4 Requirement Evolution (Management) Definition: Managing changes to requirements throughout the software lifecycle. Change Management Process: Change request, impact analysis, change implementation, version control. Traceability: Ability to link requirements to design, code, and test cases. Configuration Management: Controlling versions of requirements and related artifacts. 4.5 Requirement Analysis Functional Requirements: Describe what the system *should do* (e.g., "The system shall allow users to log in"). Non-Functional Requirements (NFRs): Describe how the system *should be* (e.g., performance, security, usability, reliability, scalability, maintainability, portability). Often more challenging to define and verify. Use Cases: Describe interactions between users (actors) and the system to achieve a goal. Simple Use Case Diagram: Customer System Boundary (Online Shop) Place Order View History User Stories: Short, simple descriptions of a feature told from the perspective of the person who desires the new capability. (e.g., "As a [role], I want [goal] so that [benefit]"). Scenarios: Detailed descriptions of a sequence of events. Data Modeling: Entity-Relationship Diagrams (ERD) to represent data structures. Behavioral Modeling: State Diagrams, Activity Diagrams to represent system behavior. Chapter 5: Software Project Management (7 hrs) 5.1 Introduction to Project Management Software Project: A temporary endeavor undertaken to create a unique software product, service, or result. Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Goals (The Triple Constraint/Iron Triangle): Managing scope, time, cost, and quality. Balancing these constraints. Project Management Triple Constraint: Scope Cost Time Quality Attributes of a good project manager: Leadership, communication, problem-solving, negotiation, technical skills. 5.2 Management Activities Planning: Defining objectives, scope, tasks, resources, and schedule. Organizing: Structuring the team, allocating responsibilities. Staffing: Acquiring and developing the project team. Directing: Leading the team, motivating, resolving conflicts. Controlling: Monitoring progress, tracking deviations, taking corrective actions. Risk Management: Identifying, analyzing, planning for, and monitoring risks. Configuration Management: Managing changes to software artifacts. (Source code, documentation, etc.) Reporting: Communicating project status to stakeholders. 5.3 Project Planning Scope Management: Defining what is included and excluded from the project. Objective Setting: Establishing SMART (Specific, Measurable, Achievable, Relevant, Time-bound) objectives. Task Definition: Breaking down the project into manageable tasks. Deliverable Identification: What outputs will be produced. Product vs. Process Metrics: Measuring characteristics of the software product vs. the development process. 5.4 Activity Organization Work Breakdown Structure (WBS): A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish project objectives and create the required deliverables. Work Breakdown Structure (WBS) Example: Project A Phase 1 Phase 2 Phase 3 Task 1.1 Task 1.2 Task 1.3 Organizational Structures: Functional, projectized, matrix. Team Structures: Decentralized, centralized, chief programmer team. Roles and Responsibilities: Defining who does what. 5.5 Project Scheduling Techniques: Gantt Charts: Bar charts illustrating project schedules, showing start and end dates of tasks. Gantt Chart Example: Week 1 Week 2 Week 3 Week 4 Task A Task B Task C Task D PERT (Program Evaluation and Review Technique): Probabilistic approach for estimating task durations, considering optimistic, most likely, and pessimistic times. CPM (Critical Path Method): Deterministic approach for identifying the longest path of dependent activities (critical path), which determines the minimum project duration. Critical Path Analysis: Identifying tasks whose delay will delay the entire project. Resource Allocation and Leveling: Assigning resources to tasks and resolving resource conflicts to optimize schedules. Effort Distribution: How effort is spread across project phases (e.g., 40-20-40 rule for analysis-design-code/test). Chapter 6: Software Project Planning (7 hrs) 6.1 Introduction to Software Project Planning Purpose: To establish a pragmatic plan for the software project, addressing "what," "how," and "when." Key Activities: Estimation, scheduling, risk analysis, resource planning. Iterative Planning: Refining plans as the project progresses and more information becomes available. 6.2 Resources for Software Projects Human Resources: Skills, experience, team size, structure. Reusable Software Resources: Existing components, libraries, frameworks. Environmental Resources: Hardware, software tools (CASE tools, IDEs, version control), network infrastructure. Resource Management: Planning for acquisition, allocation, and utilization of resources. 6.3 Software Project Estimation Purpose: To predict the effort, cost, and duration required for a software project. Factors Influencing Accuracy: Project size, complexity, team experience, technology stability, requirement volatility. Types of Estimation: Effort: Person-months or person-hours. Cost: Monetary budget. Duration: Calendar time. Techniques: Expert judgment, analogy, decomposition, empirical models. 6.4 Decomposition Techniques for Estimation Definition: Breaking down the overall project into smaller, more manageable components for individual estimation. Function-Based Decomposition: Focuses on the functional requirements of the system. Estimates effort for each major function (e.g., login module, report generation). Problem-Based Decomposition: Breaks down the overall problem into sub-problems. Each sub-problem is then estimated. Process-Based Decomposition: Estimates effort required for each phase of the software process (e.g., requirements, design, coding, testing). Often uses historical data for effort distribution across phases. 6.5 Empirical Estimation Models COCOMO (Constructive Cost Model): Developed by Barry Boehm. Estimates effort and schedule based on lines of code (LOC) or function points and a set of "cost drivers" (e.g., reliability, analyst capability, tool experience). Versions: Basic, Intermediate, Detailed COCOMO. COCOMO II: Modern version for component-based and object-oriented development. Function Point Analysis (FPA - Albrecht Method): Estimates project size based on the number and complexity of functional requirements (inputs, outputs, inquiries, files, external interfaces). Independent of programming language. Calculates Unadjusted Function Points (UFP) and then Adjusted Function Points (AFP) using Value Adjustment Factors (VAF). Used for early stage estimation and benchmarking. Use Case Points (UCP): Estimation technique based on the number and complexity of use cases and actors in the system. Considers technical and environmental factors. Often used with object-oriented projects. Chapter 7: Software Quality Assurance (3 hrs) 7.1 Introduction to Software Quality Quality: Conformance to explicit and implicit requirements. Software Quality: The degree to which a software product meets specified requirements and customer expectations. Quality Control: A set of activities for ensuring quality in software products. Focuses on identifying defects. Quality Assurance (SQA): A set of activities designed to ensure that the development and maintenance processes are adequate to produce products that conform to requirements. Focuses on preventing defects. Software Quality Attributes: Functionality, Reliability, Usability, Efficiency, Maintainability, Portability (FURPS+). 7.2 Software Quality Assurance (SQA) SQA Activities: Defining SQA plan and standards. Conducting formal technical reviews. Applying multi-tiered testing strategies. Ensuring adherence to software engineering standards. Controlling changes and reporting deviations. Measuring quality (e.g., defect density, mean time to failure). SQA Goals: Improve product quality, improve process quality, reduce costs, achieve customer satisfaction. SQA Standards: ISO 9000: International standards for quality management systems. CMMI (Capability Maturity Model Integration): A process improvement approach that provides organizations with the essential elements for effective process improvement. 7.3 Software Reviews Purpose: To find errors and defects early in the development process. Benefits: Early defect detection (cheaper to fix), knowledge transfer, improved quality, reduced rework. Types of Reviews: Walkthroughs: Informal meeting where the author of a work product presents it to the team. Inspections (Fagan Inspection): Formal, structured review process with specific roles (moderator, reader, recorder, producer, inspector) and defect logging. Peer Reviews: General term for colleagues reviewing each other's work. Review Process: Planning, overview, preparation, meeting, rework, follow-up. Metrics for Reviews: Number of defects found, defect density, effort spent on reviews. Chapter 8: Software Testing Techniques (7 hrs) 8.1 Introduction to Software Testing Definition: The process of executing a program with the intent of finding errors. Goals: Find defects, ensure software meets requirements, build confidence in the software, provide information for decision-making. Testing Principles: Testing shows presence of defects, not absence; exhaustive testing is impossible; early testing; defect clustering; pesticide paradox; testing is context-dependent; absence-of-errors fallacy. Verification vs. Validation: Verification: "Are we building the product right?" (Checking conformance to specifications). Validation: "Are we building the right product?" (Checking if it meets user needs). Verification vs. Validation: Verification "Are we building the product right?" Validation "Are we building the right product?" Internal processes, standards Customer needs, requirements 8.2 Types of Software Testing Testing Levels (V-Model): Unit Testing: Testing individual software components or modules in isolation. Focus on internal logic. Integration Testing: Testing the interfaces and interactions between integrated components. Strategies: Top-down, bottom-up, sandwich, big-bang. System Testing: Testing the complete and integrated software system against its requirements. Types: Functional, performance, security, usability, recovery, installation. Acceptance Testing: Formal testing conducted to determine if the system meets the acceptance criteria and to enable the customer to determine whether to accept the system. Alpha Testing: Performed by internal staff, often at the developer's site. Beta Testing: Performed by a selected group of end-users in a real environment. Testing Techniques (Execution-based): Black-box Testing (Functional Testing): Tests software functionality without knowledge of internal code structure. Techniques: Equivalence Partitioning: Dividing input data into partitions of equivalent data, where one test case from each partition is sufficient. Boundary Value Analysis (BVA): Testing at the boundaries of input ranges, as errors often occur there. Decision Table Testing: Used for complex logic with multiple conditions and actions. State Transition Testing: Tests behavior of a system based on different states and transitions. Use Case Testing: Deriving test cases from use cases. Black-box Testing Concept: Input Software System (Internal Logic Unknown) Expected Output Actual Output Compare White-box Testing (Structural Testing / Glass-box Testing): Tests internal structures or workings of an application, with knowledge of the code. Techniques: Path Testing (Basis Path Testing): Executes all independent paths in a module at least once. Uses cyclomatic complexity to determine the number of independent paths. Control Flow Testing: Tests all possible control flow paths. Data Flow Testing: Tests the flow of data through the program. Loop Testing: Tests loops for various conditions (zero, one, many iterations, boundary conditions). Code Coverage: Statement coverage, branch coverage, path coverage. White-box Testing Concept: Input Software System (Internal Logic Known) Expected Output Actual Output Compare Other Important Testing Types: Regression Testing: Re-executing existing test cases to ensure that recent changes have not adversely affected existing functionality. Performance Testing: Evaluating system behavior under various loads. Load Testing: Checks system performance under expected load. Stress Testing: Checks system performance under extreme load conditions. Scalability Testing: Measures system's ability to handle increasing workload. Security Testing: Identifying vulnerabilities and ensuring data protection. Usability Testing: Evaluating how easy and intuitive the system is for users. Configuration Testing: Testing how the software performs with different hardware and software configurations. Recovery Testing: Testing system's ability to recover from failures. References Sommerville, Ian. Software Engineering . 10th Edition. Pearson Education. Pressman, Roger S. Software Engineering, A Practitioner's Approach . 8th or 9th Edition. McGraw-Hill Education. Additional readings may be provided by the instructor.