final

Functional viewpoint

describes what the system does in terms of its tasks

Object-oriented testing complete coverage

Complete test coverage of a class involves Testing all operations associated with an object Setting and interrogating all object attributes Exercising the object in all possible states

user typing test

Alpha testing Users of the software work with the development team to test the software at the developer's site. Beta testing A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers. Acceptance testing Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.

Architectural pattern

An architectural pattern (AP) represents a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. APs are templates for concrete software architectures Selection of APs is the fundamental design decision of software system development Example: model-view-controller

Process change stages

Improvement identification. Improvement prioritization. Process change introduction. Process change training. Change tuning.

process improvement

Process improvement is a cyclical activity Process measurement Measure the attributes of current projects and products Process analysis Assessment and identify any weakness and bottleneck Process change Propose changes to current processes

Sequence Diagrams

Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows.

SW inspections

Software inspections Concerned with analysis of the static system representation to discover problems (static verification) May be supplement by tool-based document and code analysis Involve people examining the source representation with the aim of discovering anomalies and defects Do not require execution of a system so may be used before implementation May be applied to any representation of the system (requirements, design, test data, etc.) Inspections can check conformance with a specification but not conformance with the customer's real requirements - hard problem! Inspections cannot check non-functional characteristics such as performance, usability, etc. As well as searching for program defects, an inspection can also consider broader quality attributes of a program, such as compliance with standards, portability and maintainability. Very effective technique for discovering errors

Inspections and testing

Software inspections Concerned with analysis of the static system representation to discover problems (static verification) May be supplement by tool-based document and code analysis. Software testing Concerned with exercising and observing product behaviour (dynamic verification) The system is executed with test data and its operational behaviour is observed.

Models may be included in Architectural models

Static structural model: sub-systems or components that are to be developed as separate unit Dynamic process model: processes at run-time Interface model: services through public interfaces Relationship model: data/control flow Distribution model: how to distribute sub-systems ADLs (architectural description languages) can be used to describe system architectures

Validation and defect testing

The first goal leads to validation testing You expect the system to perform correctly using a given set of test cases that reflect the system's expected use. A successful test shows that the system operates as intended. The second goal leads to defect testing The test cases are designed to expose defects. The test cases in defect testing can be deliberately obscure and need not reflect how the system is normally used - the other half.

path testing

The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control Statements with conditions are therefore nodes in the flow graph

Computation independent model (CIM) Platform independent model (PIM) Platform specific modes (PSM)

These model the important domain abstractions used in a system. CIMs are sometimes called domain models. These model the operation of the system without reference to its implementation. The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events. These are transformations of the platform-independent model with a separate PSM for each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

process measurement

Wherever possible, quantitative process data should be collected However, where organisations do not have clearly defined process standards this is very difficult as you don't know what to measure. A process may have to be defined before any measurement is possible. Process measurements should be used to assess process improvements But this does not mean that measurements should drive the improvements. The improvement driver should be the organizational objectives. Time taken for process activities to be completed E.g. Calendar time or effort to complete an activity or process. Resources required for processes or activities E.g. Total effort in person-days. Number of occurrences of a particular event E.g. Number of defects discovered. measure analyze change measure these things Understandability Visibility Supportability Acceptability Reliability Robustness Maintainability Rapidity

Design Pattern

A design pattern (DP) provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context. DPs are smaller in scale than APs but independent of a particular programming language or programming paradigm. Selection of DPs may not have effect on fundamental structure of a software system but has influence of the architecture of a subsystem Example: publisher-subscriber The components should be loosely coupled The components that depend on the information provider are not known a priori

Function oriented metrics: FP

A function point is a unit of measurement to express the amount of business functionality an information system provides to a user -> Measurement of functionality cannot be computed directly derived indirectly using other direct measurements Function points are derived using empirical relationships on some measurable software information

Design Priniciples

A representation or model of to-be software. A set of documents to serve as the base on which an application can be fully programmed. Enables programmers to implement the requirements by designating the projected parts of the implementation. Two parts: high-level design - software architecture detailed design

Pattern Purpose

