Software Engineering Principles

Software engineering

The discipline devoted to the design, production and maintenance of computer programs that are developed on time and within cost estimates using tools that help to manage the size and complexing of the resulting software product.

Software process

A standard integrated set of software engineering tools and techniques used on a project or by organization.
Software process activities:

• Problem analysis
• Requirements elicitation
• Requirements definition
• High and low-level design
• Implementation of the design
• Testing and verification
• Delivery
• Operation
• Maintenance

Software engineering tools

• Hardware
• Software
• Idea ware

Software specification

A detailed description of the function, inputs, output and special requirements of a software product, it provides the information needed to design and implement the program
Goals of quality software:

• It works
• It can be modified
• It is reusable
• It is completed on time

Program design tools

• Abstraction
• Information hiding
• Stepwise refinement: Top down – Bottom up – Functional decomposition – round- trip gestalt design
• Visual tools: UML – Class -Responsibilities and collaboration cards (CRC).

Design approaches

• Top down design
• Object oriented design (OOP)

Verification of software correctness

• Testing
• Debugging
• Acceptance test
• Regression testing
• Program verification (fulfills its specification)
• Program validation (fulfills its intended purpose)

Errors

• Specification and design errors
• Compile time errors
• Run time errors

Robustness

• The ability of program to recover following an error
• The ability of a program to continue to operate within its environment.

Designing for correctness

• Assertion: logical preposition that can be true or false.
• Preconditions and post conditions.
• Design review activities: Desk checking – walk through – inspection

Exceptions

An unusual generally unpredictable event detectable by software or hardware, that requires special processing, the event may or may not be erroneous

Program Testing

• Unit testing: test a module of function by itself.
• Functional domain: the set of valid input data for a program or function.

Black-box Testing

• Testing a program or function based on the possible input values.
• Treating the code as a black box.
• Testing based on data coverage.

Clear(White) box testing

• Testing a program or function based on covering all the statements, branches or paths of the code.
• Statement coverage: every statement in the program is executed at least one.
• Branch: a code segment that is not always executed (switch)
• Path: a combination of branches that might be traversed when the program or function is executed.
• Path testing: a testing technique whereby the tester tries to execute all possible paths in the program or function.

Metric-based testing

• Testing based on measurable factors.
• Test plan: a document showing the test cases planned for a program or module, their purposes, input, expected outputs and criteria for success.
• Implementing a test plan: Running the program with the test cases listed in the test plan.
• Test driver: a program that setup the testing environment by declaring and assigning initial values to variables, then calls the sub program to be tested.

Integration Testing

• Testing performed to integrate program modules that have already been independently unit tested.
• Stub: a special function that can be used in top-down testing to stand in for a lower-level function.

References Book: C++ Plus Data Structures, Nell Dale