Software Engineering

Front 1

Generic Products

Back 1

Stand alone systems that are produced by a development organization and sold on the open market. Examples: PC's, word processors, drawing packages, and project-management tools.

Front 2

Customized Products

Back 2

Systems that are commissioned by a particular customer. A software contractor develops the software especially for that customer. Examples: Control systems for electronic devices, systems written to support a particular business process, and air traffic control systems.

Front 3

Engineering Discipline

Back 3

Engineers make things work by applying theories, methods, and tools where they are appropriate. They also try to find solutions when there is no applicable theory or method.

Front 4

Aspects of software production

Back 4

Technical processes and activities such as project management and the development of tools, methods, and theories to support software production.

Front 5

General Issues with different types of Software

Back 5

Heterogeneity, Business/Social Change, and Security/Trust

Front 6

Heterogeneity

Back 6

Integrating new software with older legacy systems written in different programming languages. Challenge is to develop techniques for building dependable software that is flexible enough to cope with this heterogeneity.

Front 7

Business and Social Change

Back 7

Business and society are changing incredibly quickly as emerging economies develop and new technologies become available.

Front 8

Security and Trust

Back 8

As software is intertwined with all aspects of our lives, it is essential that we can trust that software. We have to make sure that malicious users cannot attack our software and that information security is maintained.

Front 9

Software Engineering Diversity

Back 9

Deciding which software engineering methods and techniques to use depending on the application being developed.

Front 10

Stand-alone Applications

Back 10

These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network. Examples: Office applications on a PC, photo manipulation software, word processor, etc.

Front 11

Interactive transaction-based Applications

Back 11

Applications that execute on a remote computer and that are accessed by users from their own PCs or terminals. Examples: e-commerce applications where users use a remote system to buy and sell goods and services, cloud based services, etc.

Front 12

Embedded Control Systems

Back 12

Software control systems that control and manage hardware devices. Examples: software in a mobile cellphone, software in a microwave to control cooking process, software that controls anti-locking brakes in a car.

Front 13

Batch processing systems

Back 13

Business systems designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Examples: periodic billing systems, such as phone billing systems and salary payment systems.

Front 14

Entertainment systems

Back 14

Systems that are primarily for personal use and which are intended to entertain the user. Examples: games for N64 or Gamecube

Front 15

Systems for modeling and simulation

Back 15

Systems designed by scientists and engineers to model physical processes or situations.

Front 16

Data collection systems

Back 16

Systems that collect data from their environment using a set of sensors and send that data to other systems for processing.

Front 17

System of Systems

Back 17

Systems that are composed of a number of other software systems. Could be a generic product, such as a spreadsheet program.

Front 18

Software Engineering Ethics

Back 18

Confidentiality, Competence, Intellectual property rights, and Computer misuse.

Front 19

Confidentiality

Back 19

You should normally respect the confidentiality of your employer or clients regardless if you have not signed a formal confidentiality agreement.

Front 20

Competence

Back 20

The ability to do something successfully.

You should not misrepresent your level of competence. You should not knowingly accept work outside of your competence.

Front 21

Intellectual property rights

Back 21

You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be careful to ensure that the intellectual property of employers and clients is protected.

Front 22

Computer misuse

Back 22

You should not use your technical skills to misuse other people's computers. Computer misuses range from relatively trivial (game playing on an employers computer) to extremely serious (dissemination of viruses or other malware).

Front 23

Software specification

Back 23

The functionality of the software and its constraints on its operations must be defined.

Front 24

Software design and implementation

Back 24

The software to meet the specification must be produced.

Front 25

Software validation

Back 25

The software must be validated to ensure that it does what the customer wants.

Front 26

Software evolution

Back 26

The software must evolve to meet changing customer needs.

Front 27

Waterfall Model

Back 27

Incremental stages of Requirements Definition, System & Software Design, Implementation & Unit Testing, Integration & System Testing, and Operation & Maintenance. If you need to go back, you start back from the beginning.

Front 28

Waterfall Model Diagram

Back 28

Front 29

Incremental Development

Back 29

This system develops as a series of increments, with each version adding functionality to the previous version.

Front 30

Incremental Development Diagram

Back 30

Front 31

Reuse-oriented software engineering

Back 31

System is based on the existence of a significant number of re-usable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.

Front 32

4 main activities in the requirements engineering process

Back 32

Feasibility Study, Requirements elicitation & Analysis, Requirements Specification, and Requirements Validation.

Front 33

Feasibility Study

Back 33

An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies. The study considers whether the proposed system will be cost-effective from a business point of view and if it can be developed within the budget.

Front 34

Requirements elicitation and analysis

Back 34

This is the process of deriving the systems requirements through observation of existing systems, discussions with potential users, task analysis, and so on.

Front 35

Requirements Specification

Back 35

The activity of translating the information the information gathered during the analysis into a document that defines a set of requirements. Two types of requirements, User & System.

Front 36

Requirements validation

Back 36

This activity checks the requirements for for realism, consistency, and completeness. Errors will be discovered and corrected.

Front 37

Architectural Design

Back 37

You identify the overall structure of the system, the principal components their relationships, and how they are distributed.

Front 38

Interface Design

Back 38

You define the interfaces between system components. This specification has to be unambiguous so that a component can be used without other components having to know how it is implemented.

Front 39

Component Design

Back 39

You take each system component and design how it will operate.

Front 40

Database Design

Back 40

You design the system of data structures and how these are to be represented in a database. Work here is based on whether an existing database is to be reused or a new database is to be created.

Front 41

Stages in the Testing Process

Back 41

Developmental Testing, System Testing, and Acceptance Testing.

Front 42

Developmental Testing

Back 42

The components making up the system are tested by the people developing the system. Each component is tested independently.

Front 43

System Testing

Back 43

System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems.

Front 44

Acceptance Testing

Back 44

Final stage in testing process before the system is accepted for operational use. The system is tested with data supplied by the system customer rather than with simulated data.

Front 45

Boehm's Spiral Model

Back 45

Front 46

4 Sectors of Boehm's Spiral Model

Back 46

Objective setting, Risk assessment & reduction, Developmental & validation, and Planning.

Front 47

Objective Setting

Back 47

Specific objectives for that phase of the project are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up.

Front 48

Risk assessment and reduction

Back 48

For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk.

Front 49

Developmental and validation

Back 49

After risk evaluation, a developmental model for the system is chosen.

Front 50

Planning

Back 50

The project is reviewed and a decision is made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project.