Software Engineering Fundamentals: A Comprehensive Guide

Posted on Sep 4, 2024 in Computers

What is Required to Begin Requirements Elicitation?

A problem statement

What Defines a Project?

• Deliverables to a client
• Schedule
• Technical and managerial activities
• Resources consumed

Roles and Responsibilities

A role defines a set of responsibilities (“to-dos”)

Planned Communication

• Problem inspection: Developers gather information from the problem statement, the client, and the user about their needs and the application domain.
• Status meetings: Teams review their progress.
• Peer reviews: Team members identify defects and find solutions in preliminary work products.
• Client and project reviews: The client or project members review the quality of a work product, in particular deliverables.
• Releases: Project participants make available to the client and end-users versions of the system and its documentation.

Unplanned Communication

• Requests for clarification: Participants request specific information from others about the system, the application domain, or the project.
• Requests for change: Participants describe problems encountered in the system or new features that the system should support.
• Issue resolution: A conflict between different stakeholders is identified, solutions explored and negotiated, and a resolution agreed upon.

Activities, Phases, and Tasks

• Activities/phases have tasks.
• Typically end with milestones.

Agile Software Development

A group of software development methods based on iterative and incremental development. It is a “philosophy” that governs how software is developed.

Life Cycle Process and Development Paradigm

• Life Cycle Process: The way software development is understood, organized, monitored, and controlled.
• Development Paradigm: The approach taken to analyzing and designing the system.

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

Task Definition

Smallest unit of work subject to management. Small enough for adequate planning and tracking. Large enough to avoid micromanagement.

Software Project Management Plan (SPMP)

• The controlling document of a software project.
• Defines the activities, work products, milestones, and resources allocated to the project.
• Includes the development environment (project infrastructure) and constraints.
• Defines management procedures and conventions applicable to the project, such as:
  • Status reporting
  • Risk management
  • Contingency management
  • Configuration management
  • Quality assurance

Defining Success and Failure in Software Projects

Success

• On time
• Within budget
• Meets requirements

Failure

• Not meeting one or more of the success criteria

Defining High-Quality Software

• Meets the user’s needs (acceptability)
• Functions correctly (reliability: no bugs, errors, crashes)
• Secure (dependable)
• Maintainable, adaptable
• Efficient

Major Risks in Software Projects

• Complexity
• Change

Four Activities of Software Engineering

• Modeling
• Problem-solving
• Knowledge acquisition
• Rationale-driven

Dealing with Complexity

Modeling is a key tool in dealing with complexity in software development efforts.

Unified Modeling Language (UML)

The de facto standard diagramming notation for capturing object-oriented analysis and design.

Problem-Solving Activities in Software Engineering

• Requirements Elicitation
• Analysis
• System Design
• Object Design
• Implementation
• Testing

The Purpose of Software Engineering

To produce working (high-quality) software

Software Engineering: A Knowledge-Intensive Discipline

• Problem domain knowledge
• User requirements
• Technology
• Management

Non-Monotonic Knowledge Acquisition

• “90% complete” can become “Back to square 1” very quickly.
• Knowledge is perishable—the only constant is change.

Non-Monotonic Knowledge in Software Engineering

In software engineering projects, acquiring knowledge about the system is non-monotonic, or nonlinear. This means that the addition of new information may invalidate all knowledge previously acquired for understanding a system.

Rationale in Software Development

• Rationale is the justification of decisions.
• Explains why a specific design was selected over others.
• Critical for evolution—assumptions change.

Example

Cutting off both ends of the ham before putting it in the oven

Capturing and Accessing Rationale

Capturing and accessing the rationale of a software system is not trivial. Documentation methods include:

• Software Project Management Plan (SPMP)
• Requirements Analysis Document (RAD)
• System Design Document (SDD)
• Test Plan

Critical Aspects of Software Development

• Most critical and time-consuming task: Communication
• Most important information needed for changing the system (and the most complex to change/update): Rationale
• Monitoring and controlling changes of work products: Configuration Management

Requirements Elicitation

• Required to begin: A problem statement
• Major work products:
  • Functional model
  • Non-functional requirements

UML Diagram Types and Their Uses

Analysis vs. Requirements Elicitation

• Analysis: Defines a system in terms understood by developers, typically using more technical specifications or UML.
• Requirements Elicitation: Defines a system in terms understood by the customer, typically using natural language.

Requirements Gathering in Agile/Iterative Development

Early detailed requirements may be neither useful nor reliable, but this does not mean avoiding written requirements, being sloppy, or abandoning analysis before coding.

