Software Development: From Requirements to Deployment

Posted on Dec 8, 2024 in Computers

Requirements Engineering Process: Key Steps

Requirements Elicitation

  • Purpose: To gather requirements from stakeholders.
  • Activities:
    • Conduct interviews, surveys, and workshops.
    • Observe existing systems or workflows.
    • Develop use cases and scenarios to understand functional requirements.
  • Importance: Ensures all user and system requirements are identified early.
  • Challenges:
    • Ambiguity: Requirements like “user-friendly” are unclear.
    • Conflicts: Stakeholders may have differing priorities.
  • Resolution: Use structured elicitation techniques like prototyping and brainstorming sessions.

Requirements Analysis

  • Purpose: Refine, categorize, and prioritize elicited requirements.
  • Activities:
    • Check for inconsistencies, redundancies, and feasibility.
    • Classify requirements as functional, non-functional, and domain-specific.
  • Importance: Prepares requirements for effective design and implementation.
  • Challenges: Miscommunication between stakeholders and technical teams.

Requirements Specification

  • Purpose: Document requirements in a structured manner.
  • Activities:
    • Write Software Requirements Specification (SRS).
    • Use models (e.g., UML diagrams) to provide clarity.
  • Importance: Acts as a reference for the development and testing teams.

Requirements Validation

  • Purpose: Verify that the documented requirements meet user needs.
  • Activities:
    • Use prototyping and user feedback.
    • Perform peer reviews and walkthroughs.
  • Importance: Reduces costly fixes in later stages.

Requirements Management

  • Purpose: Track and adapt requirements as they evolve.
  • Activities:
    • Maintain traceability between requirements and system components.
    • Use version control to monitor changes.
  • Importance: Ensures the system aligns with changing business needs.

Prioritization Techniques

  • MoSCoW Method: Classifies requirements into Must-Have, Should-Have, Could-Have, and Won’t-Have.
  • Example: A banking app must have secure login (Must-Have), while account avatars are optional (Could-Have).
  • Value vs. Effort Matrix: Focuses on high-value, low-effort tasks to maximize ROI.

Validation Techniques

  • Prototyping: Visual models to confirm requirements.
  • Requirement Reviews: Stakeholders review documented requirements to ensure alignment with goals.

Behavioral and Structural UML Diagrams

Behavioral Diagrams

Use Case Diagram

  • Purpose: Captures system functionalities and interactions with external actors.
  • Elements:
    • Actors: Represent users or external systems (stick figures).
    • Use Cases: Represent functionalities (ovals).
    • Relationships: Lines/arrows (e.g., “include” and “extend”).
  • Example: A library management system showing “Borrow Book” and “Return Book” use cases.

Sequence Diagram

  • Purpose: Models the flow of messages between objects over time.
  • Elements:
    • Lifelines: Represent objects (vertical dashed lines).
    • Messages: Represent interactions (arrows).
    • Activation Bars: Show the execution of operations (rectangles).
  • Example: A checkout process showing interactions between user, inventory, and payment gateway.

Structural Diagrams

Class Diagram

  • Purpose: Captures the static structure of the system.
  • Elements:
    • Classes: Represented as rectangles with three sections (name, attributes, methods).
    • Relationships: Associations (lines), inheritance (arrows), and composition (filled diamonds).
  • Example: A library system with Book, User, and Loan classes.

Component Diagram

  • Purpose: Represents the physical architecture of the system.
  • Elements:
    • Components: Represent system modules (rectangles with tabs).
    • Interfaces: Represent provided and required functionalities (circles and lollipop symbols).
    • Dependencies: Represent relationships between components (dashed arrows).
  • Example: An e-commerce system showing Payment, Inventory, and Order Processing components.

SDLC Models: Agile vs. Waterfall

Agile

  • Principles: Iterative development with regular user feedback. Emphasis on collaboration and adaptability.
  • Advantages:
    • Handles changing requirements effectively.
    • Delivers incremental updates.
    • Encourages team collaboration and customer involvement.
  • Limitations:
    • Scope creep due to frequent changes.
    • Requires highly skilled, self-organized teams.
  • Use Case: Ideal for dynamic environments like mobile app development.

Waterfall

  • Principles: Sequential development phases. Emphasis on documentation and clear deliverables.
  • Advantages:
    • Structured approach with predictable outcomes.
    • Well-suited for projects with stable requirements.
  • Limitations:
    • Late discovery of issues in testing phases.
    • Inflexible to changes once development begins.
  • Use Case: Best for regulated industries like healthcare.

Comparison: Agile is preferred for projects with evolving requirements, while Waterfall is better for projects needing strict adherence to fixed requirements.

Software Design Challenges and Practices

Key Practices

  • Model Transformation: Simplifies design models.
  • Example: Extracting common attributes into a superclass in a class diagram.
  • Forward Engineering: Converts UML diagrams into source code.
  • Example: Translating sequence diagrams into method implementations.
  • Reverse Engineering: Reconstructs design models from existing code.
  • Example: Extracting a class diagram from legacy system code.
  • Refactoring: Improves code structure without altering behavior.
  • Example: Splitting a long method into smaller, cohesive methods.

Testing in Software Engineering

