Ch.21 Software Its Nature and Qualities. Ch.22 Outline Software engineering (SE) is an intellectual...
-
Upload
bethanie-martin -
Category
Documents
-
view
216 -
download
0
Transcript of Ch.21 Software Its Nature and Qualities. Ch.22 Outline Software engineering (SE) is an intellectual...
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