Software Systems Analysis and Design

S. Ramanathan

What is a System?

Set of interrelated elements with a common goal (e.g) business system, political system

The System Concept

Systems may be abstract (conceptual) or physical
Social system is an example of abstract system Data processing system is a physical system

A system is defined by
Goals Inputs and outputs Conversion process Feedback and control Communication with other subsystems Environment Boundaries

ENVIRONMENT

BOUNDARY

INPUT

PROCESS

OUTPUT

Control / Feedback

Classification of Systems
Natural (rivers, lakes) or manmade (Computer) Closed (does not interact with outside world) or Open (interacts with external environment)

System Analysis
For proper understanding of the existing system and designing new system Helps in understanding interrelationships between the subsystems

What is Software?
1. Instructions (programs) that when executed produce desired features, functions and performance 2. Data structures that enable the programs to adequately manipulate information 3. Documents that describe the operation and use of the programs

Issues with Software Development

Why does it take so long to complete a software? Why are development costs so high? Why cant you find errors before delivering software? Why do we spend so much time and effort in maintaining existing software? Why do we continue to have difficulty in measuring progress, as software is being developed?

Why is software different?

Software is a logical and not physical product Quality of the product is dependent on quality of the people employed Accommodating change can create problems in a software and change is a reality! Most software is custom built

Why Structured Systems Development Methodology?

Software often did not (does not?) meet
The functionality requirements The Performance expectations of the user Adhere to the budgetary limits, originally estimated and agreed upon Adhere to the time schedule specified and agreed upon
Software cannot be creative art of individual programmers; there is a need to have a disciplined framework and a defined process for software

What is Structured Methodology?

Problem Analysis Design of a solution Construction of a solution Verification of the appropriateness of the solution Ensuring sustainability of the solution Maintenance Management of technical aspects

Steps in Structured Systems Development Methodology

What is the problem to be solved? What characteristics of the solution will be used to solve the problem? How will the solution be realized? What approach will be used to uncover errors as the solution is developed? How will the product be supported over a long time corrections, enhancements

Definition

Development

Support

System Definition
Focus on what
What problem is proposed to be solved? What functions are desired in the solution? What data to be processed for this? What level of performance is desired? What system behaviour can be expected? What interfaces to be established? What are the design constraints? What validation criteria are required? Addressed in Feasibility study and Analysis phases

System Development
Focus on how
How to structure data How to implement the desired functions How to implement procedural details How to establish interfaces How to translate the design into a program How to perform testing Addressed in design, program construction and testing phases

System Support
Focus on change Error correction Adaptation for new environments Enhancements

Addressed in Implementation and Maintenance Phases

SDLC
Identifies all the activities required for Software development Establishes a precedence ordering among the different activities Divides life cycle into phases

How can SDLC ensure quality?

Defined activity in each phase Planning and control Standards and compliance Documentation Staffing Checkpoints Sign off

Umbrella activities
Project tracking and control
Budgeting Reporting Review signoffs

Quality assurance Configuration management Documentation Change Management Reusability management Measurement Risk management

Roles in a Project
Steering Committee Project Manager Project Leader Systems Analyst Module Leader Programmers Data Base Administrator Quality Assurance Testers Domain Specialist Technology Specialist Documentation Specialist

Feasibility Study

Steps in Feasibility Study

Identify the problem and its impact Identify the objective Identify the scope in an unambiguous manner a way intelligible to managers in a bounded manner

Software Scope
functional requirements data to be processed control requirements performance requirements constraints interfaces reliability requirements

Software Scope Information Requirements

Who is the initiator of this project? Who will use the solution? What will be the economic benefit of a successful solution? Will the solution have major implication? Will it have an impact on organizational structure? How would the customer evaluate a successful solution? What is likely to be the environment the solution will be used? Any performance requirements? Constraints?

Cost / Benefit Analysis

Quantification of benefits Net Present Value Analysis

Feasibility
Technology: Is the project technically feasible? Is it within the state of the art? Finance: Can the software be developed at a cost that the client or market can afford? Economic: Do the benefits exceed cost? Time: Will the project / product be delivered in time to meet the customer needs / competition? Resources: Does the organization have the resources to complete the project? Operational: Can the input data be collected? Are the outputs usable? Behavioural: What impact will the system have on the quality of working life of users? Legal: Does the project comply with the local legal requirements?

Business Case
Detailed definition of problem Analysis of potential solutions Potential cost, risk, benefits and issues for each option Recommended solution and generic plan Justification based on cost-benefit analysis Time impact on cost, benefit