Work Products of Requirements Elicitation

• FURPS+ / Supplementary spec
• Use Case Model

FURPS+

• F: Functionality
• U: Usability
• R: Reliability
• P: Performance
• S: Sustainability
• +: Constraints

Management Roles in Software Development

• Organizing the structure of a team and assigning various roles to developers for different tasks during different activities.
• Estimating and scheduling the time and cost of a development effort.
• Tracking and reporting the progress of a development effort to stakeholders and developers.
• Ensuring that the rationale for decisions made by developers is recorded and captured for later use.

Outputs of Requirements Elicitation

• Functional Model
• Nonfunctional Requirements

Hierarchical Organizational Structure

Decisions are made at the top of the organization and passed down. Status is generated at the bottom and flows upwards.

PERT Chart

Represents a schedule as an acyclic graph of tasks, good for viewing task dependencies.

Software Project Management Plan (SPMP)

The controlling document for a software project that documents all issues related to client requirements, developer activities, and team organization.

Package Diagram

This type of UML diagram describes the behavior of a system in terms of the execution of a set of operations. They are similar to flowcharts because they can be used to represent control flow and data flow.

UML Diagrams for Representing Internal System Behavior

• State Machine
• Activity Diagram
• Interaction Diagram

Use Case Representation in UML

In a UML use case diagram, an oval represents a function offered or provided by the system that yields a visible result for an actor.

Describing User Interface in Use Cases

• Mock-ups or prototypes are the best way to evaluate and describe user interface design decisions with the customer.
• The use case text should avoid descriptions of the actual interface being used.

Greenfield Engineering Project

Bruegge and Dutoit describe categories of requirements elicitation based on the source of user requirements. A course project is an example of a Greenfield Engineering Project.

System Sequence Diagrams

System sequence diagrams are directly derived or created from a particular use case.

Closed Architectures

In closed architectures, each layer can only access the layer immediately below it.

Partitioning vs. Layering

Partitioning organizes subsystems as peers that mutually provide different services to each other, whereas Layering allows a system to be organized as a hierarchy of subsystems, each providing higher-level services to the subsystem above it by using lower-level services from the subsystems below it.

Software Engineering Project Considerations

• Overall cost of a software system: Primarily determined during the development phase.
• Cost of upgrading/maintaining a system: Best addressed during the design phase.
• Organizational structure: Hierarchical vs. peer-to-peer

Analysis and Design

• Analysis: Doing the right thing.
• Design: Doing the thing right.
• Domain modeling: Decomposes a system into a collection of collaborating objects.

Testing

• Purpose: To demonstrate the presence of errors.
• White-box testing: Tests the internal workings of the code (best for unit tests).
• Black-box testing: Tests the functionality of the code without knowledge of its internal workings (best for functional tests).
• Refactoring: Semantic-preserving changes that improve design/apply patterns.

Layering

• An approach to organizing subsystems.
• Each layer consists of one or more subsystems.
• Subsystems are not allowed to use or know about higher layers.

Partitions

Partitions divide a system or subsystem into several independent (or weakly-coupled) subsystems that provide services within the same package.

Closed Architecture (Opaque or Strict Layering)

• Each layer can only call operations from the layer directly below it.
• Design goal: High maintainability

Open Architecture (Transparent or Relaxed Layering)

• Each layer can call operations from any layers below.
• Design goal: Runtime efficiency

Verification vs. Validation

• Verification: “Are we building the product right?” The software should conform to its specification.
• Validation: “Are we building the right product?” The software should do what the user really requires.

Reliability and Failures

• Reliability: The measure of success with which the observed behavior of a system conforms to some specification of its behavior.
• Failure: Any deviation of the observed behavior from the specified behavior.
• Error: The system is in a state such that further processing by the system will lead to a failure.
• Fault (defect, bug): The mechanical or algorithmic cause of an error.

White-Box Testing

• Designed to test the inner code “pathways.”
• Needs representative test cases.
• Advantage: Makes complete testing practical.
• Disadvantages:
  • Requires a deeper understanding of the code.
  • May still be impractical.

Black-Box Testing

• Don’t get concerned about code “inside the box.”
• Only care about correct output.
• Advantage: Simple.
• Disadvantage: May be impractical.

Software Change is Inevitable

Software change is inevitable due to:

• New requirements emerging during software use.
• Changes in the business environment.
• The need to repair errors.
• The addition of new computers and equipment to the system.
• The need to improve system performance or reliability.