Abstracting from specific problem-solution pairs and distilling out common factors leads to patterns Each pattern is a three-part rule, which expresses a relation between: a certain context a problem a solution A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate. Patterns support the construction of software with defined properties Patterns help you build complex and heterogeneous software architectures Patterns help you to manage software complexity A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it. Patterns document existing, well-proven design experience Patterns identify and specify abstractions that are above the level of single classes and instances, or of components Patterns provide a common vocabulary and understanding for design principles Patterns are a means of documenting software architectures Context: a situation giving rise to a problem Problem: the recurring problem arising in that context Solution: a proven resolution of the problem

Idioms

An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. In idiom addresses aspects of both design and implementation.

Types of Patterns

Architectural patterns Design patterns Idioms

Architectural design decisions

Architectural template Distributive characteristics Architectural style Approach to structure the system How to decompose structural units How to control the operations in the units Evaluation of the architectural design How to document

v & V

Assuring that a software system meets a user's needs What is V&V? 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 V & V must be applied at each stage in the software process. Objectives The discovery of defects in a system The assessment of whether or not the system is usable in an operational situation.

Configuration databases

CD should be able to answer the following questions: Which customer took which version of a system What hardware and operating system configuration is required to run a given system version. How many versions of a system have been created and what were their creation dates? What versions of a system might be affected if a particular component is changed How many change requests are outstanding on a particular version How many reported faults exist in a particular version.

Change management

Change management should involve technical change analysis, cost-benefit analysis and change tracking. Typically a change control board or change committee do the following: Determines validity of a change : analyze impact of the change from strategic and organizational point of view Detect conflicting/overlapping changes Estimate cost Schedule changes relative to software releases Tracks the change process making sure that the change is applied Access and synchronization control Access control ensures the SW engineer is authorized to check out Sync. control locks the object at check-out and unlocks at check-in

Program Design Language

Clarify algorithms in many cases Impose increased discipline on the process of documenting detailed design Provide additional level at which inspection can be performed Help to trap defects before they become code Increases product reliability May decreases overall costs

Goal and purpose MDA

Completely automated transformation of models to code Separation of concerns Easy of reuse, lower the cost of software development Enable Models to be intellectual property since they provide solutions to the given problems

Implemenatation view Enviroment view behavioral structure

Component diagram Deployment diagram sequence diagram, collaboration, statechart, activity class, object

Measuring Quality SW

Correctness: defects per KLOC Maintainability: MTTC (mean-time-to-change) Integrity: the system's ability to withstand attacks to its security. For this measurement, threat and security need to be defined: Threat: probability that an attack of certain type will happen over a period of time Security: probability that an attack of certain type will be removed over a period of time Integrity = [(1-threat) X (1-security)] Usability: Required physical and/or intellectual skill The time required to become moderately efficient in the system The net increase in productivity The assessment of users attitudes toward the system

Black-Box Testing

Data-driven testing -- input/output testing Testers view the program as a black box Do not concerned about internal structure or behavior Test data derived solely from specifications Find all errors Exhaustive input testing: use every possible input condition Test planning can begin early in the software process

Software Configuration Management

Definition: A SW configuration collectively refers to all info. produced as part of the software engineering process Goal: to minimize mistakes while maximizing productivity during software development cycle Assumption: change is inevitable ( a fact of life in software development) Why change? Customers want to change requirements, Developers -> technical approach, Managers -> project approach, Reorganization/downsizing, Budgetary and/or scheduling constraints

Cyclomatic Complexity

Developed by Thomas McCabe Represents the number of independent paths V(G) = E - N + 2 // G: flow graph, E: edges, N:nodes, V(G) = number of binary decision + 1 Cyclomatic complexity of 1 through 10 may be viewed as low risk and simple, greater than 50 considered untestable. Code development risk analysis Change risk analysis in maintenance Test planning Reengineering Deriving Test Cases Using the design, draw a corresponding flow graph Determine the cyclomatic complexity of the resultant flow graph Determine a basis set of linearly independent paths Prepare test cases that will force execution of each path in the basis set.

Lines of Code

Fully designed, implemented, debugged and documented source code Why controversial? Program language dependent (e.g. non procedural languages? - LISP, PROLOG) Quality dependent (e.g. well designed but shorter programs?) Metrics: errors per KLOC (before release) defects per KLOC (after release) $ per LOC pages of documentation per KLOC errors per person-month

