Ch.2 1

Software

Its Nature and Qualities

Ch.2 2

Outline

• Software engineering (SE) is an intellectual activity and thus human-intensive

• Software is built to meet a certain functional goal and satisfy certain qualities

• Software processes also must meet certain qualities

• Software qualities are sometimes referred to as “ilities”

Ch.2 3

Software: Its nature and QualitiesEngineering goal: build sth, an artifact, or product

– SE builds a “sw system’’ (intangible)• difficult to describe and evaluate

– malleable• people ask for modifications so often• people think it is easy, in practice is is not!• change in sw is change in design which is an

instance of product

– human intensive• involves only trivial “manufacturing” process

Ch.2 4

Software: Its nature and QualitiesAny product has some acceptance standards

– a bridge• travel across a river, no collapse w/ wind,

convoy of trucks shall pass, etc.

– a transistor• power range, frequency interval, etc.

– a software• not clear, intermixed in specifications!

Ch.2 5

Classification of sw qualities"ilities"Software quality applies to

– the process (productive, predictable, easy-to-control)

– the product (verifiable, maintainable, portable, etc.)

•Internal vs. external– external visible to users– internal concern developers– internal qualities affect external qualities

• e.g., verifiability (internal) is necessary for reliability (external)

Ch.2 6

Classification of sw qualities"ilities"• Product vs. process

– process used to produce a sw product– product what is delivered to the customer +

intermediate (work) products (reqs, design docs, test data, etc.)

– Process quality affects product quality• process qualities product qualities

– e.g., process quality careful planning of test data before design then product reliability (product quality) increases

– Configuration management maintaining & controlling relationship btw all related work products

Ch.2 7

Representative qualitiesThe most important qualities of sw products & processes

– Correctness, reliability, and robustness– Performance– Usability– Verifiability– Maintainability

• Reparability• Evolvability

– Reusability– Portability– Understandability– Interoperability– Productivity– Timeliness– Visibility

Ch.2 8

Correctness• Software is (functionally) correct if it

satisfies the functional requirements specifications– assuming that specification exists!

• Other reqs – performance & scalability do not exist in those specs.

Software specification

• A mathematical property (experimental, analytical)correctness

Ch.2 9

The limits of correctness

• It is an absolute (yes/no) quality– there is no concept of “degree of

correctness”– there is no concept of severity of

deviation

• What if specifications are wrong?– (e.g., they derive from incorrect

requirements or errors in domain knowledge)

Ch.2 10

Reliability

• Reliability– informally, user can rely on it– can be defined mathematically as

“probability of sw operates as expected for a certain time period”

– if specs are correct, all correct software is reliable, but not vice-versa

– if consequences are not serious, incorrect sw can still be reliable

Ch.2 11

Reliability

• Engineering products are expected to be reliable

• However SE products commonly released by ‘‘known bugs’’– Release 1 is ‘‘buggy’’

• Therefore, SE is an immature engineering discipline

Ch.2 12

Idealized situation

Assumption: requirements are correct

Reliability

Correctness

• Requirements might not be an accurate statement of what user wants (human writes it)

• Upshot is sometimes we have correct apps for incorrect reqs correctness is sufficient

Ch.2 13

Robustness

• Robustness – software behaves “reasonably” even in

unforeseen circumstances (e.g., incorrect input, hardware failure)

– Difficult-to-define property• if can be defined precisely then =

correctness

– Two bridges over the river, both are correct, but one collapses w/ an eartquake, then the other is more robust

Ch.2 14

Robustness

Robustness correctness (w/ no strict line btw)

•if a requirement– exist in specs subject of correctness– left in specs subject of robustness

•A process is also robust if it can accomodate unanticipated changes in the production environment

Ch.2 15

Performance

performance efficiency•efficiency: how economically sw utilizes computer resources, memory, processing time, etc. (internal)•performance: based on user requirements (external)•Can be verified

• complexity analysis (theoretical–average or worst case)• performance evaluation