Terms of Reference
Vision Objectives Scope Deliverables Organization structure roles and responsibilities Summarized plan of activities Resource requirements Fund requirements Risks issues Assumptions constraints

System Requirements Analysis (more broadly Requirements Engineering)

Steps in Requirements Engineering Process

Requirements elicitation Requirements analysis System modeling Requirements specification Requirements validation Requirements management

Requirements Elicitation
Ask the user
What are the objectives of the system What needs to be accomplished How does the system fit into the needs of the business How is the system proposed to be used

Problems in Requirements Elicitation

Scope Ill-defined boundaries User specification of unnecessary technical detail Missing the wood for the trees Understanding Uncertainty of requirements Poor understanding of the capabilities and limitations of the computing environment Incomplete understanding of the problem domain Inability to communicate with systems analyst Omitting obvious information Specification of requirements in conflict with other user requirements Ambiguous / untestable requirements Volatility Change of requirements over time

Guidelines for Requirements Elicitation

Identify the organizational bias of the users who specify the requirements Define the technical environment (e.g. computing architecture, operating system, telecommunication needs) into which the system will be placed Identify domain constraints I.e. characteristics of the business that limit the functionality of the system Define appropriate elicitation method(s) Broad base the user participation such that each requirement can be adequately cross checked Identify ambiguous requirements as candidates for prototyping Create usage scenarios for users to better identify requirements

Initiating the Requirements Elicitation Process First Questions

Who is the initiator of this project? Who will use the solution? What will be the economic benefit of a successful solution? Will the solution have major implication? Will it have an impact on organizational structure? How would the customer evaluate a successful solution? What is likely to be the environment the solution will be used? Any performance requirements? Constraints?

Initiating the Requirements Elicitation Process First Steps

Identifying the stakeholders Recognizing multiple viewpoints Working towards collaboration
Meeting at definite time with an agenda Facilitator Visual aids

Requirements Negotiation
Recognize that you are not in competition with the user Decide on what you want to achieve and chalk out a strategy towards it. Listen: Dont cut short the user on the basis of some assumptions Focus on other partys interest Dont take positions Dont let it go personal: Focus on the problem Be creative: Think out of the box, particularly at stalemate situations Be ready to commit, once a decision is reached

Work products of Requirement Elicitation

Statement of need and feasibility Bounded statement of scope List of stakeholders who participated in the study Broad technical parameters, in which the system will operate List of requirements, organized by function and domain constraint for each Set of usage scenarios for insight into the use of the product under different operating conditions Prototypes, if any

Requirements Analysis
Categorize the requirements identified in the elicitation into related subsets Explore each requirement in relation to others Examine requirements for consistency, omissions and ambiguity Rank requirements based on user needs

Requirements Analysis Contd.

Is each requirement consistent with the overall objectives of the system? Have all requirements been specified at proper level of abstraction? Is the requirement really necessary? Is each requirement bounded and unambiguous? Does each requirement have an identified source? Is there any conflict between requirements? Is each requirement achievable in the proposed technical environment? Is each requirement testable?

Requirements Analysis Contd

Bring pragmatism in the ambitious requirements of the users Search for the essential requirement among the conflicting requirements Reconcile the differences Ask users to rank requirements to resolve conflicts Iteratively eliminate / combine / modify requirements

Requirements Specification
Introduction
Goals and objectives of the software Context of the computer-based system.

Information Description:
Problem description Information content, flow and structure Hardware,software, human interfaces for external system elements and internal software functions.

Functional Description:
Diagrammatic representation of functions Processing narrative for each function. Interplay among functions Design constraints

Requirements Specification Contd.

Behavioural Description: Response to external events and internal controls Validation Criteria: Classes of tests to be performed to validate functions, performance and constraints Bibliography: Software engineering documentation Technical references Vendor literature Standards Appendix: Tabular data Detailed description of algorithms Charts, graphs and other such material.

Requirements Validation
by both the software developer and the customer. First review for
completeness consistency accuracy.

Detailed review of
Informational functional and behavioural domains

sign off by both the customer and the developer

This is a contract for software development.

Requirements Management
Activities that help the project team to identify, control and track requirements and changes to requirements Create traceability tables:
Features traceability table:how requirements relate to user observable features Source traceability table: source of each requirement Dependency traceability table: relationship between requirements Subsystem traceability table: categorization of requirements Interface traceability table: relationship of requirements to internal and external interfaces

Analysis Modeling Techniques

What is modeling?

A model is a simplification of reality. It provides a blue print of a system. A good model includes elements that have broad effects and omit elements that are not relevant to system.

