SE Revision Notes PDF

Table of Contents Study Notes: Design Modelling 2 (lecture 7)............................................................ 6 1. User Interface Design (focus on this).........................................................................6 1.1 The Design Model...................................

Table of Contents Study Notes: Design Modelling 2 (lecture 7)............................................................ 6 1. User Interface Design (focus on this).........................................................................6 1.1 The Design Model...................................................................................................................... 6 1.2 Characteristics of Good Interface Design.................................................................................. 6 1.3 Common UI Design Errors......................................................................................................... 6 1.4 Golden Rules of UI Design......................................................................................................... 6 1.5 Interface Analysis...................................................................................................................... 7 1.6 Interface Design Issues............................................................................................................. 7 2. Component-Level Design..........................................................................................7 2.1 Views of Components............................................................................................................... 7 2.2 Basic Design Principles............................................................................................................. 7 2.3 Cohesion in Design................................................................................................................... 7 2.4 Design Guidelines..................................................................................................................... 8 2.5 Coupling in Design (focus on this)............................................................................................. 8 2.6 Steps in Component-Level Design............................................................................................. 8 3. Algorithm Design......................................................................................................9 3.1 Steps in Algorithm Design.......................................................................................................... 9 3.2 Algorithm Design Models.......................................................................................................... 9 3.3 Structured Procedural Design................................................................................................... 9 4. Component-Based Development..............................................................................9 4.1 Key Questions in Reuse............................................................................................................. 9 4.2 Challenges in Reuse.................................................................................................................. 9 4.3 Component Qualification.......................................................................................................... 9 4.4 Component Adaptation........................................................................................................... 10 4.5 Component Composition........................................................................................................ 10 Study Notes: WebApp and Mobile App Design (lecture 8)..................................... 10 1. WebApp Features (focus on this)............................................................................. 10 1.1 Overview................................................................................................................................. 10 1.2 Web Applications (WebApps).................................................................................................. 10 1.3 WebApp Architecture.............................................................................................................. 11 2. WebApp Design (focus on this)................................................................................ 11 2.1 When to Focus on Design........................................................................................................ 11 2.2 Quality Attributes.................................................................................................................... 11 2.3 User-Focused Quality Dimensions.......................................................................................... 11 2.4 Design Goals........................................................................................................................... 11 3. WebApp Design Components.................................................................................. 12 3.1 Interface Design...................................................................................................................... 12 3.2 Aesthetic Design..................................................................................................................... 13 3.3 Content Design....................................................................................................................... 13 3.4 Navigation Design................................................................................................................... 13 3.5 Architecture Design................................................................................................................. 14  3.7 Component-Level Design........................................................................................................ 14 4. Mobile App Features............................................................................................... 15 4.1 Overview................................................................................................................................. 15 4.2 Types of Mobile Apps............................................................................................................... 15 4.3 Mobile App Architecture.......................................................................................................... 15 5. Mobile App Design.................................................................................................. 15 5.1 Key Considerations................................................................................................................. 15 5.2 UI Design Considerations........................................................................................................ 15 5.3 Common Design Mistakes....................................................................................................... 15 5.4 Best Practices......................................................................................................................... 16 6. Development Process............................................................................................. 16 Steps in MobileApp Development................................................................................................. 16 Key Takeaways........................................................................................................... 16 Study Notes: Software Quality Assurance (lecture 9)............................................ 16 1. Software Quality..................................................................................................... 16 1.1 Definition................................................................................................................................ 16 1.2 Software Quality...................................................................................................................... 16 2. Dimensions of Software Quality (focus on this)........................................................ 17 2.1 David Garvin’s Dimensions...................................................................................................... 17 2.2 McCall’s Software Quality Factors........................................................................................... 17 3. The Software Quality Dilemma................................................................................ 17 4. Cost of Quality........................................................................................................ 17 4.1 Cost Categories...................................................................................................................... 17 4.2 Cost Implications.................................................................................................................... 18 5. Software Quality Assurance (SQA)........................................................................... 18 5.1 Key Elements.......................................................................................................................... 18 5.2 Role of the SQA Group............................................................................................................. 18 6. Statistical Software Quality Assurance.................................................................... 18 7. Software Safety...................................................................................................... 18 8. Software Quality Standards (focus on this).............................................................. 19 8.1 Major Standards...................................................................................................................... 19 9. Six Sigma for Software Engineering............................................................................................ 19 10. Achieving Software Quality................................................................................... 19 10.1 Practices............................................................................................................................... 19 10.2 Goals.................................................................................................................................... 19 Key Takeaways........................................................................................................... 19 Study Notes: Software Testing Techniques (lecture 10)................................... 20 1. Software Testing................................................................................................... 20 1.1 Definition................................................................................................................................ 20 1.2 Objectives of Testing.............................................................................................................. 20  1.3 Testability Factors.................................................................................................................. 20 1.4 Characteristics of a "Good" Test............................................................................................ 20 2. White-Box Testing (Structural Testing)................................................................. 20 2.1 Why is Coverage Important?................................................................................................. 21 2.2 Basis Path Testing................................................................................................................. 21 2.3 Control Structure Testing....................................................................................................... 21 2.4 Loop Testing........................................................................................................................... 21 3. Black-Box Testing (Functional Testing)................................................................ 21 3.1 Key Aspects........................................................................................................................... 21 3.2 Black-Box Testing Methods................................................................................................... 22 4. Testing Object-Oriented Applications................................................................... 22 4.1 Unique Challenges................................................................................................................ 22 4.2 Strategies for OO Testing...................................................................................................... 22 4.3 OO Testing Methods.............................................................................................................. 22 4.4 Other Methods....................................................................................................................... 22 5. Debugging............................................................................................................. 23 5.1 Debugging Process............................................................................................................... 23 5.2 Challenges in Debugging...................................................................................................... 23 5.3 Debugging Techniques.......................................................................................................... 23 5.4 Correcting Errors................................................................................................................... 23 Key Takeaways......................................................................................................... 23 1. Software Testing...................................................................................................................... 23 2. White-Box Testing.................................................................................................................... 23 3. Black-Box Testing.................................................................................................................... 23 4. OO Testing............................................................................................................................... 24 5. Debugging................................................................................................................................ 24 Study Notes: Software Testing Strategies (lecture 11)........................................... 24 1. Software Testing Strategy........................................................................................ 24 1.1 Strategic Approach.................................................................................................................. 24 1.2 Verification vs. Validation........................................................................................................ 24 1.3 Who Tests the Software?......................................................................................................... 24 1.4 Testing Process....................................................................................................................... 25 2. Unit Testing............................................................................................................. 25 2.1 Definition................................................................................................................................ 25 2.2 Unit Testing Environment......................................................................................................... 25 2.3 Key Focus Areas...................................................................................................................... 25 3. Integration Testing.................................................................................................. 25 3.1 Strategies................................................................................................................................ 25 3.2 Incremental Integration Approaches....................................................................................... 25 3.3 Regression Testing................................................................................................ 26 3.4 Smoke Testing......................................................................................................................... 26 4. System Testing........................................................................................................ 26 4.1 Validation Testing.................................................................................................................... 26  4.2 Alpha and Beta Testing............................................................................................................ 26 4.3 Acceptance Testing................................................................................................................. 26 4.4 High-Order Testing Types......................................................................................................... 27 5. Testing Object-Oriented Applications...................................................................... 27 5.1 Differences in OO Testing........................................................................................................ 27 5.2 OO Testing Strategies.............................................................................................................. 27 6. Testing Web Applications........................................................................................ 27 6.1 Web Testing Quality Dimensions............................................................................................. 27 6.2 WebApp Testing Steps............................................................................................................. 27 7. Testing Mobile Applications (focus on this).............................................................. 27 7.1 Key Mobile Testing Areas......................................................................................................... 27 7.2 Mobile Testing Guidelines........................................................................................................ 28 Key Takeaways........................................................................................................... 28 Final Thoughts............................................................................................................ 28 Study Notes: Software Project Management(lecture 12)....................................... 28 1. Software Project Management (focus on this).......................................................... 29 1.1 What is a Project?................................................................................................................... 29 1.2 What is Project Management?................................................................................................. 29 1.3 Benefits of Project Management.............................................................................................. 29 1.4 Project Management Activities................................................................................................ 29 2. People in a Project.................................................................................................. 29 2.1 Stakeholders........................................................................................................................... 29 2.2 Software Teams....................................................................................................................... 29 2.3 Team Leadership – MOI Model................................................................................................. 30 2.4 Agile Teams............................................................................................................................. 30 2.5 Team Communication............................................................................................................. 30 3. Product, Process, and Project Metrics..................................................................... 30 3.1 Why Measure?......................................................................................................................... 30 3.2 Measures, Metrics, and Indicators........................................................................................... 30 3.3 Types of Metrics...................................................................................................................... 30 3.4 Measurement Process............................................................................................................ 31 4. Project Planning and Estimation.............................................................................. 31 4.1 Why is Planning Important?..................................................................................................... 31 4.2 Key Planning Tasks.................................................................................................................. 31 4.3 Estimation Techniques............................................................................................................ 31 4.4 Estimation Accuracy............................................................................................................... 31 5. Project Scheduling (focus on this)........................................................................... 31 5.1 Why Do Projects Fail?.............................................................................................................. 31 5.2 Scheduling Principles.............................................................................................................. 31 5.3 Effort Allocation...................................................................................................................... 32 5.4 Scheduling Techniques........................................................................................................... 32 5.5 Critical Path Scheduling.......................................................................................................... 32 6. Risk Management in Projects.................................................................................. 32  6.1 Types of Risks.......................................................................................................................... 32 6.2 Risk Handling Strategies.......................................................................................................... 32 Key Takeaways........................................................................................................... 32 Final Thoughts............................................................................................................ 32 Study Notes: Software Maintenance & Control(lecture 13)................................... 33 1. Project Monitoring & Control................................................................................... 33 1.1 Definitions.............................................................................................................................. 33 1.2 What Must Be Controlled & Monitored?................................................................................... 33 1.3 Monitoring Activities................................................................................................................ 33 1.4 Feedback Loop in Monitoring.................................................................................................. 33 1.5 Control vs. Risk....................................................................................................................... 33 2. Software Configuration Management (SCM) (focus on this)...................................... 34 2.1 The First Law of SCM............................................................................................................... 34 2.2 Types of Changes in Software.................................................................................................. 34 2.3 What is Software Configuration Management?........................................................................ 34 2.4 Main Tasks of SCM.................................................................................................................. 34 2.5 Baselines in SCM.................................................................................................................... 34 2.6 SCM Repository...................................................................................................................... 34 2.7 Version Control in SCM........................................................................................................... 34 2.8 Change Control Process.......................................................................................................... 35 2.9 Configuration Auditing............................................................................................................. 35 3. Software Maintenance (focus on this)...................................................................... 35 3.1 What is Software Maintenance?.............................................................................................. 35 3.2 Types of Software Maintenance............................................................................................... 35 3.3 Characteristics of Maintainable Software................................................................................ 35 3.4 Common Software Maintenance Problems............................................................................. 35 4. Software Reverse Engineering & Reengineering......................................................................... 35 4.1 Reverse Engineering................................................................................................................ 35 4.2 Software Reengineering.......................................................................................................... 36 Key Takeaways........................................................................................................... 36 Final Thoughts............................................................................................................ 36 Study Notes: Design Modelling 2 (lecture 7) Focus on UI design principles, component cohesion and coupling, algorithm structuring, and software reuse as key areas for the exam. 1. User Interface Design (focus on this) User Interface (UI) design is a critical aspect of software engineering, ensuring that users can efficiently interact with the system. 1.1 The Design Model A good design model consists of: Data/Class Design Architectural Design Interface Design Component-Level Design 1.2 Characteristics of Good Interface Design A well-designed interface should be: Easy to use Easy to understand Easy to learn 1.3 Common UI Design Errors Some common UI design errors include: Lack of consistency High memorization demand for users No guidance/help available Poor response time Arcane or unfriendly design 1.4 Golden Rules of UI Design 1. Place the user in control: o Avoid forcing users into unnecessary or undesired actions. o Allow flexible and interruptible interactions. o Hide technical internals from casual users. o Streamline interaction as users gain expertise. 2. Reduce the user’s memory load: o Provide intuitive shortcuts. o Use real-world metaphors in the visual layout. o Disclose information progressively. 3. Make the interface consistent: o Maintain consistency across applications. o Avoid unexpected changes unless necessary. 1.5 Interface Analysis Understanding the following elements is essential for UI design: End-users: Who will interact with the system? User tasks: What must users do to complete their work? Content: What information is presented? Environment: Where will users operate the system? 1.6 Interface Design Issues Key UI concerns include: Response time Help facilities Error handling Menu and command labeling Accessibility Internationalization 2. Component-Level Design A component is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes interfaces. 2.1 Views of Components 1. Object-Oriented View (OO View) o A component consists of collaborating classes. 2. Conventional View o A component includes processing logic, internal data structures, and an interface. 2.2 Basic Design Principles 1. Open-Closed Principle (OCP): A module should be open for extension but closed for modification. 2. Liskov Substitution Principle (LSP): Subclasses should be substitutable for base classes. 3. Dependency Inversion Principle (DIP): Depend on abstractions, not concrete implementations. 4. Interface Segregation Principle (ISP): Use many client-specific interfaces rather than one general-purpose interface. 5. Release Reuse Equivalency Principle (REP): The granule of reuse should match the granule of release. 6. Common Closure Principle (CCP): Classes that change together should belong together. 7. Common Reuse Principle (CRP): Classes that aren’t reused together should not be grouped. 2.3 Cohesion in Design Cohesion measures how well a module focuses on a single purpose:  Functional: A module performs one function. Layer: Functions within a specific abstraction layer. Communicational: Functions share common data. Sequential: Output from one process serves as input to another. Procedural: Functions are related and executed in sequence. Temporal: Functions are related in time. Utility: Functions serve similar general utility. 2.4 Design Guidelines Components Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model Interfaces Interfaces provide important information about communication and collaboration (as well as helping us to achieve the OPC) Dependencies and Inheritance it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes). 2.5 Coupling in Design (focus on this) Coupling measures how dependent components are on each other: Content Coupling: One module modifies another. Common Coupling: Modules share global data. Control Coupling: One module controls another's logic. Stamp Coupling: Modules share composite data structures. Data Coupling: Modules share data through parameters. Routine Call Coupling: Dependencies arise from calling other routines. Type Use Coupling: Dependencies exist through type definitions. Inclusion Coupling: Direct import of other modules. External Coupling: Dependency on external systems. 2.6 Steps in Component-Level Design 1. Identify all design classes corresponding to the problem domain. 2. Identify design classes corresponding to the infrastructure domain. 3. Elaborate design classes that are not acquired as reusable components. o Define message details. o Identify appropriate interfaces. o Elaborate attributes, data types, and structures. o Describe processing flow. 4. Describe persistent data sources (databases, files). 5. Develop and refine behavioral representations. 6. Elaborate deployment diagrams. 7. Factor every component-level design representation and consider alternatives. 3. Algorithm Design Algorithm design is the closest activity to coding and ensures that software processes are structured and optimized. 3.1 Steps in Algorithm Design 1. Review component design descriptions. 2. Use stepwise refinement to break the problem into smaller parts. 3. Use structured programming for procedural logic. 4. Use formal methods to prove the logic’s correctness. 3.2 Algorithm Design Models Different models help represent algorithms effectively: Graphical Notation: Flowcharts, box diagrams, activity diagrams. Tabular Notation: Decision tables for logic representation. Program Design Language (PDL): Pseudocode. 3.3 Structured Procedural Design This approach breaks down tasks into smaller steps, often represented using: Activity Diagrams Decision Tables Flowcharts PDL (Pseudocode) 4. Component-Based Development Component-Based Development (CBD) focuses on reusability and modularization. 4.1 Key Questions in Reuse Are commercial off-the-shelf (COTS) components available? Are internally developed reusable components available? Are the available components compatible with the system architecture? 4.2 Challenges in Reuse Many organizations lack a structured reuse plan. Most developers do not use available reusable components. Limited training on software reuse exists. Some teams believe reuse is more trouble than it’s worth. Lack of incentives for creating reusable components. 4.3 Component Qualification Before using a component, assess: APIs: Are they well-documented? Development tools: What is needed for integration?  Runtime requirements: Memory, speed, network usage. Security: Authentication, access controls. Embedded assumptions: Algorithms, non-numerical processing. Exception handling: How are failures managed? 4.4 Component Adaptation For easy integration, ensure: Consistent resource management Common activities like data handling Standardized interfaces within the system architecture 4.5 Component Composition Components must be bound together through: Data Exchange Models Automation Tools Structured Storage Mechanisms Underlying Object Models Study Notes: WebApp and Mobile App Design (lecture 8) 1. WebApp Features (focus on this) 1.1 Overview World Wide Web (WWW): A collection of websites or web pages stored in web servers and accessed via the Internet. Client-Server Interaction: o Client Computers request web pages. o Web Servers respond with HTML data. o Browsers interpret and display web pages. 1.2 Web Applications (WebApps) A WebApp is a software application that runs in a web browser. Dynamically generate HTML files using user inputs and databases. Core components: o Web Browser (Client-side): ▪ The frontend that interact with user. ▪ Manages presentation logic and user input. o Web Server (Server-side): ▪ Handles business logic and processes user requests. ▪ Manages application operations. o Database Server: ▪ Manages data storage and retrieval. 1.3 WebApp Architecture Follows a 3-Tier Architecture: 1. Presentation Layer: User interface (UI). 2. Application Layer: Business logic. 3. Data Layer: Manages and retrieves data. 2. WebApp Design (focus on this) 2.1 When to Focus on Design Complex content and functionality. Large-scale WebApps (hundreds of content objects and functions). Critical to business success. 2.2 Quality Attributes 1. Security: Protect against external attacks and ensure privacy. 2. Availability: Ensure uptime for users. 3. Scalability: Handle user and transaction volume variations. 4. Time-to-Market: Efficient development processes. 2.3 User-Focused Quality Dimensions Time: Highlight changes since the last update. Structural: Ensure all links and elements are functional. Content Accuracy: Maintain high-quality, consistent content. Response Time: Ensure fast server responses. Performance: Manage load variations and ensure smooth operation. 2.4 Design Goals Consistency: Ensure uniform content, design, and navigation. Identity: Align design with business goals. Robustness: Provide relevant and reliable functionality. Navigability: Intuitive and predictable user experience. Visual Appeal: Balance text, graphics, and media effectively. Compatibility: Work seamlessly across environments and configurations. 3. WebApp Design Components Interface Design – Defines how users interact with the WebApp. Aesthetic Design – Ensures visual appeal and consistency. Content Design – Manages how information is structured. Navigation Design – Determines user movement within the WebApp. Architecture Design – Establishes the application structure. Component Design – Deals with backend and functional elements. 3.1 Interface Design Answer user questions like: o "Where am I?" (location indicators). o "What can I do now?" (available options and links). o "Where have I been?" (navigation history and paths). Effective WebApp Interfaces Bruce Tognozzi’s Guidelines for Interface Design 1. Users should feel in control: o The interface should be forgiving (allow undoing actions). o Users should see all available options quickly. 2. The interface should hide complexity: o Users should not be overwhelmed with system details. o Actions should be automated where possible. 3. Efficient Applications = Minimal User Input: o The system should require the least effort from users. o Avoid unnecessary steps in completing tasks. 3.2 Aesthetic Design Avoid clutter and emphasize content. Organize elements from top-left to bottom-right. Optimize layouts for browser and screen resolutions. 3.3 Content Design Key Aspects of Content Design 1. Defines the structure of information in the WebApp. 2. Aligns with data objects in traditional software. 3. Establishes relationships between content elements. Attributes of Content Objects Each content object should contain: Content-specific information (e.g., product details, user-generated content). Implementation details (e.g., metadata, links, database references). A content object can represent: Products (e.g., product name, description, price). Media (e.g., images, videos, specifications). Textual Descriptions (e.g., marketing copy, technical documents). Example of a Content Object Model Content Type Attributes Product Name, Price, Description Photo Dimensions, Format, Border Style Video Resolution, Audio Volume Document Font, Color, Size, Spacing 3.4 Navigation Design Principles of Navigation Design Consider user hierarchy and use cases. Each user type may require different navigation structures. WebApp navigation should be intuitive and predictable. Navigation Semantic Units (NSUs) NSU = a set of information & related navigation structures. NSUs help fulfill specific user requirements. Navigation Syntax Types of Navigation Elements 1. Individual Navigation Links: o Text-based links. o Icons, buttons, switches.  2. Horizontal Navigation Bar: o Contains 4-7 major categories. o Provides quick access to main sections. 3. Vertical Navigation Column: o Lists major content sections. o Displays all key content objects. 4. Tabs: o A variant of navigation bars. o Organizes sections like file folders. 5. Site Maps: o Lists all pages and sections. o Helps users find content quickly. 3.5 Architecture Design Content Architecture: Defines how content is structured for display and navigation. Also known as Information Architecture. Helps with labeling, organization, and searchability. WebApp Architecture: Determines how the application handles: o User interaction o Internal processing o Content presentation Works alongside interface and content design. Content Architecture Models 1. Hierarchical Structure – Organizes content in a tree format. 2. Grid Structure – Arranges content in a uniform grid layout. 3. Linear Structure – Guides users step-by-step through content. 4. Network Structure – Allows free-form navigation between content. 3.7 Component-Level Design Key WebApp Functionalities 1. Content Processing – Dynamically generates content. 2. Data Processing – Handles computations and logic. 3. Database Access – Fetches and updates data. 4. External Integrations – Connects with other systems. Component Responsibilities Each WebApp component must: Handle specific business logic. Ensure efficient data access. Provide dynamic content generation.  Maintain security and stability. 4. Mobile App Features 4.1 Overview Mobile apps are software designed for mobile devices like smartphones and tablets. Characteristics: o Limited functionality due to hardware constraints. o Simplified user interfaces for small screens. 4.2 Types of Mobile Apps 1. Native Apps: o Built for specific platforms (e.g., iOS, Android). o Offer better performance and stricter quality standards. 2. Web Apps: o Run in browsers using HTML5 or CSS. o Require a stable internet connection. 4.3 Mobile App Architecture Similar to WebApp, using a 3-Tier Architecture: 1. Presentation Layer: User Interface (UI) and User Experience (UX). 2. Application Layer: Manages data exchange and operations. 3. Data Layer: Handles data transactions. 5. Mobile App Design 5.1 Key Considerations Multiple Platforms: Support various hardware and software configurations. Short Development Cycles: Rapid iterations. Device Limitations: Manage power, storage, and processing constraints. Integration: Ensure seamless use of external services and APIs. Security: Follow privacy policies and implement secure models. 5.2 UI Design Considerations Define consistent brand elements. Optimize flows and UI elements for performance. Focus on core user stories and tasks. 5.3 Common Design Mistakes Kitchen Sink: Overloading the app with features. Inconsistency: Non-standard UI patterns. Overdesigning: Unnecessary complexity. Slow Performance: Neglecting speed optimization. 5.4 Best Practices Understand the audience and design for their context. Keep the interface intuitive yet functional. Use platform advantages (e.g., gestures, native capabilities). Prioritize clear labels and simple navigation. 6. Development Process Steps in MobileApp Development 1. Formulation: Define the problem and goals. 2. Planning: Map out resources and timelines. 3. Analysis: Gather requirements. 4. Engineering: Develop features and functionalities. 5. Implementation and Testing: Build and test the app. 6. User Evaluation: Collect feedback for improvement. Key Takeaways 1. WebApp Design: o Focus on user experience, robust navigation, and scalability. o Align content and architecture for performance and usability. 2. Mobile App Design: o Consider device constraints and platform-specific features. o Keep interfaces simple and user-friendly. 3. Use a structured approach for both WebApp and MobileApp design to ensure consistency, functionality, and appeal. Study Notes: Software Quality Assurance (lecture 9) 1. Software Quality 1.1 Definition Quality: A characteristic or attribute of something. o Quality of Design: Focuses on requirements, specifications, and system design. o Quality of Conformance: Primarily concerned with implementation. o User Satisfaction: Achieved by delivering a compliant product with good quality within budget and schedule. 1.2 Software Quality Defined as:  o Effective Software Process: Establishes infrastructure and avoids chaos. o Useful Product: Delivers desired functionality reliably and meets both explicit and implicit requirements. o Value Addition: ▪ Reduces maintenance costs for producers. ▪ Expedites processes and increases productivity for users. 2. Dimensions of Software Quality (focus on this) 2.1 David Garvin’s Dimensions 1. Performance Quality: Delivers specified content, functions, and features effectively. 2. Feature Quality: Includes features that delight users. 3. Reliability: Error-free operation, always available when needed. 4. Conformance: Adheres to relevant standards and conventions. 5. Durability: Maintains functionality despite changes or corrections. 6. Serviceability: Allows quick maintenance and debugging. 7. Aesthetics: Offers an elegant, intuitive user experience. 8. Perception: Influenced by user prejudices and expectations. 2.2 McCall’s Software Quality Factors Product Operations: Correctness, reliability, efficiency, integrity, usability. Product Revision: Maintainability, flexibility, testability. Product Transition: Portability, reusability, interoperability. 3. The Software Quality Dilemma Challenges: o Poor quality can lead to rejection by users. o Overemphasis on perfection increases costs and delays. Solution: Strive for a balance—deliver “good enough” software that satisfies user needs but avoids unnecessary perfectionism. 4. Cost of Quality 4.1 Cost Categories 1. Prevention Costs: o Quality planning, technical reviews, test equipment, training. 2. Internal Failure Costs: o Rework, repair, failure mode analysis. 3. External Failure Costs: o Complaint resolution, product returns, warranty work. 4.2 Cost Implications The cost of detecting and fixing errors increases significantly as errors progress from prevention to external failure. 5. Software Quality Assurance (SQA) 5.1 Key Elements 1. Standards: Establish clear guidelines for quality. 2. Reviews and Audits: Ensure compliance with standards. 3. Testing: Verify functionality and identify defects. 4. Error Collection and Analysis: Trace and address root causes. 5. Change Management: Handle modifications effectively. 6. Education: Train staff on quality practices. 7. Vendor and Security Management: Ensure alignment with external systems. 8. Risk Management: Identify and mitigate risks. 5.2 Role of the SQA Group Prepares and monitors the SQA plan. Audits and reviews processes for compliance. Tracks deviations and ensures corrections. Reports findings to management and ensures noncompliance is resolved. 6. Statistical Software Quality Assurance Steps: 1. Collect data on software errors and defects. 2. Categorize errors and identify their causes (e.g., incomplete specs, poor design, communication gaps). 3. Apply the Pareto principle: Focus on the 20% of causes responsible for 80% of defects. 4. Implement fixes for root causes to improve processes. Key Measures: Reliability: Probability of failure-free operation over a specific time. o MTBF: Mean Time Between Failures = MTTF + MTTR. o Availability: Percentage of uptime = [MTTF / (MTTF + MTTR)] × 100%. 7. Software Safety Identifies and mitigates potential hazards to prevent system failures. Design features can eliminate or control risks early in the development process. 8. Software Quality Standards (focus on this) 8.1 Major Standards IEEE: Standards for quality and engineering. ISO (9001:2015): Requirements for effective quality management systems. Capability Maturity Model (CMM): o Focus on improving engineering processes. o Five maturity levels: Initial, Managed, Defined, Quantitatively Managed, Optimizing. CMMI: Successor to CMM; supports Agile development and advanced practices. 9. Six Sigma for Software Engineering Aims for extremely high quality (3.4 defects per million opportunities). Steps: 1. Define customer requirements and project goals. 2. Measure process outputs and collect defect metrics. 3. Analyze root causes of defects. 4. Improve processes to eliminate causes. 5. Control processes to prevent reintroduction of issues. 10. Achieving Software Quality 10.1 Practices 1. Good Project Management: o Include quality techniques in project plans. 2. Quality Control: o Conduct inspections, reviews, and tests. 3. Quality Assurance: o Use audits and reporting to guide proactive decisions. 10.2 Goals Requirements Quality: Ensure correctness and completeness. Design Quality: Verify compliance with requirements. Code Quality: Follow coding standards and ensure maintainability. Control Effectiveness: Optimize resources for high-quality results. Key Takeaways 1. Strive for balanced quality—high enough to meet user expectations but within budget and timeline constraints. 2. Emphasize effective processes, design validation, and root cause analysis to prevent defects. 3. Adhere to established quality standards and frameworks (e.g., ISO, CMMI).  4. Continuously monitor, measure, and improve processes for long-term quality assurance. Study Notes: Software Testing Techniques (lecture 10) 1. Software Testing 1.1 Definition Software Testing is the process of executing a program with the intent of finding errors before delivery to the end user. 1.2 Objectives of Testing Ensure software is error-free. Verify requirements conformance. Evaluate performance. Provide an indication of quality. 1.3 Testability Factors 1. Operability – Software should run smoothly. 2. Observability – Test results should be clear. 3. Controllability – Testing should be automated and optimized. 4. Decomposability – Test cases should be modular. 5. Simplicity – Reduce complexity to simplify testing. 6. Stability – Fewer changes during testing lead to better results. 7. Understandability – The design should be clear. 1.4 Characteristics of a "Good" Test High probability of finding an error. Not redundant. Efficient in detecting maximum errors with minimum effort. Neither too simple nor too complex. 2. White-Box Testing (Structural Testing) White-box testing ensures that all statements and conditions in the code are executed at least once. 2.1 Why is Coverage Important? Logic errors are more likely in paths that are rarely executed. Untested paths may contain errors. Typographical errors may remain unnoticed without full coverage. 2.2 Basis Path Testing A technique that derives independent paths to test. Cyclomatic Complexity (V(G)): o Formula: V(G) = Number of decision points + 1. o The higher V(G), the greater the chance of errors. Steps: 1. Compute cyclomatic complexity. 2. Identify independent paths. 3. Prepare test cases for each path. 2.3 Control Structure Testing Condition Testing: Verifies logical conditions in a program. Data Flow Testing: Selects test paths based on variable definitions and usage. 2.4 Loop Testing Simple Loops: Test cases should include: o Skipping the loop. o One, two, and multiple passes. o Maximum and minimum loop limits. Nested Loops: o Start from the innermost loop. o Vary loop counts systematically. Concatenated Loops: o Test independently if loops are not interdependent. o Otherwise, treat as nested loops. 3. Black-Box Testing (Functional Testing) Black-box testing examines input-output behavior without looking at internal logic. 3.1 Key Aspects Tests functional validity and performance. Identifies incorrect or missing functions. Detects interface errors. Evaluates data structures and external databases. Analyzes behavior and performance errors. 3.2 Black-Box Testing Methods 1. Graph-Based Testing: o Models software objects and their relationships. o Ensures expected relationships exist. 2. Equivalence Partitioning: o Divides inputs into valid and invalid groups. o Reduces test cases while maintaining coverage. 3. Boundary Value Analysis: o Focuses on edge cases (e.g., min/max values). 4. Testing Object-Oriented Applications 4.1 Unique Challenges Testing must be applied at all levels (analysis, design, code). Object-oriented software relies on inheritance and message passing, requiring special test strategies. 4.2 Strategies for OO Testing Semantic Correctness Testing: o Ensure class attributes and relationships reflect real-world requirements. Class Model Consistency: o Review Class-Responsibility-Collaboration (CRC) models. o Verify relationships among objects. 4.3 OO Testing Methods Fault-Based Testing: o Identify plausible faults and design test cases accordingly. Class Hierarchy Testing: o Test all derived classes separately. Scenario-Based Testing: o Focus on how users interact with the system. 4.4 Other Methods Random Testing: o Generate random but valid test cases. Partition Testing: o Categorize operations based on state changes, attributes used, and functions performed. Inter-Class Testing: o Evaluate message passing between objects. 5. Debugging 5.1 Debugging Process 1. Diagnose the error (find the root cause). 2. Fix the issue (correct the error and rerun tests). 3. Perform regression testing to check for side effects. 5.2 Challenges in Debugging Cause & symptom may be far apart. Fixing one bug may create another issue. Compiler or system errors may contribute. Assumptions may be incorrect. 5.3 Debugging Techniques 1. Brute Force – Print/logging statements. 2. Backtracking – Trace backwards from the issue. 3. Induction/Deduction – Use logical reasoning. 5.4 Correcting Errors Ensure similar bugs are not repeated elsewhere. Evaluate potential side effects before applying a fix. Learn from mistakes to prevent future errors. Key Takeaways 1. Software Testing Identifies errors before delivery. Should be systematic and targeted. Balances exhaustive vs. selective testing. 2. White-Box Testing Focuses on internal logic. Uses basis path testing to cover all paths. 3. Black-Box Testing Examines input-output behavior. Uses graph-based testing, equivalence partitioning, and boundary analysis. 4. OO Testing Requires additional class-based and hierarchical testing methods. 5. Debugging Efficient debugging saves time and cost. Use logical reasoning and systematic approaches. Final Thoughts Think before debugging. Use tools to diagnose issues. Seek help when needed. Always perform regression testing after fixing a bug. Study Notes: Software Testing Strategies (lecture 11) 1. Software Testing Strategy 1.1 Strategic Approach Effective testing starts with technical reviews to eliminate errors before formal testing. Testing begins at the component level and progresses outward to system integration. Different testing techniques apply at different phases of development. Testing is done by both developers and independent testers. Testing ≠ Debugging: Testing finds errors, debugging fixes them. 1.2 Verification vs. Validation Verification: "Are we building the product right?" o Ensures that the software correctly implements specific functions. Validation: "Are we building the right product?" o Ensures that the final product meets customer expectations. 1.3 Who Tests the Software? Developers: o Understand the system well but tend to test gently. o Driven by delivery deadlines. Independent Testers: o Aim to break the system and find faults. o Driven by quality assurance. 1.4 Testing Process 1. Unit Testing (smallest components/modules) 2. Integration Testing (connecting components) 3. System Testing (validating overall system behavior) 4. Acceptance Testing (ensuring customer satisfaction) 2. Unit Testing 2.1 Definition Unit Testing tests individual software modules in isolation. It ensures that: o Interfaces work correctly. o Local data structures are maintained. o Boundary conditions are properly handled. o Error handling functions as expected. 2.2 Unit Testing Environment Drivers: Simulate higher-level modules that call the module under test. Stubs: Simulate lower-level modules that the module calls. 2.3 Key Focus Areas Interface Testing: Ensure correct function calls and responses. Boundary Testing: Test limits (e.g., min/max values). Path Testing: Check all independent execution paths. Error Handling: Verify exception handling. 3. Integration Testing 3.1 Strategies 1. Big Bang Approach: o All components are integrated at once. o Risky: Hard to isolate and debug errors. 2. Incremental Integration: o Modules are integrated progressively. o Preferred: Easier debugging and issue isolation. 3.2 Incremental Integration Approaches 1. Top-Down Integration Starts with the top-level module, progressively adding lower modules. Uses stubs for missing modules. Pros: o Identifies major design flaws early. o Ensures critical modules are tested first.  Cons: o Lower modules might not be tested properly early on. 2. Bottom-Up Integration Starts with the lowest-level modules, progressively adding higher modules. Uses drivers for missing modules. Pros: o No need for stubs. o Ensures low-level modules are tested early. Cons: o Higher-level system behavior is tested later. 3. Sandwich Testing Combines Top-Down and Bottom-Up approaches. Test major high-level and low-level components simultaneously. 3.3 Regression Testing Ensures that new changes don’t break existing functionality. Done after: o Bug fixes o Feature additions o Performance improvements Can be manual or automated. 3.4 Smoke Testing A quick set of tests to check if the software build is stable enough for further testing. Common in daily builds of product software. 4. System Testing 4.1 Validation Testing Ensures the system behaves as the customer expects. Checks functional, performance, and behavioral requirements. 4.2 Alpha and Beta Testing Alpha Testing: o Conducted at the developer's site. o Developers observe real users testing the system. Beta Testing: o Conducted at end-user sites. o Users report bugs to developers. 4.3 Acceptance Testing A formal test conducted before customer approval. Usually contractual for software projects. 4.4 High-Order Testing Types Recovery Testing: Tests system failure recovery. Security Testing: Checks vulnerability against attacks. Stress Testing: Pushes the system beyond limits. Performance Testing: Checks efficiency under normal and peak loads. 5. Testing Object-Oriented Applications 5.1 Differences in OO Testing Focus on Classes rather than modules. Encapsulation means testing the state and behavior of objects. Inheritance & Polymorphism require testing all class hierarchies. 5.2 OO Testing Strategies Class Testing: Unit testing equivalent for OO. Thread-Based Testing: Tests all classes needed for one specific event. Use-Based Testing: Tests all classes involved in a single use case. Cluster Testing: Tests groups of interacting classes. 6. Testing Web Applications 6.1 Web Testing Quality Dimensions 1. Content Testing: Check grammar, spelling, correctness, and consistency. 2. Functionality Testing: Verify that web functionalities work as expected. 3. Structural Testing: Ensure the system can be extended and modified. 4. Usability Testing: Evaluate ease of use for different users. 5. Navigation Testing: Check for dead links, incorrect redirects. 6. Performance Testing: Verify responsiveness under load. 7. Security Testing: Identify and mitigate vulnerabilities. 6.2 WebApp Testing Steps 1. Review the content model for errors. 2. Test interface usability and navigation. 3. Verify design correctness. 4. Perform unit tests on components. 5. Conduct compatibility and security testing. 7. Testing Mobile Applications (focus on this) 7.1 Key Mobile Testing Areas User Experience Testing: Ensure intuitive and accessible UI. Device Compatibility Testing: Test on different devices.  Performance Testing: Check responsiveness and efficiency. Connectivity Testing: Ensure app functions well in different network conditions. Security Testing: Prevent vulnerabilities. Testing-in-the-Wild: Test under real-world user conditions. Certification Testing: Meet distribution platform standards (Google Play, App Store). 7.2 Mobile Testing Guidelines Test under real-world network conditions. Use actual devices rather than simulators. Prioritize critical device-platform combinations. Conduct GUI and usability testing for consistency. Check performance under varying network loads. Key Takeaways 1. Software testing is structured: It starts from small components (unit testing) and scales up to system-wide validation. 2. Testing strategies vary: White-box, black-box, regression, and stress testing all serve different needs. 3. Integration testing matters: Use top-down, bottom-up, or sandwich approaches to ensure system coherence. 4. User acceptance is crucial: Beta testing and customer validation ensure software meets real-world needs. 5. OO and Web testing require specialized methods: Classes, navigation flows, and security aspects need specific attention. 6. Mobile testing is challenging: Testing across devices, networks, and real-world conditions is essential. Final Thoughts Plan testing strategies early to reduce errors before system integration. Automate where possible to save time on regression and compatibility tests. Never skip security testing, especially for web and mobile apps. Prioritize usability to ensure a smooth user experience Study Notes: Software Project Management(lecture 12) 1. Software Project Management (focus on this) 1.1 What is a Project? A project is a temporary effort undertaken to create a unique product, service, or result. Key Features of a Project: Unique (one-time program). Specific start and end time (life cycle). Work scope defined into tasks. Budget and resources allocated. 1.2 What is Project Management? Planning, organizing, staffing, directing, and controlling resources to meet objectives within a specified time. Ensures that projects meet performance, cost, and schedule objectives. 1.3 Benefits of Project Management Clearly defined roles and responsibilities. Helps in minimizing reporting efforts. Sets time limits for scheduling. Allows for early identification of issues. Improves future project estimation. 1.4 Project Management Activities Establish project objectives. Define work requirements and timing. Allocate resources and budget. Track progress and compare with plans. Take corrective actions as needed. 2. People in a Project 2.1 Stakeholders Project stakeholders include: 1. Senior Managers – Define business priorities. 2. Project Managers – Plan, motivate, and control execution. 3. Practitioners – Execute the technical tasks. 4. Customers – Define software requirements. 5. End-Users – Interact with the final product. 2.2 Software Teams A software team must focus on: Leadership & motivation. Collaboration & organization. Generating new ideas. 2.3 Team Leadership – MOI Model Motivation – Encourage team members to give their best. Organization – Set clear processes and structures. Ideas/Innovation – Encourage creativity within constraints. 2.4 Agile Teams Self-organizing and adaptive. High autonomy in decision-making. Trust and skill balance among team members. 2.5 Team Communication Types of communication in software projects: 1. Formal Documentation – Reports, memos, schedules, etc. 2. Formal Meetings – Status updates, quality reviews. 3. Informal Meetings – Brainstorming, discussions. 4. Electronic Communication – Emails, video calls. 5. Networking – Discussions with experts. 3. Product, Process, and Project Metrics 3.1 Why Measure? Measurement helps to: Track project status. Identify risks early. Improve quality. Optimize resources. 3.2 Measures, Metrics, and Indicators Measure – A quantitative assessment of a process or product. Metric – A standard unit of measure for evaluating attributes. Indicator – A metric that provides insights into project health. 3.3 Types of Metrics 1. Product Metrics (Assess Software Quality) Defects per KLOC (Thousand Lines of Code). Errors per function point. 2. Process Metrics (Assess Process Effectiveness) Defects found before release. Errors discovered per review. Schedule conformance. 3. Project Metrics (Assess Development Efficiency) Effort per task. Bugs reported per phase. Milestone completion rate. 3.4 Measurement Process 1. Formulation – Define key metrics. 2. Collection – Gather data. 3. Analysis – Compute and interpret results. 4. Feedback – Apply insights for process improvement. 4. Project Planning and Estimation 4.1 Why is Planning Important? Planning ensures that projects are completed on time, within budget, and meet requirements. 4.2 Key Planning Tasks 1. Define Objectives – Clearly outline project goals. 2. Scope Definition – Identify features, data, and constraints. 3. Risk Assessment – Identify and mitigate uncertainties. 4. Resource Allocation – Assign personnel and technology. 5. Cost Estimation – Predict effort, budget, and duration. 4.3 Estimation Techniques Past Project Experience – Use historical data. Task Breakdown – Estimate based on individual tasks. Empirical Models – Use mathematical models. Automated Tools – Software-based estimation. 4.4 Estimation Accuracy Depends on: Understanding of project scope. Historical data quality. Team capabilities. Stability of requirements. 5. Project Scheduling (focus on this) 5.1 Why Do Projects Fail? Unrealistic deadlines. Changing requirements. Underestimating complexity. Miscommunication. Poor risk management. 5.2 Scheduling Principles 1. Compartmentalization – Break tasks into smaller units.  2. Interdependency – Define task relationships. 3. Effort Validation – Ensure resources are available. 4. Define Responsibilities – Assign team members. 5. Define Outcomes – Specify deliverables. 6. Milestone Tracking – Set checkpoints for progress. 5.3 Effort Allocation Estimated time breakdown: 40-50%: Front-end (planning, design). 30-40%: Coding. 15-20%: Testing & installation. 5.4 Scheduling Techniques 1. Gantt Charts – Visual task scheduling. 2. PERT Analysis – Evaluates task completion time. 3. Critical Path Method (CPM) – Identifies the longest sequence of dependent tasks. 5.5 Critical Path Scheduling Determines the shortest project duration. Tasks on the critical path must not be delayed. 6. Risk Management in Projects 6.1 Types of Risks Technical Risks – Unforeseen complexities. Project Risks – Budget/schedule overruns. Business Risks – Market or company shifts. 6.2 Risk Handling Strategies Risk Avoidance – Change project scope. Risk Minimization – Implement backup plans. Risk Contingency – Develop mitigation plans. Key Takeaways 1. Project Management ensures efficient execution of software projects. 2. Effective planning and scheduling prevent delays and cost overruns. 3. Metrics help track quality and progress throughout the project. 4. Risk management is crucial to handling uncertainties. 5. Stakeholder communication plays a key role in project success. Final Thoughts Always define project objectives clearly.  Use metrics to track and improve processes. Ensure realistic deadlines and resource allocation. Manage risks proactively. Good communication ensures a smooth workflow. Study Notes: Software Maintenance & Control(lecture 13) 1. Project Monitoring & Control 1.1 Definitions Monitoring: Collecting, recording, and reporting project information. Controlling: Using monitoring data to align actual performance with planned performance. Evaluation: Judging the quality and effectiveness of project management. 1.2 What Must Be Controlled & Monitored? 1. Performance – Ensuring project goals are met. 2. Quality – Maintaining software reliability. 3. Cost – Keeping expenses within budget. 4. Time – Ensuring tasks are completed on schedule. 1.3 Monitoring Activities 1. Establish performance criteria and data collection methods. 2. Identify relevant information to collect. 3. Collect and analyze data. 4. Prepare progress reports. 5. Update plans, charts, and schedules. 1.4 Feedback Loop in Monitoring 1. Plan – Define objectives and performance standards. 2. Action – Execute tasks based on plans. 3. Results – Measure actual performance. 4. Feedback & Adjustments – Compare results with planned objectives and make necessary adjustments. 1.5 Control vs. Risk High Control = Low Risk but incurs higher costs. Low Control = High Risk, increasing the chance of problems. Balance is key – The project manager must implement adequate control while maintaining manageable risks. 2. Software Configuration Management (SCM) (focus on this) 2.1 The First Law of SCM "No matter where you are in the system life cycle, the system will change, and the desire to change will persist throughout the life cycle." 2.2 Types of Changes in Software Business Requirements – Market shifts, regulatory changes. User Requirements – Feedback, usability improvements. Technical Requirements – Bug fixes, performance enhancements. 2.3 What is Software Configuration Management? SCM is the discipline of systematically controlling changes during software development. Applied throughout the software engineering process. SCM gets more complex towards the end of development. 2.4 Main Tasks of SCM 1. Identification – What are the configuration items (code, data, documents)? 2. Control – How should changes be managed? 3. Status Accounting – Tracking changes and modifications. 4. Auditing – Ensuring the system meets design and quality requirements. 2.5 Baselines in SCM Definition: A milestone in development marked by a formal review. Types of Baselines: o Functional Baseline – Requirements documentation. o Design Baseline – Architectural and design specifications. o Product Baseline – Fully developed and tested software. 2.6 SCM Repository A structured storage system for managing software changes. Key Features: o Versioning – Track different versions of files. o Dependency Tracking – Manage file interdependencies. o Requirements Tracking – Ensure each requirement is implemented. o Audit Trails – Log all changes for traceability. 2.7 Version Control in SCM Manages different versions of files created during software development. Key Components: 1. Project Repository – Stores all configuration objects. 2. Version Management – Maintains historical versions. 3. Make Facility – Automates software assembly. 4. Issue Tracking – Logs and tracks software defects. 2.8 Change Control Process 1. Recognize Need for Change – Identify issue or request. 2. Evaluate Change Request – Assess impact and feasibility. 3. Authorize Change – Change Control Board approves or rejects. 4. Implement Change – Developers make modifications. 5. Review & Audit Change – Verify correctness and update documentation. 6. Include in Next Release – Integrate into the software. 2.9 Configuration Auditing Ensures the system correctly implements baseline requirements. Increases visibility and traceability in the development process. Confirms that approved changes are properly implemented. 3. Software Maintenance (focus on this) 3.1 What is Software Maintenance? Process of modifying a system after deployment. Final phase of the software development life cycle (SDLC). Software Evolution: Keeping software updated and operational. 3.2 Types of Software Maintenance 1. Corrective Maintenance – Fixing reported defects. 2. Adaptive Maintenance – Modifying software for new environments (OS, hardware, APIs). 3. Perfective Maintenance – Enhancing performance, adding new features. 4. Preventive Maintenance – Improving future maintainability. 3.3 Characteristics of Maintainable Software Effective Modularity – Well-structured code. Use of Design Patterns – Improves readability. Coding Standards – Ensures consistency. Quality Assurance Practices – Catches maintenance issues early. 3.4 Common Software Maintenance Problems Lack of Documentation – Hard to understand old code. Multiple Versions – Difficult to track software evolution. Unstructured Code – Makes debugging and modifications challenging. Original Developers Unavailable – New team struggles to make changes. 4. Software Reverse Engineering & Reengineering 4.1 Reverse Engineering Extracting knowledge from an existing system to understand how it works. Used to recover lost documentation or analyze legacy code. Process of Reverse Engineering 1. Extract Code Abstractions – Analyze code structure. 2. Simplify & Refine – Identify key components. 3. Generate High-Level Specifications – Create diagrams and documentation. 4.2 Software Reengineering Improves and restructures existing software. Helps in reducing maintenance costs. Starts with reverse engineering and refines design for better future updates. Reengineering Process 1. Inventory Analysis – Identify parts needing improvement. 2. Document Restructuring – Improve technical documentation. 3. Code Restructuring – Simplify logic, remove redundant code. 4. Data Restructuring – Optimize database and file structures. 5. Forward Engineering – Build a new system from an improved design. Key Takeaways 1. Monitoring & Control ensures software projects stay on track by tracking performance, quality, cost, and time. 2. SCM is essential for managing changes, ensuring software integrity, and maintaining a structured development process. 3. Version Control & Change Management prevent software chaos by tracking all modifications systematically. 4. Software Maintenance is a crucial part of the SDLC, ensuring long-term usability and adaptability. 5. Reverse Engineering is used to analyze legacy software, while Reengineering enhances existing systems for better maintainability. Final Thoughts Effective monitoring ensures project success. SCM tools and processes simplify software evolution. Well-structured code reduces maintenance effort. Reengineering is key for long-term software sustainability.