– measurement (measure whole sys by hw&sw monitors – analysis (build a math model – less accurate, cheap)– simulaton (build model – more accurate, expensive)

•Performance of a process determines productivity

Ch.2 16

Usability (or user-friendliness)• Expected users find the system easy to

use– desires of expert & non-expert users might

vary (subjective - difficult to evaluate)

• Other term: user-friendliness

• Affected mostly by user interface• e.g., visual vs. textual• usability engineering

Ch.2 17

Verifiability

• How easy it is to verify properties– mostly an internal quality– can be external as well (e.g., security critical

application) – tested via sw monitors – code inserted into

the sw

Modular designDisciplined coding practice contributes toAppropriate PL verifiability

Ch.2 18

Maintainability• Maintainability: ease of maintenance• Maintenance: changes after release

Maintenance costs > 60% of total cost of sw

• Three main categories of maintenance– corrective: removing residual errors (20%)– adaptive: adjusting to environment changes

(20%)– perfective: quality improvements (>50%)

Ch.2 19

Maintainability

• Can be decomposed as– Repairability

• ability to correct defects in reasonable time

– Evolvability• ability to adapt sw to environment changes

and to improve it in reasonable time

• Distinction is not clear and depends on requirements

Ch.2 20

Repairability

• Repairability• ability to correct in reasonable time

– automobiles built w/ reparable engine parts– computer systems built b standard bus interface

• as cost decreases need for reparability decreases

• A sw consisting of well-designed modules is easier to repair

– However, increasing # of modules leads complex interconnections which does not help producing more repairable products (trade-off)

Ch.2 21

Evolvability• SW modifications are often made w/o

feasibility study• If design is made evolution in mind

– sw can evolve gracefully– American Airlines SABRE system designed mid

60s– proper modularization is needed

! Studies show that each release decreases evolvability of sw systems

Ch.2 22

Reusability

• Evolution modify to build a new version

• Reuse use existing product (or components) to build another product– UNIX Shell batch (script programming)– FORTRAN, C, C++ libraries

• OOP– aims achieving reusability & evolvability

Ch.2 23

Portability

• Software can run on different hw platforms or sw environments– e.g. iOS, Android systems & CSS, HTML5

• As networked systems pervade, importance of portability increases due to heteregeneous execution environments

• Portable product or porting a product is an example of reusability

Ch.2 24

Understandability

• Ease of understanding software– abstraction & modularity enhance

understandability

• Program modification requires ‘‘program understanding’’– internal understandability – helps achieving

evolvability & verifiability– External understandability – is a factor in

prduct usability

Ch.2 25

Interoperability

• Ability of a system to coexist and cooperate with other systems – e.g., word processor and spreadsheet– e.g., new OSs support plug-and-play to

automatically detect & work w/ new devices

Ch.2 26

Typical process qualities

• Productivity– denotes its efficiency and performance

productivity of a team is often

less than sum of individual productivity of team members

– very important quality due to increasing cost of sw• hard-to-measure (different metrics, team

organizations)

Ch.2 27

Typical process qualities

• Timeliness– ability to deliver a product on time– major quality leading birth of SE after

‘‘software crisis’’– By itself is not useful: delivering an

unreliable & performance lacking product on time is pointless

• gave rise to the concept pf releasing beta versions

• Ada compiler example

Ch.2 28

Timeliness: a visual description of the mismatch

Function

t t t t t0 1 2 3 4

User needs

Actual system capabilities

Time

Continuously changing user reqs explain why most sw developments fail

One technique for achieving timeliness is ‘‘incremental delivery’’

• another Ada compiler design example• relies on ability to break down into subsets

Ch.2 29

Typical process qualities

• Visibility– all of its steps and current status are

documented clearly – allows engineers weigh the impact of their

actions and guides them• e.g., while integration group is testing the

product, engineering group decides to do a majör redesign to add some functionality

– stabilization tension de-stabilization

– Helps new engineers joining the team to gain folklore of the project

Ch.2 30

Application-specific qualitiesInformation systems•Based on storage and retrieval of data

– Primarily database systems

•ISs are data-oriented and characterized by– Data integrity (corruptions due to malfunction)– Security (protect unauthorized access)– Data availability (under what conditions data become available)– Transaction performance (#of transactions per unit time)

•End users are ordinary people (sales clerks, admin staff)– Human-computer intertaction & user-friendliness– Support end-user computing to offer simple customization

Ch.2 31

Application-specific qualitiesReal-time systems•Respond w/in predefined & strict period of time

– sound an alarm due to temperature– flight sw operating according to weather conditions– response time is a correctness criterion rather than a performance

issue

•E.g., Mouse clicks cause interrupts– One-left click: select an object– Two-left clicks (close in time): open the object

•Real-time systems require ‘‘fast response times’’ WRONG– We need a quantitatively specifiable and veirfiable response time

•Real-time systems control oriented, requires scheduling (priority or deadline)

Ch.2 32

Application-specific qualitiesDistributed systems•Independent or semi-independent computers are connected via a communication network•New requirement

– Support for development in multiple computers– Gave rise to Java (bytecode) and C# (components are loaded &

executed on different machines)

•Characteristics of DS1. Amount of distribution – data, processing, or both?2. Partitioning of network – two or more subsets?3. Tolerate failure of individual computers?

•DS offer new opportunities for achieving prior qualities– Replicating data increase reliability and performance– Code mobility (e.g., javascripts) improve performance

Ch.2 33

Application-specific qualitiesEmbedded systems•sw is just one component of ESs •ESs often do not have user-interface•sw communicates w/ hw rather than humans

– coin-operated vending machine

•ESs are often real-time in natüre

•In practice, apps may exhibit common characteristics– E.g., an IS being distributed having some real-time reqs and

even embedded in a larger monitoring system

(example, a hospital patient-monitoring system)

Ch.2 34

Quality measurement

• When goals & needed qualities are decided, we need principles & techniques to achieve and measure them

DEFINE A QUALITY and then

MEASURE IT QUANTITATIVELY• Research is going on achieving such

paradigm

Ch.2 35

Concluding remarks

• SE is concerned w/ applying engineering principles to building of sw products

• Defining engineering principles apply uniformly on differing sw products requires devising a set of qualities characterizing the product (what we have done today)

• Next step learn what principles to apply so that we build sw products achieving these qualities