Principles of Modeling
1. Every model may be expressed in different levels of precision 2. The best models are connected to reality 3. No single model is sufficient

Analysis Modeling Rules of Thumb

Start with high level of abstraction: dont get bogged down by details; dont try to explain at this stage how the system will work Identify elements that add to the overall understanding of the requirements Minimize interconnections Understand different requirements of different stake holders and present them the view useful to them Keep the model as simple as possible

Domain Analysis
Understand the domain
Literature survey Existing applications Customer surveys Expert advice

Dont go by just current requirements; anticipate future requirements Identify recurring patterns reusable components

Usage Scenarios Use cases

A use case specifies behavior of a system or part of a system and is a description of a set of sequence of actions, including variants that a system performs to yield an observable result of value to an actor. It describes WHAT a system does but does not specify HOW it does.
Validate user Sensors:: Calibrate location

Actors
An actor represents a coherent set of roles that users of use case play when interacting with the use cases.

It represents a human, a hardware device or even another system.

Actors are not part of the system though they are used in a system. They lie outside the system.

A USE CASE DIAGRAM

Place phone call

Place conference hall

Cellular network

Receive phone call

Receive additional call

User

User scheduler

Cellular telephone

MODELLING THE CONTEXT OF A SYSTEM

Credit card validating system Perform card transaction

Customer

Process customer bill

retail institution

Reconcile transactions

sponsoring financial Corporate institution Customer

Manage customer account Individual customer

To model the requirements of a system

Establish the context of the system by identifying the actors that surroun For each actor consider the behavior that each expects or requires the system to provide

Name these common behaviors as use cases Factor common behavior into new use case that are used by others;

Factor variant behavior into new use cases that extend more main line

Model these use cases, actor, and their relationships in a use case dia

Adorn these use cases with notes that assert nonfunctional requireme

When it

When is a use case diagram said to be well-structured?

Is focused on communication one aspect of a systems static use case Contains only those use cases and actors that are essential to understand that aspect Provides details consistent with its level of abstraction; you should expose only those adornments that are essential to understanding. Is not so minimalist (simple) as to misinform the reader about semantics that are important.

Principles of Drawing Use Case Diagrams

Give it a name that communicates its purpose Lay out its elements to minimize lines that cross Organize elements spatially so that behaviors and roles that are semantically close are laid out physically close

Use notes and color as visual cues to draw attention to important featu of your diagram Try not to show too many kinds of relationships. If you have any complicated relationships, take these elements to another diagram.

Prepare Use cases for the following:

a. Elevator ride to top floor b. Operation of a car cruise control in heavy traffic

Elements of the Analysis Model

Scenario-based
Use-cases Activity diagrams Swimlane diagrams

Behavioral
State diagrams Sequence diagrams

Static
E-R Diagrams Class diagrams

Flow-oriented
Data flow diagrams Process specifications

Flow-Oriented Modeling: Data Flow Diagram

External Entity Flow

Process

Data Store

Process

Data Store

DFDs - Rules
Naming and Numbering of
Entities Processes Data Stores

Direction and Naming of Flows Process explosion numbering of sub-processes Process specification

Tools for Process Specification

Flow Chart Decision Tree Decision Table Structured English

Flow Chart

Repetition Selection

Sequence

Decision Tree
6 or more Book Store Less than 6 Discount Policy 50 or more Libraries / individuals 20 - 49 6 - 19 Less than 6 15% 10% 5% Nil 25% Nil

Structured English (Example)

If previous reading and new reading match then perform 'status-check' If status is 'dead' then calculate bills based on average consumption Else compute bill based on actual consumption status-check If meter does not register any change after switching on any electrical device then meter status is 'dead' Else meter status is 'ok'

Structured English compared with Normal English

Loose, normal English:
In the case of 'Bill', a master file is updated with the bill (that is consumer account number and bill date). A control file is also to be updated for the 'total bill amount'. A similar treatment is to be given to 'Payment

Structured English:
If transaction is 'BILL' then update bill in the Accounts master file update total bill amount in the Control file If transaction is 'PAYMENT' then update receipt in the Accounts master file update total receipt amount in the Control file

Static Modelling
Description of applications in terms of
Entities / objects Attributes Relationships

Cardinality
One-to-One One-to-Many Many-to-many

Modality
Modality of a relationship is 0, if there is no explicit need for the relationship to occur 1, if the occurrence of relationship is mandatory

Object-Oriented Concepts
Class: encapsulates the data and procedures required to describe the content and behavior of some real world entity; Object: instance of a class Attribute: data value(s) of a class Operation: behavior of a class Subclass: specialization of a superclass Superclass / Base class: generalization of a set of classes

