Software Engineering Overview

SOFTWARE ENGINEERING LECTURE NOTES

Course Information

Course Title: Software Engineering
Course Code: R18A0511
Semester: B.Tech III Year - I Sem (R18) 2021-22
Department: Computer Science and Engineering
Institution: Malla Reddy College of Engineering & Technology
Accreditation: Autonomous Institution – UGC, AICTE approved, NBA & NAAC ‘A’ Grade, ISO 9001:2015 Certified

Objectives

The students will be able:

  1. To comprehend the various software process models.
  2. To understand the types of software requirements and the SRS document (Software Requirements Specification).
  3. To know the different software design and architectural styles.
  4. To learn software testing approaches and metrics used in software development.
  5. To know about quality control and risk management.

UNIT I: Introduction to Software Engineering

Overview

Definition: Software Engineering (S/E) is defined as a systematic, disciplined, and quantifiable approach for the development, operation, and maintenance of software. It comprises:

  • Instructions + Data Structures + Documents
  • Engineering is the application of science, tools, and methods to find cost-effective solutions to problems.
Characteristics of Software
  • Developed or engineered, not manufactured in the classical sense.
  • Does not wear out but deteriorates due to change.
  • Custom-built rather than assembled from existing components.
Changing Nature of Software

Categories of Software:

  1. System Software
  2. Application Software
  3. Engineering and Scientific Software
  4. Embedded Software
  5. Product-line Software
  6. Web Applications
  7. Artificial Intelligence Software
Legacy Software
  • Refers to older programs developed decades ago that often have poor quality due to inextensible design, convoluted code, and lack of documentation.
  • Legacy systems must evolve to adapt to new environments, enhance to meet business requirements, and extend to interoperate with modern systems.
Software Myths

Myths about software can be classified into:

  • Management Myths:
      - Standards and procedures are sufficient.
      - New tools guarantee better development.
      - More programmers can resolve delays.
      - Outsourcing means less oversight.
  • Customer Myths:
      - General objectives are enough for development.
      - Software can be easily modified due to its flexibility.
  • Practitioner Myths:
      - The job is complete once the code is written.
      - Quality cannot be assessed until running.
      - Working programs are the only deliverables.
      - Documentation slows down development.
Software Engineering as a Layered Technology
Layered Structure
  1. Quality Focus: Fundamental bedrock for Software Engineering.
  2. Process: Foundation that guides software engineers.
  3. Methods: Technical instructions for constructing software.
  4. Tools: Support for methods through automation.
Process Framework
  • Framework Activities:
      - Communication
      - Planning
      - Modeling
      - Construction
      - Deployment
  • Umbrella Activities:
      - Software project tracking
      - Formal technical reviews
      - Software quality assurance
      - Software configuration management
      - Documentation preparation
      - Risk management
Capability Maturity Model Integration (CMMI)
  • Developed by the Software Engineering Institute (SEI) to assess and rate organizations based on their software process maturity.
  • CMMI Levels:
  1. Level 0: Incomplete
  2. Level 1: Performed
  3. Level 2: Managed
  4. Level 3: Defined
  5. Level 4: Quantitatively Managed
  6. Level 5: Optimized

UNIT II: Software Requirements

Overview of Software Requirements

Definition (IEEE):

  1. A capability needed by a user to solve a problem or achieve an objective.
  2. A condition that must be met or possessed by a system component to satisfy standards or specifications.
  3. A documented representation of the above.
Categories of Software Requirements
  • User Requirements: External view of the required services, often in plain language and diagrams.
  • System Requirements: Detailed description of services and operational conditions.
  • Functional Requirements: Specific behaviors in response to certain inputs.
  • Nonfunctional Requirements: Constraints on the desired services that apply to the system as a whole.
Problems with Natural Language
  1. Clarity Issues: Ambiguity often leads to misunderstandings.
  2. Confusion: Over-flexibility can create challenges in distinguishing between similar requirements.
  3. Amalgamation Issues: Difficult-to-modularize natural language requirements.
Software Requirements Specification (SRS) Document

Purpose:

  • Facilitate communication between customers and developers.
  • Serve as a foundation for design, development, and testing.
  • Directly reference quality and maintenance guidelines.
Requirements Engineering Process
  1. Feasibility Study: Assesses business value and feasibility.
  2. Elicitation/Analysis: Collects and analyzes requirements.
  3. Specification: Converts gathered information into a standardized format.
  4. Validation: Ensures that requirements meet user needs and are implementable.

UNIT III: Design Engineering

Design Process and Quality
  • Design facilitates the translation of requirements into a blueprint for implementation and quality corresponds to both adherence to specifications and the satisfaction of stakeholder needs.
Design Concepts
  1. Abstraction: Hierarchical representation separating observable behavior from implementation.
  2. Architecture: Structure organized by software components and their interrelationships.
  3. Patterns: General reusability in different contexts.
  4. Modularity: Decomposing a system into manageable sections.
  5. Information Hiding: Concealing implementation details from other components.
  6. Functional Independence: Modules should perform a well-defined function with minimal interdependence.
Object-Oriented Design
  • Objects and Classes: Objects are entities with states and behaviors, while classes define the structure and behavior of these objects.
  • Key Stages in Object-Oriented Design: Identify the context, design architecture, identify objects, and develop models.

UNIT IV: Testing Strategies

Overview of Testing
  • Testing is a critical phase aimed at identifying, isolating, and correcting errors.
  • Validation is the confirmation that the software meets customer expectations, while verification ensures correctness against requirements.
Testing Strategies
  1. Unit Testing: Tests individual components for correctness.
  2. Integration Testing: Focuses on correct interfacing among modules.
  3. Validation Testing: Higher-order checks against functional requirements.
  4. System Testing: Validates the complete system as a whole against specifications.
Types of Testing
  1. Black-Box Testing: Focuses on functional specifications without concern for internal workings.
  2. White-Box Testing: Involves internal processing and logic paths.
Debugging Techniques
  1. Brute Force: Unefficiently investigates unknown sources of errors.
  2. Back Tracking: Tracing code backward from symptoms.
  3. Cause Elimination: Formulating hypotheses to identify sources of errors systematically.

UNIT V: Risk Management and Quality Management

Risk Management
  • Risks are uncertain events with potential negative impacts on a project.
  • Reactive vs. Proactive Strategies: Reactive identifies risks as they occur; proactive involves anticipating and mitigating them in advance.
  • Risk Identification: Involves cataloging all possible risks and categorizing them.
Quality Management
  • Quality Assurance (QA): Involves planned activities that ensure software delivery adheres to certain standards.
  • Quality Control: Inspections, reviews, and tests that validate product quality against specifications.
  • Statistical Software Quality Assurance: Methods to track defects and iterate for improvement.
  • ISO 9000: Guidelines that help ensure quality in product manufacturing and services.