Overview of Software Engineering

Stakeholders

Stakeholders are the people or organizations interested in the outcome of a software project. The customer commissions the system. The developer builds the system. The users use the system.

Phases/Artifacts/Tools

A system is anything that has interacting components and that interacts with its environment. In some cases the components of a system can be viewed as sub-systems operating in the environment of the parent system's internal network of components. Organisms, organizations, and devices are systems. A computer program is a system.

There are many ways to view a system, but we are primarily interested in two: the behavioral view which describes the interactions between the system and its environment, and the structural view, which describes the system's components and their interactions with each other.

In the case of software systems (i.e., computer programs), we identify behavior with semantics, function, and specification. The environment might include the runtime environment of the host platform, remote servers and devices that the program must interact with, and human users of the system. More broadly, the environment might also include the business environment that the program supports. The business environment can be viewed as a type of system on its own, consisting of concepts, events, roles, entities, rules, and processes. All stakeholders are potentially interested in the behavior of a software system.

Architecture, design, and implementation/syntax are low-, medium-, and high-resolution views of the structure of a software system, respectively. More generally, we can view the structure of a system as a network of components or modules. The components can be functions, interfaces, classes, packages, or sub-systems. A connection between two components indicates that one component uses the services provided by the other component. Developers are the stakeholders primarily interested in the structure of a software system.

Analysis/Specification/CASE

The specification is a document that describes the behavior of the software system to be built. It contains the requirements model and the domain model. The requirements model includes functional requirements (capabilities) and non-functional requirements (constraints).

Functional requirements are often described with UML use case and sequence diagrams. Here's an example of an initial use case diagram for an email client:

Non-functional requirements include:

Usability

Impedence mismatch with existing workflows
UI conventions
online help
documentation

Reliability

mean-time between failures
fault tolerance/robustness
safety

Performance

Response time
Throughput
Availability
Accuracy

Supportability

How easy will it be to add new features? fix bugs?

The application domain is the real-world context or environment of the application. This includes the various systems and users the application interacts with. It also includes important business concepts (roles, events, entities, descriptions), rules, and processes that the application must know about. UML class, object, deployment, sequence, and activity diagrams are used to describe the application domain. For example, here's an initial model of a hospital domain:

Analysis patterns are reusable fragments of application domain models.

Computer Aided Software Engineering (CASE) tools are often used to create UML diagrams during the analysis and design phases.

Design/Architecture/CASE

Following the specification, the system architecture is developed during the design phase. This document describes the structure of the system to be developed. Initially, it describes the major subsystems and their dependencies. Within a subsystem important interfaces, global functions, classes, and sub-subsystems are described as well as the relationships between them. Package, class, and sequence diagrams are used to model the system architecture.

Implementation/Source/IDE & SCCS

The subsystems, functions, classes, and interfaces described in the system architecture are implemented during the implementation phase. The implementation further describes the structure of a system down to the level of individual instructions.

Integrated Development Environments (IDEs) integrate compilers, linkers, editors, and debuggers. Some IDEs can interface with source code control systems (SCCS) that manage different versions of the source code files.

Testing/Tests/Testing Frameworks

There are two types of testing: behavioral and structural. Structural testing often takes the form of a review in which a group of people inspects the source code line by line.

Behavioral testing focuses on system behavior rather than system structure. Each function/method has an associated function test that feeds the function a set of inputs, and then compares the outputs with the expected outputs. The expected outputs are provided by a table called an oracle. The test fails if one or more of the actual outputs differs significantly from the expected output.

Running a class test runs the function tests for each method. The class test fails if any of the method tests fails.

Running a subsystem test runs the class tests for each class in the subsystem. The subsystem test fails if any of the class tests fail.

Running a system test runs each subsystem test. The system test fails if any of the subsystem tests fail.

Testing frameworks are often used to automate the organization and running of tests.

Structural testing reveals many more bugs than functional testing.

Functional testing is good for regression testing.

Maintenance/Releases/CM

During the maintenance phase releases or builds are produced and distributed to the users. Configuration management tools such as make and ant are used to manage the configurations and versions of various releases.

The main types of maintenance include corrective maintenance (fixing bugs), adaptive maintenance (interfacing with or porting to new systems), and perfective maintenance (adding new features).

Studies show that the maintenance phase is the most expensive. Perfective maintenance is the most expensive type of maintenance.

Processes

The Waterfall

In the traditional waterfall method one phase follows another. Returning to a phase after it is complete is not allowed. This prevents feature creep-- the tendency for customers to add new requirements late in the development process.

Iterative-Incremental Development

There are two flaws with the Waterfall model. First, change is inevitable. It's nearly impossible to anticipate all of the system requirements before design and implementation. Second, the riskiest phase, testing, occurs late in the process.

Iterative-Incremental processes such as Model-Driven Development (MDD) and Rational Unified Process (RUP) are organized into short 2 - 3 week development cycles called iterations. During an iteration each artifact is extended. The extension is called an increment.

During early iterations the riskiest requirements can be specified, designed, implemented, and tested. This places risk near the beginning of the process.

There is no need for a maintenance phase because there is no preset limit to the number of iterations that can be performed; new features can be added in new iterations:

Agile Development

Agile methodologies such as Extreme Programming (XP), Test-Driven Development (TDD), and Agile Model-Driven Development (AMDD) are iterative-incremental processes that de-emphasize big up front designs. Instead, design comes late in the process in the form of refactoring (techniques for redesigning existing code).