Identification of Classes
External entities Things Events Roles Organizational units Places Structures

Selection Criteria for Classes

Is the information about it to be remembered for the system to function? It must have operations that can change its values in some way It should have multiple attributes There must be some attributes that are applicable to all the instances of the class There must be some operations that are applicable to all the instances of the class External entities

Identify the Classes in the following

Conducted tour package A school A computer program Computer hard disk Engine

Specifying Attributes
What data items fully define the class? May be elementary or composite Composite data items are represented in terms of elementary data items:
item code = source code+group code+subgroup code+serial no.

Defining Operations
Operations define the behavior of an object Broad categories
That manipulate data in some way That perform a computation That inquire about the state of an object That monitor an object for the occurrence of a controlling event

Derived from process specifications

Scenario-based Modeling
Writing use-cases

Scenario
Outcome: Insurance company pays claim
1. Claimant submits claim with substantiating data. 2. Insurance company verifies claimant owns a valid policy (failure here probably means goal failure) 3. Insurance company assigns agent to examine case. 4. Agent verifies all details are within policy guidelines. (an interaction between the agent and secondary actors) 5. Insurance company pays claimant (implies all preceding goals managed to pass)

Extensions
1a. Submitted data is incomplete:
1a1. Insurance company requests missing information 1a2. Claimant supplies missing information

2a. Claimant does not own a valid policy:

2a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.

3a. No agents are available at this time

3a1. (What does the insurance company do here?)

4a. Accident violates basic policy guidelines:

4a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.

4b. Accident violates some minor policy guidelines:

4b1. Insurance company begins negotiation with claimant as to degree of payment to be made. The greatest value of the use case does not lie in the main scenario, but in alternative behaviors

Variations
1. Claimant is
a. a person b. another insurance company c. the government

5. Payment is
a. by check b. by interbank transfer c. by automatic prepayment of next installment d. by creation and payment of another policy

Activity Diagram
Graphical representation of the interaction within a specified scenario

Conduct interviews
Make list of classes, functions Make list of constraints Elicit requirements Formal prioritization? Y Y Use QFD N Informal method

Create use-cases

Define actors Create use-cases Draw use-case diagram

Create scenarios

Create template

L ge r d ta o rro e ils

S a E p y eD ta c n m lo e e ils

s c e try uh n

