Software Engineering Q&A

Cheatsheet Content

Part A: Very Short Answers (1 Mark Each) UNIT-I: Introduction to Software Engineering Define Software Engineering. Software Engineering is a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. What is a Software Myth? Software myths are misleading beliefs about software that arise due to historical perspectives, management pressures, or developer practices. Name two evolutionary process models. Two evolutionary process models are the Spiral Model and the Incremental Model. List two Agile models. Two Agile models are Scrum and Extreme Programming (XP). UNIT-II: Software Requirements Distinguish between Functional and Non-functional Requirements. Functional requirements describe what the system *does*, while non-functional requirements describe *how* the system performs a function (e.g., performance, security). What is Requirements Elicitation? Requirements elicitation is the process of gathering information from stakeholders about the needs and expectations for a software system. UNIT-III: System Models and Design Engineering Name two types of System Models. Two types of system models are Context Models and Behavioral Models. What is a Design Pattern? A design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. UNIT-IV: Testing Strategies and Metrics What is Black-box Testing? Black-box testing examines functionality without knowing internal structure; it focuses on inputs and outputs. UNIT-V: Risk and Quality Management Define Software Risk. A software risk is a potential problem that might occur, adversely affecting the success of a software project. Part B: Long Answers (10 Marks Each) UNIT-I: Introduction to Software Engineering Question 2: Process Models 2 (a) Explain the Waterfall Model in detail, including its phases, advantages, and disadvantages. The Waterfall Model is a linear sequential life cycle model where each phase must be completed before the next begins. It's simple but rigid. Phases: Requirements: Gather and document all system needs. Design: Plan system architecture based on requirements. Implementation: Code the software units. Testing: Integrate units and verify the system works as specified. Deployment: Release the software to the customer. Maintenance: Ongoing support, bug fixes, and enhancements. Diagram: Waterfall Model Requirements Design Implementation Testing Deployment Maintenance Title: The Waterfall Model of Software Development Explanation: The diagram shows a sequential flow from Requirements to Maintenance. Each box is a phase, and arrows indicate strict, unidirectional progression. Data flows from one completed phase to the next. Advantages: Simple, well-documented, clear milestones. Disadvantages: Inflexible, costly to change requirements late, no parallel development. 2 (b) Discuss the Capability Maturity Model Integration (CMMI) as a generic view of the process. CMMI is a process improvement approach that guides organizations to improve performance. It views software development as a layered technology, emphasizing continuous improvement through maturity levels. Maturity Levels: Initial (1): Ad-hoc, chaotic processes. Managed (2): Project-level planning and control. Defined (3): Organizational standard processes. Quantitatively Managed (4): Processes measured and controlled statistically. Optimizing (5): Continuous process improvement. Diagram: CMMI Maturity Levels Level 1: Initial Level 2: Managed Level 3: Defined Level 4: Quantitatively Managed Level 5: Optimizing Title: CMMI Maturity Levels Explanation: The diagram shows a stack of increasing maturity levels. Moving up implies more predictable and efficient processes. Higher levels encompass the practices of lower levels. Benefits: Improved quality, customer satisfaction, better project management, predictability. Question 3: Agile Development 3 (a) Explain the principles of Agile Software Development and discuss its advantages over traditional models. Agile is an iterative, incremental approach emphasizing rapid delivery, collaboration, and adaptability to change. Principles (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. Diagram: Agile Development Iteration Working Software Plan Develop Test Review Feedback Title: Agile Iteration Cycle Explanation: The diagram shows a continuous loop: Plan, Develop, Test, Review, Feedback, Adapt. Each cycle delivers working software, emphasizing iteration and continuous improvement. Advantages over Traditional Models: Flexibility: Adapts to changing requirements. Faster Delivery: Working software delivered frequently. Customer Satisfaction: Continuous involvement. Reduced Risk: Early detection of issues. 3 (b) Describe the different types of Process Models, including incremental and evolutionary process models. Process models provide frameworks for software development. They include linear, incremental, and evolutionary types. 1. Linear Sequential (e.g., Waterfall): Phases completed one after another. Good for stable requirements. 2. Incremental: System built in small, functional increments. Each increment goes through mini-waterfall cycles. Diagram: Incremental Model Req Design Code Test Increment 1 Req Design Code Test Increment 2 Increment N (Final Product) Title: Incremental Model Explanation: Multiple rows show mini-waterfall cycles for each increment. Arrows indicate progression to the next increment, building functionality iteratively. 3. Evolutionary (e.g., Prototyping, Spiral): Produce increasingly complete versions. Good for vague requirements. Prototyping: Build a quick model, get feedback, refine. Spiral Model: Iterative, risk-driven, combines waterfall and prototyping, emphasizing risk analysis at each cycle. Diagram: Spiral Model Risk Analysis Development Planning Evaluation Title: Spiral Model Explanation: The spiral shows iterative cycles, each with Planning, Risk Analysis, Development, and Evaluation. Each loop represents a phase, moving outwards as the project progresses. 4. Agile Models (e.g., Scrum, XP): Focus on flexibility, customer collaboration, and working software. UNIT-II: Software Requirements Question 4: Software Requirements 4 (a) Differentiate between Functional and Non-functional Requirements with suitable examples. Software requirements define what a system must do (functional) and how well it must do it (non-functional). Functional Requirements: What: Services the system provides. Focus: User goals, system behaviors. Example: "The system shall allow users to log in." Non-functional Requirements (NFRs): How: Quality attributes, constraints. Focus: Performance, security, usability, reliability. Example: "The system shall respond within 3 seconds." Categories: Performance, Security, Usability, Reliability, Scalability, Maintainability, Portability. Table: Comparison of Functional and Non-functional Requirements Feature Functional Requirements Non-functional Requirements What it specifies What the system does How the system performs Focus Features, actions Quality, constraints Examples Login, search Speed, security 4 (b) Describe the Requirements Engineering Process, including its key activities. Requirements Engineering (RE) is a systematic process to define, document, and maintain software requirements. Key Activities: Feasibility Studies: Determine if the project is viable (technical, economic, operational). Elicitation & Analysis: Gather requirements from stakeholders (interviews, workshops) and analyze them for clarity, consistency. Specification: Document requirements in a clear, unambiguous Software Requirements Specification (SRS). Validation: Ensure documented requirements accurately reflect stakeholder needs (reviews, prototyping). Management: Handle changing requirements, traceability, and version control throughout the project. Diagram: Requirements Engineering Process Feasibility Elicitation & Analysis Specification Validation Management SRS Document Title: Requirements Engineering Process Flow Explanation: The diagram shows sequential steps: Feasibility, Elicitation & Analysis, Specification, Validation, and an overarching Management. Arrows indicate flow, with feedback loops to earlier stages, culminating in the SRS Document. Question 5: User and System Requirements 5 (a) Discuss User Requirements and System Requirements, and explain why both are important. Requirements are expressed at different levels: User (what the user wants) and System (how the system will deliver it). User Requirements: Definition: High-level statements in natural language about system services. Audience: Customers, end-users. Purpose: Contract, overview of system goals. Example: "The system shall allow a customer to view their order history." System Requirements: Definition: Detailed, technical specifications of system functions and constraints. Audience: Developers, testers. Purpose: Basis for design and implementation. Example: "The system shall retrieve order history from 'Orders' database table using SQL." Importance of Both: Bridging the Gap: User requirements define the problem; system requirements define the solution. Communication: User reqs for stakeholders, system reqs for technical teams. Validation & Verification: User reqs validate the final product; system reqs verify component implementation. 5 (b) What is an Interface Specification? Explain its role in defining software requirements. An interface specification describes how different components or systems interact, defining boundaries and communication protocols. Types of Interfaces: User Interface (UI): How humans interact with software. Hardware Interface: Software interaction with hardware. Software Interface (API): How software modules/systems communicate. Communication Interface: How systems communicate over networks. Role in Requirements: Precise Interaction: Defines exact communication points. Parallel Development: Allows separate teams to work concurrently. Integration: Ensures components fit together smoothly. Testability: Provides clear points for testing interactions. UNIT-III: System Models and Design Engineering Question 6: System Models 6 (a) Describe different types of System Models used in software engineering. System models are simplified representations of a system, used for understanding and communication. Types of System Models: Context Models: Show system boundaries and its interactions with the external environment (e.g., Context Diagram). Behavioral Models: Describe how the system responds to events (e.g., Use Case, Sequence, State Machine Diagrams). Data Models: Describe data structure and relationships (e.g., Entity-Relationship Diagrams). Object Models: Describe system in terms of objects and their interactions (e.g., Class Diagrams). Structured Methods: Combine process, data, and behavioral modeling (e.g., Data Flow Diagrams). 6 (b) Explain the concepts of Design Process and Design Quality in software engineering. Software design translates requirements into a detailed plan. Design quality ensures this plan leads to good software. Design Process: Systematic approach to creating a software plan. Architectural Design: Define overall system structure, components, and interactions. Interface Design: Specify how components/system interact with each other and users. Component Design: Detail internal structure, algorithms for each component. Database Design: Design data storage and schema. Design Quality: Excellence of the software design, impacting robustness, maintainability, performance. Key Attributes: Modularity: System divided into independent units. Cohesion: Elements within a module are functionally related. Coupling: Minimal dependencies between modules. Maintainability: Easy to modify and fix. Reusability: Components can be used elsewhere. Question 7: Design Concepts and Architecture 7 (a) Discuss fundamental Design Concepts in software engineering. Fundamental design concepts help manage complexity and ensure quality in software systems. Concepts: Abstraction: Hiding complex details, showing essentials. Modularity: Decomposing system into independent units. Information Hiding: Concealing internal implementation details. Functional Independence (Cohesion & Coupling): High cohesion (single purpose), low coupling (minimal dependencies). Refinement: Progressively adding detail to a high-level design. Architectural Styles/Patterns: Reusable solutions for structuring systems. 7 (b) Explain Software Architecture and describe various Architectural Styles and Patterns. Software architecture is the fundamental organization of a system, defining its components, relationships, and design principles. Software Architecture: Purpose: Address non-functional requirements, manage complexity. Components: Processing elements, data elements, connectors. Architectural Styles/Patterns: Reusable solutions for structuring systems. 1. Layered Architecture: System organized into hierarchical layers (e.g., Presentation, Business, Data Access). Diagram: Layered Architecture Presentation Layer Business Layer Data Access Layer Title: Layered Architecture Explanation: Shows a stack of layers (Presentation, Business, Data Access). Arrows indicate downward flow of requests, enforcing separation of concerns. 2. Client-Server Architecture: Divides functionality between clients (requesters) and servers (providers). Diagram: Client-Server Architecture Client Server Title: Client-Server Architecture Explanation: A client sends requests to a server, which processes them and sends responses back. Arrows show bidirectional request-response flow. 3. Model-View-Controller (MVC): Separates application into Model (data/logic), View (UI), Controller (input handler). 4. Microservices Architecture: Application as a suite of small, independently deployable services. UNIT-IV: Testing Strategies and Metrics Question 9: Testing Strategies 9 (a) Describe the different types of testing strategies for conventional software, including black-box and white-box testing. Testing strategies ensure software quality. They include unit, integration, system, and acceptance testing, using black-box or white-box approaches. Conventional Strategies: Unit Testing: Tests individual components in isolation. Integration Testing: Tests interfaces between integrated units. System Testing: Tests the complete system against requirements. Acceptance Testing: Verifies system meets user needs, done by users. Black-box Testing: Definition: Tests functionality without knowing internal code/design. Focus: External behavior, inputs, outputs. Techniques: Equivalence Partitioning, Boundary Value Analysis. Applicability: Integration, system, acceptance testing. White-box Testing: Definition: Tests internal structure with knowledge of code/design. Focus: Internal logic, code paths, branches. Techniques: Statement Coverage, Branch Coverage. Applicability: Unit, integration testing. 9 (b) Explain Verification and Validation testing, and discuss System Testing. Verification and validation are complementary processes for quality assurance. System testing is a key validation activity. Verification: "Are we building the product right?" Checks if software artifacts conform to specifications (e.g., reviews, inspections). Validation: "Are we building the right product?" Checks if the final product meets user needs and expectations (e.g., system testing, acceptance testing). System Testing: Purpose: Evaluate the complete, integrated system against all specified requirements (functional and non-functional). Objectives: Verify functionality, performance, security; identify defects; test end-to-end flow. Types: Functional, Performance, Security, Usability, Reliability testing. Diagram: V-Model Illustrating Verification and Validation Bus. Req. User Req. Sys. Req. Design Coding Unit Test Integration Test System Test Acceptance Test Verif. Code Verif. Design Valid. Sys. Req. Valid. User Req. Verification Validation Title: V-Model: Verification and Validation Activities Explanation: The V-Model shows development phases on the left (Verification) and corresponding testing phases on the right (Validation). Each testing phase verifies/validates artifacts from the opposing development phase, ensuring quality throughout. Question 10: Metrics for Process and Products 10 (a) Discuss software quality and metrics for the analysis model. Software quality ensures a product meets requirements and user needs. Metrics for the analysis model (requirements) assess the quality of these requirements. Software Quality: Definition: Degree to which software fulfills requirements and implicit needs. Attributes: Functionality, Reliability, Usability, Efficiency, Maintainability, Portability (ISO 9126). Metrics for Analysis Model (Requirements): Completeness: All necessary requirements are specified (e.g., number of TBDs). Consistency: Requirements don't contradict each other (e.g., number of conflicts). Unambiguity: Each requirement has only one interpretation (e.g., subjective terms count). Verifiability: Requirements can be tested (e.g., % with test cases). Traceability: Links between requirements and other artifacts (e.g., % linked to design). These metrics help identify and fix quality issues early in the requirements phase. 10 (b) Discuss metrics for the design model and metrics for source code. Metrics for design and code evaluate the internal quality of the software, impacting maintainability and reliability. Metrics for Design Model: Assess design quality (modularity, cohesion, coupling). Architectural Metrics: Structural complexity, number of interfaces. Object-Oriented Metrics (CK Suite): WMC (Weighted Methods Per Class): Class complexity. CBO (Coupling Between Objects): Inter-class dependencies. LCOM (Lack of Cohesion in Methods): Cohesion within a class. Function-Oriented Metrics: Coupling and Cohesion measures for modules. Metrics for Source Code: Assess complexity and maintainability of code. Size Metrics: Lines of Code (LOC): Simple count. Function Points (FP): Functional size, language-independent. Complexity Metrics: Cyclomatic Complexity: Number of independent paths through code ($V(G) = E - N + 2P$). High values ($>10-15$) indicate complex modules. Halstead's Metrics: Based on operators and operands. Maintainability Index (MI): Composite metric for code maintainability. UNIT-V: Risk and Quality Management Question 11: Risk Management and Quality Management 11 (a) Differentiate between Reactive and Proactive risk strategies and explain the RMMM plan. Risk management involves identifying, assessing, and controlling risks. Strategies are either reactive (after occurrence) or proactive (before occurrence). Reactive Risk Strategy: Approach: "Wait and see," resolve problems after they occur. Focus: Crisis management. Outcome: Higher costs, delays, "firefighting." Proactive Risk Strategy: Approach: Identify risks early, plan mitigation. Focus: Prevention, early detection. Outcome: Minimized impact, more stable projects. RMMM Plan (Risk Mitigation, Monitoring, and Management Plan): A detailed plan for addressing identified risks proactively. Components for each risk: Risk Identification: Clear description of the risk. Risk Probability & Impact: Likelihood and severity assessment. Risk Mitigation: Actions to reduce probability/impact (preventive). Risk Monitoring: Tracking risks and triggers. Risk Management (Contingency): Actions if risk occurs (reactive). Question 12: Quality Management 12 (a) Explain Quality Concepts and Software Quality Assurance (SQA). Quality management ensures high-quality software. It involves quality concepts and Software Quality Assurance (SQA). Quality Concepts: Quality: Degree to which software meets requirements (explicit and implicit). Quality Control (QC): Product-focused, detects defects (e.g., testing). Quality Assurance (QA): Process-focused, prevents defects (e.g., process definition, audits). Software Quality Assurance (SQA): A planned, systematic set of activities to ensure software processes and products conform to standards. Key SQA Activities: SQA Plan: Documenting SQA work. Standards & Procedures: Defining and enforcing development rules. Technical Reviews: Peer examination of artifacts to find errors. Testing: Planning and strategizing testing efforts. Defect Tracking: Reporting, tracking, and resolving defects. Audits: Independent checks for compliance. 12 (b) Discuss Software Reviews, Formal Technical Reviews, Software Reliability, and the ISO 9000 quality standards. These elements contribute to building reliable and high-quality software. Software Reviews: Systematic examination of software artifacts to detect errors. Informal: Desk checks, walkthroughs. Formal Technical Reviews (FTRs): Structured process with roles and procedures (e.g., Inspections) for early defect detection. Software Reliability: Probability of failure-free operation for a specified time in a given environment. Measured by MTTF, MTBF. Achieved through fault avoidance, detection, and tolerance. ISO 9000 Quality Standards: International standards for Quality Management Systems (QMS). ISO 9001: Provides requirements for a QMS. Principles: Customer focus, leadership, process approach, continuous improvement. Benefits: Improved customer satisfaction, consistency, market credibility.