Testing Strategies

  • Unit Testing: Tests individual components in isolation.
  • Example: Testing the calculateTotal() method in a shopping cart.
  • Integration Testing: Validates interactions between modules.
  • Example: Testing the interaction between Payment and Order Processing modules.
  • System Testing: Ensures the entire system meets requirements.

Black-Box vs. White-Box Testing

  • Black-Box Testing: Focuses on inputs and outputs without considering internal logic.
  • White-Box Testing: Analyzes code structure, logic, and paths.

Regression Testing

  • Ensures changes don’t break existing functionality.
  • Example: Automating test scripts with Selenium after adding a new feature.

Coupling and Cohesion in System Design

Coupling

  • Definition: The degree of dependency between modules.
  • Low Coupling: Modules interact through well-defined interfaces, minimizing dependencies.
  • Example: A Billing module accessing Inventory through APIs rather than direct data calls.
  • Importance:
    • Reduces interdependencies, making modules easier to modify or replace.
    • Enhances code maintainability and reusability.

Cohesion

  • Definition: The degree to which elements within a module focus on a single task.
  • High Cohesion: A module performs one well-defined function.
  • Example: A ReportGenerator module handling only report generation.
  • Importance:
    • Improves code clarity, modularity, and testability.
    • Reduces complexity within modules.

Key Principle: Low Coupling + High Cohesion: Results in a modular, maintainable, and scalable system.

Architectural Styles

Client-Server Architecture

  • Definition: Centralized servers provide services to multiple clients.
  • Advantages:
    • Centralized control simplifies data management and security.
    • Scalable by adding more servers or clients.
  • Limitations:
    • Single point of failure if the server goes down.
    • Dependency on reliable network connectivity.
  • Example: Email systems or database applications.

MVC Architecture

  • Definition: Separates application logic into three layers:
    • Model: Manages data and logic.
    • View: Handles the user interface.
    • Controller: Processes input and updates the model/view.
  • Advantages:
    • Clear separation of concerns enhances modularity and testability.
    • UI flexibility allows for easier updates.
  • Limitations: Increased complexity due to component interactions.
  • Example: E-commerce web applications.

Comparison: Client-server focuses on network communication, while MVC is about structuring application logic.

Version Control and Release Management

Version Control

  • Purpose: Tracks changes to code and enables collaboration.
  • Types:
    • Centralized: Single repository (e.g., Subversion).
    • Distributed: Each developer has a complete copy of the repository (e.g., Git).
  • Advantages of Git:
    • Branching and merging for parallel development.
    • Enables offline work and distributed collaboration.

Release Management

  • Purpose: Ensures smooth transitions from development to deployment.
  • Activities:
    • Manage versions and dependencies.
    • Automate builds and deployments using CI/CD pipelines.
  • Example: Jenkins automates testing and deployment after code changes.

Software Maintenance and Evolution

Types of Maintenance

  • Corrective Maintenance: Fixes defects or bugs.
  • Example: Addressing a login failure in a banking app.
  • Adaptive Maintenance: Updates software to accommodate changes in the environment.
  • Example: Adapting a system to a new operating system.
  • Perfective Maintenance: Enhances performance or functionality.
  • Example: Improving load times in a web application.

Reengineering

  • Purpose: Improves the maintainability of legacy systems.
  • Example: Refactoring monolithic code into microservices.

Software Entropy

  • Definition: Systems degrade over time due to unmanaged changes.
  • Strategies to Manage:
    • Regular code refactoring.
    • Using modular and well-documented designs.

Cloud Computing in Software Development

Models

  • IaaS (Infrastructure as a Service): Provides virtualized infrastructure (e.g., AWS EC2).
  • Use Case: Hosting a scalable web application.
  • PaaS (Platform as a Service): Provides development platforms (e.g., Heroku).
  • Use Case: Rapid app development without managing servers.
  • SaaS (Software as a Service): Provides ready-to-use applications (e.g., Salesforce).
  • Use Case: CRM systems or email services.

Advantages: Scalability, reduced costs, and faster deployment.

Challenges: Security risks and potential vendor lock-in.

UI/UX Design Principles

The Five-Plane Design Process

  • Strategy Plane: Defines user needs and project goals.
  • Example: Identifying target users for an e-commerce app.
  • Scope Plane: Determines features and functionality.
  • Example: Shopping cart and payment gateway.
  • Structure Plane: Organizes content and interactions.
  • Example: Defining navigation paths in a website.
  • Skeleton Plane: Creates wireframes to outline layouts.
  • Example: Designing a homepage layout with clickable elements.
  • Surface Plane: Finalizes visual design and aesthetics.
  • Example: Choosing fonts, colors, and icons for a mobile app.

Importance: Enhances usability and user satisfaction.

Open-Source Development and Collaboration

Benefits:

  • Faster innovation due to collaborative contributions.
  • Cost-effective as software is free or low-cost.
  • Large community support ensures faster problem resolution.

Challenges:

  • Security vulnerabilities from open access.
  • Lack of guaranteed support for critical issues.

Tools for Collaboration

  • GitHub: Facilitates version control and team collaboration. Enables code reviews and issue tracking.
  • Example: Linux is a widely used open-source operating system developed collaboratively.