[D ta a eF ilu a b s a re

E p y ed ta m lo e e ils fro E p y e m m lo e d ta a em s a b s ut b fe h db e tc e y a n a c tra k r tte d n e c e F tc D ta a eD ta e h a b s e ils

Sa n rs n s cne ed s a n de p y e c n e m lo e d ta toa n a c e ils tte d n e tra k r ce

S n E p y eD ta e d m lo e e ils

[D ta a eF tc S c e s a b s e h uc s

V rifyE p y eD ta e m lo e e ils

[V lidE p y e a m lo e

S v A n a c In rm tio a e tte d n e fo a n

[S o g e s n l h w re n ig a

E it B e m ep

So s n l h w ig a

Swimlane Diagrams
Variation of Activity Diagram Additional information on which actor is involved in which function

Behavioral Model
For applications driven by events Time and performance are critical

State Diagram
Emphasizes the event ordered behaviour of an object

Initial state final

STAT ES
Key press

shutdown state Running

Idle

finished name

Initial state and final state

Initial state indicates starting place for the state machine or substate and is represented as a filled black circle. Final state indicates that the execution of the state machine or enclosing state has been completed and is represented as a filled black circle surrounded by an unfilled circle.

Sequence Diagram
Emphasizes the time ordering of message Shows a set of objects and message sent by and received by those objects These objects may be instances of classes, collaborations, components and nodes

Sequence Diagram an example

Client Object Supplier Object
:Client :Supplier

Object Lifeline
1: PerformResponsibility

Reflexive Message

Message

Focus of Control

The Anatomy of Sequence Diagrams

Object life line represents the existence of an object over a period of time If any object is created during a transaction, then its lifeline starts from the receipt of that message. Similarly objects may be destroyed before the end of the transaction Focus of control: period of time during which an object is performing an action, either directly or through a subordinate procedure; represented by a thin rectangle

Design Engineering

What is System Design?

Detailing how the proposed system can be realized into a working model

Design Model

Component Design Interface Design Architectural Design Data Design

Analysis Model Design Model

Behavioral State diagrams Sequence diagrams Scenario-based Use-cases Activity diagrams Swimlane diagrams Flow-oriented Data flow diagrams Process specifications Static E-R Diagrams Class Diagrams

Component Design Interface Design Architectural Design Data Design

Basic Principles of Design

Object-Oriented Design

Encapsulation

Abstraction

Modularity

Hierarchy

What is Abstraction?
Any model that includes the most important, essential, or distinguishing aspects of something while suppressing or ignoring less important, immaterial, or diversionary details. The result of removing distinctions so as to emphasize commonalties The essential characteristics of an entity that distinguish it from all other kinds of entities. Defines a boundary relative to the perspective of the viewer Is not a concrete manifestation, denotes the ideal essence of something

ABSTRACTION
An Abstraction is a simplification or mental model that helps a person understand something at a appropriate level. This implies that different people would build radically different abstractions for the same concept.

What is Encapsulation?
Hide implementation from clients
Clients depend on interface

Abstraction and Encapsulation

Encapsulation as a counterpoint to abstraction An abstraction highlights the important aspects of an object. Encapsulation hides the internal details of the object. A well-encapsulated object allows other objects to use it without depending on any internal details.

What is Modularity?
The breaking up of something complex into manageable pieces
Order Entry

Order Processing System

Order Fulfillment

Billing

What is Hierarchy?
Levels of abstraction
Increasing abstraction

Asset

BankAccount

Security

RealEstate

Savings

Checking

Stock

Bond

Decreasing abstraction

Classes at the same level of the hierarchy should be at the same level of abstraction

Design of Data Base

Conceptual Modelling Data Modelling Storage Structure Design Physical lay-out design

Conceptual Modelling
Description of applications in terms of
Entities / objects Attributes Relationships

Cardinality
One-to-One One-to-Many Many-to-many

Data Modelling
Translate conceptual model into a data model (eg) deriving a relational data model from entity relationship model Tool: Normalization

Normalization
Record design technique to avoid some update anomalies First Normal Form: no repeating groups Second Normal Form: all non-key data items should depend on key only Third Normal Form: no non-key item should depend on another non-key item

Architectural Design
Major modules Function and Scope of each module Interface features of each module Modules that each module can call directly or indirectly Data received from / sent to / modified in other modules Tool: Functional Decomposition

Functional Decomposition
Module Couple

Couple: Data item passing from one module to another

Design Principles
Do not confine to a single pre-judged solution; consider alternatives Traceability to analysis Suitability to the structure of the problem Easily identifiable relationship of software functions to user function Uniformity in style and format Modularity

Modularity
Module is a manageable unit performing a well-defined task Modules contain instructions and data for performing a particular task. Modules have well-defined interfaces. Advantages: Maintainability, Reusability

Measures of Modularity
Cohesion: how well the elements fit together in a module Coupling: strength of interconnection between modules Desired: High Cohesion and Low Coupling

User Interface Design The Golden Rules

1. Place the user in control 2. Reduce the users memory load 3. Make the interface consistent

Interface Analysis and Design Models

Know the user, know the tasks Categorize users as novices, professionals and experts Screen should match the users mental model Look and feel Help Physical environment of the location
Physical location Users posture Space, light, noise constraints Special human factor considerations

Design Issues
System response time length and variability User help facilities
Availability for all / selected functions Request for help menu, function key Representation of help separate window Return to normal interaction

Error information handling

User understandable language Constructive advice for recovery from the error Any negative consequence o the error Audio / visual cue nonjudgmental

Command labeling
Command options control sequence, function key Ease of remembering commands Facility of customization by the user Self-explanatory labels Consistency of submenus with main menu

Internationalization

Software Testing

Software Testing - Objectives

Process of executing a program with an intent of finding an error

Verification and Validation

Verification refers to the set of activities that ensure that software correctly implements the specific function Validation refers to a different set of activities that ensure that the software is built as per customer requirements Verification: Are we building the product right? Validation: Are we building the right product?

Testing Strategy

Feasibility Study Reqmt. analysis System Design

System Testi Corrections

Acceptance Testing Integration testing Unit testing Coding

Program Design

The Realities of Software Testing

It is impossible to test a program completely because of very large possibilities Software testing is a risk based exercise: Cost of testing vs.loss due to undetected defects Testing can show that bugs do exist, but cannot assure that bugs do not exist The more bugs you find, the more bugs there are The more you test a software, the more it becomes immune to your testing pesticide paradox Not all the bugs you find will be fixed, because There is not enough time Could turn out to be a feature Too risky to fix Just not worth it

Unit Testing
Process of testing individual units of software in isolation of other parts of the program. This test is conducted to test
Functionality: should produce expected result for a given input value Performance: response time, execution time, throughput, memory utilization, traffic in communication channels Stress: Checking the limits Structure: processing logic

Unit Test Considerations

All independent paths should be executed at least once Boundary conditions Common errors
Incorrect arithmetic precedence Mixed mode operations Incorrect initialization Precision inaccuracy Incorrect symbolic representation of an expression Defining precise equality Incorrect / non-existent loop termination Improperly modified loop variable

Antibugging

Unit Test Procedures

Adjunct to coding Test cases derived from Design Test cases should include expected results Driver and Stub

Integration Testing
If they all work individually, they will work, when we put them together and the whole product will also work False; Interfacing can create problems Hence overall product is checked

Integration Testing
Systematic technique for assembling software while at the same time conducting tests to uncover errors associated with interfacing Tests for
Interface integrity Functional validity Performance

Types
Bottom-Up Top-Down

Bottom-Up Integration
Assembly and testing with atomic modules Easier to implement, because at the time of each module testing, tested subordinate modules are available Testing of major decision / control points is deferred to a later period

Top-Down Integration
Integration starting with main control module and moving down the hierarchy, integrating subordinate modules Adv: major control / decision point are tested first and details are addressed later Disadv: Testing higher levels without the process outputs of lower levels poses difficulty

Regression Testing
The process of rerunning a portion of software to check that changes have not introduced new errors Obj: to ensure that all aspects of an application system remain functional after testing Should be conducted after a predetermined number of changes in the application system Significant during maintenance too

Smoke Testing
For time-critical projects Steps
Develop builds (integrated software engineering components) Design tests that will stop build from properly performing its function focus on show stopper errors Continuous integration of builds and daily test of the integrated build

Benefits
Integration risk is minimized by daily testing Quality of end product is improved Error diagnostics and correction simplified Progress easier to access

Integration Test Specification

Contents
Test Plan description of overall strategy for integration Test procedure

Part of software configuration

Testing Strategy for Object-Oriented Architectures

Operations cannot be tested individually, since they are embedded in the classes Unit testing at the class level Integration test of collaborating classes Regression tests as classes are integrated Finally, integration test of the entire application

Integration Testing in the OO Context

Thread-based testing: integration of set of classes required to respond to one input or event and test Use-based testing: Test independent classes first and then dependent classes, which use these independent classes Cluster testing: testing cluster of collaborating classes

Validation Testing
Step at the end of Integration Testing Testing software functions in a manner that can be reasonably expected by the custome As specified in the Validation criteria in Software Requirements Specifications

Alpha and Beta Testing

Types of Acceptance Tests Alpha Test conducted at the developers site by the end user Beta Test conducted at end user sites; developer may not be present

Stress Testing
Designed to determine if the system can function when subjected to large volumes Areas stressed: input transactions, internal tables, disk space, output, communications, computer capacity Obj: to simulate production environment Useful in situations, where volume of transactions is unpredictable such as in on-line systems Time and resource consuming

Execution Testing
Designed to determine whether the system achieves the desired level of proficiency in production status Verifies response time, turn around time, design performance Can be tested in whole or part Can be performed early in the developmental process

Recovery Testing
Ability to restart operations after the loss of application integrity Ability to return to a point of known system integrity and reprocess transactions till the point of failure Obj: to test
Adequacy of back-up data Security of back-up storage Documentation of recovery procedures Staff knowledge of recovery procedures

Simulated disaster Necessary in situations, where continuity of operations is critical

Security Testing
Designed to determine the adequacy of protective procedures Tests for both physical and logical security Obj: To determine
adequacy of identification of risks Enforcement of access control In-house expertise in security testing The functioning of security measures

Conducted just before the system goes into operational status

Debugging
Occurs as a consequence of testing

Challenges in Debugging
Cause may be in a remote location Temporary symptoms Caused by human error Non-synchronization of time Reproducibility may not be possible always Cause distributed across tasks

Debugging Tactics
Brute Force: Let the computer decide Memory Dumps Backtracking Cause elimination Automated Debugging
Debugging compilers Tracers Automatic test case generators Cross-reference mapping tools

Correcting the Error

Beware: Dont introduce another error in the process!

Parameters of Quality
Correctness Integrity Functionality:
- Suitability - Accuracy - Interoperability - Compliance - Security

Parameters of Quality Contd.

Reliability
Maturity Fault Tolerance Recoverability

Usability
Understandability Learnability Operability

Parameters of Quality Contd.

Efficiency
Performance Resource utilization

Maintainability
Traceability Changeability Stability Testability

Portability

Can you think of more?

Reusability Completeness Conciseness Consistency Expandability Generality Modularity Safety

What is a Good Test?

A good test case is one that has high probability of finding an as yet undiscovered error A good test is not redundant A good test should be best of breed A good test should be neither too simple nor too complex

Functional and Structural Testing

Also known as Black Box Testing Also known as White Box Testing No knowledge of internal logic Knowledge of internal logic required require Exclusively through validation Predominantly though verification Adv: simulates actual system usage Can detect errors which cannot be detected by functional testing

Disadv: possibility of missing Does not ensure testing of all errors functional requirements Possibility of redundant testing Does not mimic real world situations

Test-to-Pass and Test-to-Fail

Test-to-Pass:assurance that the software works in the normal conditions Test-to-Fail: Pushing to limits: Errorforcing

Basis Path Testing

White Box Testing technique Flow Graph notation Identify the number of independent paths Design tests to execute each of these paths at least once

Equivalence Partitioning
Black Box Testing Method Process of methodically reducing the huge set of possible test cases into a much smaller, but equally effective, set
Always consider creating an equivalence partition that handles the default, empty, blank, null, zero o none conditions

Boundary Conditions
Situations at the edge of the planned operational limits of the software

Scenario-Based Testing
Concentrates on what the user does and not what the product Derived from use-cases

Tests Derived from Behavioral Models

State Diagram used to derive a sequence of steps Tests designed to cover all states (eg) for a bank account, states are open, set up account, deposit, withdraw, close

Advanced Topics in Software Engineering

Formal Methods

Formal Methods
Formal methods allow a software engineer to create a specification that is more complete, consistent and unambiguous than those produced by conventional methods Uses tools such as symbol tables, sets etc.

Cleanroom Software Engineering

What is Cleanroom Software Engineering?

Do it right the first time Emphasizes mathematical verification of correctness before program construction Establish a development approach that precludes introduction of defects Eliminate errors in specification and design and then develop in a clean manner Avoiding costly defect removal processes

Why is it not popular?

Too theoretical, too mathematical and too radical for use in real software environment Drastically deviates from existing accepted practices such as Unit testing and hence too radical to implement Clean room processes demand rigorous application of defined processes; industry is not in that process maturity level to apply these techniques

The Cleanroom Process Model

Specialized version of the incremental model Independent teams develop software increments Each increment is certified and integrated into the whole

Steps in the Cleanroom Process Model

Overall product requirements specification using system engineering methods Identified software element for each functionality assignment to independent teams Tasks of each team Increment planning Identification of increments Deliverable functionality of each increment Schedule Requirement gathering Box structure specification Formal design Architectural Component level Correctness verification Application of correctness questions Formal (mathematical) methods Code generation, inspection and verification Walkthrough / inspection for semantic conformance and syntactic correctness Statistical test planning Parallel activity with specification, verification and code generation Certification After correction of errors Increment ready for integration

Box Structure Specification

A box encapsulates a system or some aspect of the system at some level of detail Through a process of elaboration and stepwise refinement, boxes are refined into a hierarchy At that stage, the information content of each box specification is sufficient to define its refinement Hierarchy with essential representation at the top to implementation at the bottom Three types of boxes Black Box: specifies the behavior of the system: transition rules mapping stimulus to response State Box: input (stimuli) and output (response) states Clear Box: procedural design required to accomplish a state box transition

Design Verification
The procedural design in each clear box is refined stepwise into programming constructs At each level of refinement, formal correctness verification is performed Advantages: Reduces verification to a finite process Verification through group analysis based on correctness theorem: more rigorous than program testing in conventional process: useful in mission-critical applications Results in near zero defect level by eliciting unanimous agreement from all team members on correctness Scalability: process of stepwise refinement and reduction to basic programming constructs the procedure valid irrespective of size More efficient than unit testing: testing functionality than paths

Statistical Unit Testing

Testing the software the way user intends to use it Based on interview with users determine probability of use for each stimuli Test cases as per usage probability distribution Verify software behavior against specification of the system

Certification
Specification of reliability (measured by meantime-to-failure MTTF) for each component Steps
Creation of usage scenarios Specification of usage profile Generation of test cases Execution of test cases; record and analysis of failure data Computation of reliability and certification

How is Cleanroom Different?

Makes explicit use of statistical quality control Verifies design specification using a mathematically based proof of correctness Implements testing techniques that have a high probability of uncovering high impact errors Deemphasizes unit testing and debugging Emphasizes on continuous improvement but it does not deviate from basic software engineering principles of emphasis on good analysis and design

Component-Based Development

Component-Based Software Engineering (CBSE)

Emphasizes design and construction of computer based systems using reusable software components Buy, dont build philosophy Composing instead of programming; integration instead of implementation Based on assumption that there is sufficient commonality across large software systems

What is a Component?
A non-trivial near-independent and replaceable part of the system that fulfils a clear function

Questions to be Addressed
Is it possible to construct complex system using a catalog of reusable components? Will it be cost-efficient and time-effective? Are the additional costs involved in creating a generalized software worth the returns due to reuse? How do we store these components and make them available when necessary?

Steps in Component-Based Software Engineering Domain Analysis to be investigated Define the domain
Identify requirements Define analysis classes Identify candidate components:
Look for repeating patterns (of functions, data and behaviour) within the application Duplication of the component within the domain Possibility of parameterization Reusability with minor changes Decompose to achieve reusability

Steps in Component-Based Software Engineering

Identify reqmts
Is it amenable to composition? Remove reqmts.?

Y
Component available?

N
COTS available?

Y Y

Use Buy N

N Identify Interface Reqmts.

N Build

Remove

Steps After Component Identification

Component Qualification
Check for the fit with the architecture Interface requirements

Component Adaptation
Component wrapping

Component Composition
Assembly of components Services for communication with other components Object Request Brokers (ORB) CORBA, COM, JavaBeans

Classifying and Retrieving Components

Describing Components Concept purpose and function of the component Content how the component is realized: needed only for modification Context domain of applicability: operational and implementation features Classification of Components Enumerated Classification: hierarchical description with classes and subclasses Faceted classification: classification based on ranked limited features Attribute-value classification: definition based on attribute values. Similar to faceted, except no ranking and limit Repository should also contain libraries and tools required to interface components

Impact of Components on Quality, Productivity and Cost

Quality
Verification before placing in repository Improvement of quality with reuse Defect rate in reused code is 0.9 / KLOC against 4.1 / KLOC (HP study) 35% 51% improvement in quality reported in studies

Productivity
25% - 40% productivity improvement reported

Cost
component development costlier than porgram specific to application because additional requirements of cost of generality and repository maintenance Payoffs realized through reuse

Reengineering

What is Reengineering?
With time, the ability of software to support the business processes wanes Solution: Reengineer the software to add functionality, improve performance, reliability and maintainability

Business Process Reengineering

The search for, and implementation of , radical changes in business process to achieve breakthrough results Definition published in Fortune magazine Business Process: a set of logically related tasks to achieve a defined business outcome Every business process has a defined customer Business processes cross organizational boundaries

A BPR Model
Evolutionary process no start or end Activities
Business definition: goal identification within the context of four key drivers cost reduction, quality improvement, personnel development and empowerment Process identification: Identification of processes that are critical to achieving the business goals; ranking of these processes by importance or need for change Process evaluation: on the basis of cost, time, quality and performance Process specification and design: use-case preparation and redesign Prototyping: for the redesigned process for testing and refinement Refinement and instantiation: Refinement based on the feedback from the prototype and instantiation within the business system

Software Reengineering Process Model

Data restructure Forward Engineering Inventory Analysis

Code restructure

Document restructure

Reverse Engineering

Software Reengineering Process Model

Inventory Analysis: Size, age, business criticality, current maintainability of each application. Select apps for reengineering Document restructure: at least for critical apps. Reverse Engineering: Analyze the program to uncover design Code restructure: Violations of structured code removed and tested Data restructure: more basic change: will impact code and architecture Forward Engineering: Perfect the design

Computer Aided Software Engineering (CASE)

Automated tools that assist in every activity associated with software process Features:
Diagramming support Code Generation Screen Painting Testing Data Dictionary Maintenance Requirement Tracing Modeling Configuration Mgmt. Prototyping Documentation support Design analysis Reengineering

Categories of CASE
Upper CASE: Requirement definitions

Middle CASE: Design Screens and Reports Lower CASE: Code generation

Benefits of CASE
Integration of the activities of SDLC Automatic standardization Guaranteed consistency and quality Removal of monotony Self documentation Reduced cost Reduced time of development

Disadvantages of CASE
Training need High cost of tools

CASE Repository
Enterprise Information
Organizational structure Business analysis Information architecture

CASE database or repository is an integrated CASE environment containing the following data:

Application Design
Model diagrams Naming standards Integrity rules Entity / object definitions Data structures Process definitions Menu trees Performance criteria Screen definitions Report definitions Processing logic

CASE Repository
Construction
Source code Object code Change information

Testing
Test plan Test results Quality Metrics

Project Management
Project plan Work breakdown structure Estimation, schedules Problem reports Change requests, status reports Audit information

Documentation
System requirement specifications Design document User manuals