Software Engineering Lecture Notes

Flashcards on Software Engineering

Software Engineering (SE)

Theories, methods, and tools for professional software development, focusing on cost-effectiveness and covering all aspects of software production.

Maintainability

Ability to evolve with changing customer needs.

Dependability/Security

Reliable, prevents physical/economic damage from failure, resists unauthorized access.

Efficiency

Resource-efficient (memory, processor), smooth, responsive, quick.

Acceptability

Suitable for target users, compatible with other systems.

Software Engineering

Concerns the practicalities of development and delivering useful software.

System Engineering

Encompasses all aspects of computer-based systems (hardware, software, process). SE is a part of this.

Stand-alone Systems

Marketed and sold to any customer (e.g., PC graphics programs).

Custom Software

Commissioned by a specific customer (e.g., embedded control systems, air traffic control).

Generic Products

The Developer owns the specification and makes change decisions.

Customized Products

Customer owns the specification and makes the change decisions.

Heterogeneity

Systems operate across diverse networks, computers, and mobile devices.

Business and Social Changes

Need for rapid adaptation and new software development due to evolving economies and technologies.

Security and Trust

Crucial due to software's pervasive role in life.

Scale

Software developed across a vast range, from small embedded devices to global cloud systems.

Embedded control systems

manage hardware.

Batch processing systems

large data batches.

Systems of systems

composed of multiple software systems.

Software Process Model

An abstract representation of a software development process, showing it from a particular perspective.

Specification

Defining what the system should do.

Design/Implementation

Defining system organization and implementing it.

Validation

Checking if the system meets customer requirements.

Evolution

Changing the system in response to changing needs.

Products

Outcomes of process activities.

Roles

Responsibilities of individuals in the process.

Pre/Post-conditions

Statements true before/after an activity or product creation.

Plan-driven processes

Activities are planned in advance, progress measured against the plan.

Agile processes

Planning is incremental, easier to adapt to changing customer requirements.

Waterfall Model

Linear, sequential. Each phase must be finished before moving on to the next, with no overlap.

Agile Model

Flexible and incremental. Allows for collaboration, feedback, and frequent changes. Develops in short sprints (cycles).

Iterative and Incremental Model

Merges repetition of iterations (revision and refining of components) and incremental development (building of the system). Developed in small parts, increments, and it goes through testing.

Spiral Model

A combination of the waterfall and iterative models is very risk-driven. Developed in spirals, each spiral is a phase. Helps with early risk detection.

V-Model

Works in a V-like structure; development on the left (descending) and testing on the right (ascending). There is testing at every stage, which emphasizes documentation.

Integration and Configuration

Building systems by integrating existing components or application systems.

Terminology

Often referred to as COTS (Commercial Off-The-Shelf) systems

Types of Reusable Software

Stand-alone application systems (COTS) configured for specific environments.

Process Activities

Real software processes are interleaved sequences of technical, collaborative, and managerial activities.

Overall Goal

Specifying, designing, implementing, and testing a software system.

Software Design and Implementation

Converting system specifications into an executable system.

Software Design

Creating a software structure that fulfills the specification.

Implementation

Translating the designed structure into a program.

Architectural Design

Identifying overall system structure, main components, relationships, and distribution.

Database Design

Designing system data structures and their representation in a database.

Interface Design

Defining interfaces between system components.

Component Selection and Design

Searching for and designing reusable components.

Debugging

The process of finding and correcting program faults.

Software Validation

To ensure the system conforms to its specification and meets customer requirements.

System Testing

Executing the system with test cases derived from specifications and real data.

Component Testing

Individual components (functions, objects, or groups) are tested independently.

System Testing

The system is tested as a whole, with a focus on emergent properties.

Customer Testing (Acceptance Testing)

Testing with customer data to verify it meets their needs.

Prototype

An initial system version used to demonstrate concepts and explore design options.

Change Tolerance (Incremental Delivery)

Development and delivery are broken into increments, each delivering a part of the required functionality.

Agile Development Characteristics

Specification, design, implementation are interleaved (done together)

Rapid Software Development

Fast-changing business environments make stable requirements nearly impossible.

Extreme Programming (XP)

An extreme approach to iterative development

Incremental Planning

Requirements are written as story cards, prioritized by costumers, and broken into tasks by developers.

Small Releases

Minimal useful features are built first, followed by frequent releases that add more functionality.

Simple Design

Only design what's immediately needed.

Test-First Development (TDD)

Automated unit tests are written before the code for a feature is implemented. All tests (new and old) are run with every new code addition to immediately catch errors.

Refactoring

Developers constantly improve the code to keep it simple, understandable, and easy to maintain, without waiting for major overhauls. This reduces the need for extensive documentation.

Pair Programming

Two developers work together at one computer, reviewing each other's work and sharing knowledge. This promotes shared code ownership.

Collective Ownership

All team members can change any part of the system, preventing knowledge silos.

Continuous Integration

Completed code is integrated into the main system as soon as a task is done, and all tests must pass.

Sustainable Pace

Avoids excessive overtime to maintain code quality and productivity.

On-Site Customer

A user representative works full-time with the team to provide and clarify requirements.

Scrum

Focus on managing iterative development

Project Closure

Finalizes the project, completes documentation, and reviews lessons learned.

Development team

A self-organizing group (max 7 people) responsible for the software.

Product backlog

A list of all work items, like features and requirements

Product owner

Manages and prioritized the product backlog, ensuring it meets business needs

Scrum

Daily meeting where the team reviews progress and discuss problems

Scrum master

Ensures the Scrum process is followed, guides the team, and protects them from outside distractions. (Not a project manager).

Sprint

A fixed-length development iteration (usually 2-4 weeks).

Velocity

An estimate of how much work a team can complete in a sprint, used for planning and measuring improvement

Scaling Agile Methods

Adapting Agile for larger, longer projects with many teams (possibly spread out) or introducing it across an entire large organization.

Requirements Engineering (RE)

The process of defining customer-required system services and operational/development constraints.

System requirements

Structured document detailing system functions, services, and constraints, defining implementation, and potentially part of a contract.

System Stakeholders

Any person/organization affected by the system with a legitimate interest.

Functional requirements

Describe system services, reactions to inputs, and behavior. Can also state what the system should not do.

Non-functional requirements

Constraints on system services/functions (e.g., timing, development process, standards).

Product requirements

Specify delivered product behavior (speed, reliability).

Organizational requirements

Consequence of policies/procedures (process standards, implementation).

External requirements

Arise from external factors (interoperability, legislative).

Requirements Elicitation

Technical staff work with customers to understand domain, services, constraints. Involves stakeholders.

Stories and Scenarios

Real-life examples of system use. Stakeholders can relate to them.

Requirements Specification

Writing user and system requirements into a requirements document.

Mathematical specifications

Based on math concepts (finite-state machines, sets). Unambiguous but not understood by most customers.

Software Requirements Document (SRD)

Official statement of system requirements. Not a design document. Should include user and system requirements.

Requirements Validation

Demonstrates requirements define what the customer really wants.

Requirements Management

Process of managing changing requirements during RE and development.

Project Risks

Affect schedule or resources

Product Risks

Affect software quality or performance

Business Risks

Affect the company

Motivating People

Help people work best by organizing tasks and the work environment

Milestones

Points in the schedule to check progress.

COCOMO Cost Modeling

Used model for estimating software costs.