White Box testing

Logic-driven testing Testers examines internal structure of program Test data derived from the program's logic Find all errors Exhaustive path testing: execute every possible path of control flow of program. Number of unique logic paths total number of unique ways of moving from some program point A to B Derivation of test cases according to program structure. Knowledge of the program is used to identify additional test cases Statement coverage criterion Every statement in the program should be executed at least once Decision/condition coverage criterion Write enough test cases such that each decision has a true and false outcome at least once Each branch direction must be traversed at least once Multiple condition coverage Write enough test cases such that each condition in a decision takes on all possible outcomes at least once, and each statement is executed at least once.

Model driven architecture (MDA)

Model-driven architecture (MDA) was the precursor of more general model-driven engineering MDA is a model-focused approach to software design and implementation that uses a subset of UML models to describe a system. Models at different levels of abstraction are created. From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention.

Component level / Intra-module design

Occurs after the first iteration of architectural design the overall data and program structure of the software are established at this stage Component can be defined as "a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces" [OMG] Specify classes and functions completely Specify algorithms use flowcharts use program design language (structured English or Pseudocode)

Partitioning testing

Partitioning testing Input data and output results often fall into different classes where all members of a class are related. Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. Test cases should be chosen from each partition. Equivalence Partitioning Goal: minimize total number of test cases while covering maximum number of errors => partition the input domain into a finite number of equivalent classes: a test of a representative value of each class is equivalent to a test of any other value => equivalent partitioning Steps: Identify the equivalence classes Define the test cases Identify the equivalence classes Use heuristic process to identify each input condition and partition it Two types of equivalence classes: valid equivalence classes: represent valid input to the program invalid equivalence classes: represent all other inputs Example: valid input condition : 1 < item count < 999, Invalid input condition : item count < 1 and item count > 999 Valid/Invalid : must be a letter/not a letter

Software Testing

Software testing Concerned with exercising and observing product behaviour (dynamic verification) The system is executed with test data and its operational behaviour is observed Can reveal the presence of errors NOT their absence A successful test is a test which discovers one or more errors The only validation technique for non-functional requirements Should be used in conjunction with static verification to provide full V&V coverage Definition: Testing is the process of analyzing a system or system component to detect the differences between specified (required) and observed(existing) behavior. Assumption: It is impossible to completely test a nontrivial system (due to time and resource constraints.) It is always end uses who test it thoroughly. Types : 1. Black-box testing 2. White-box testing

Tabular design

Specify classes and functions completely Specify algorithms use flowcharts use program design language (structured English or Pseudocode)

Design goals

Sufficiency: satisfying the requirements Flexibility: handles changes in requirements Understandability: can be understood by intended audience Modularity: divided into well-defined parts Cohesion Coupling Reusability Information hiding Efficiency reliability

System Patterns

Sys Model Comp Connect Cntrl Structure Pipeline stream filters (local data flow data flow stream processing) ASCII streams Data abstraction localized Servers procedure call, decentralized, state maint (ADTs, objs), message passing single thread MVC SOA Events implicit independent blind loose coupling invocation components announce Interpreter virtual state machine, fetch, input-driven machine two memories store Repository central 1 memory direct access internal or database, N Processes or procedure call external blackboard

Layered architecture

Used to model the interfacing of sub-systems. Organises the system into a set of layers (or abstract machines) each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. However, often artificial to structure systems in this way.

Analysis vs Design model

analysis understands while design provides solution

baseline

collection of component versions that make system. controlled which means versions of components in system cannon be changed. this means it should always be able to recreate baseline from is constituent componets.

Behavioral viewpoint

describes causal links between events and system responses during execution concerned with dynamic relationship

Data-modeling viewpoint

describes data objects used within the system and their relationship

Structural viewpoint

describes static aspects of the system, used to model static relationships between design objects

mainline

sequence of baselines representing different versions

codeline

set of versions of a software component and other config items on which that component depends

Metrics per phase Specification design and development Testing and validation MAintenance

size of document user input, distributed system, lines of code number of errors meantime to change