Software
-
Upload
burton-saunders -
Category
Documents
-
view
21 -
download
0
description
Transcript of Software
![Page 1: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/1.jpg)
Ch.2 1
Software
Its Nature and Qualities
![Page 2: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/2.jpg)
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”
![Page 3: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/3.jpg)
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
![Page 4: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/4.jpg)
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!
![Page 5: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/5.jpg)
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)
![Page 6: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/6.jpg)
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
![Page 7: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/7.jpg)
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
![Page 8: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/8.jpg)
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
![Page 9: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/9.jpg)
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)
![Page 10: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/10.jpg)
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
![Page 11: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/11.jpg)
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
![Page 12: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/12.jpg)
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
![Page 13: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/13.jpg)
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
![Page 14: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/14.jpg)
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
![Page 15: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/15.jpg)
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
![Page 16: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/16.jpg)
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
![Page 17: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/17.jpg)
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
![Page 18: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/18.jpg)
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%)
![Page 19: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/19.jpg)
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
![Page 20: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/20.jpg)
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)
![Page 21: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/21.jpg)
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
![Page 22: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/22.jpg)
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
![Page 23: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/23.jpg)
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
![Page 24: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/24.jpg)
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
![Page 25: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/25.jpg)
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
![Page 26: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/26.jpg)
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)
![Page 27: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/27.jpg)
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
![Page 28: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/28.jpg)
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
![Page 29: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/29.jpg)
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
![Page 30: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/30.jpg)
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
![Page 31: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/31.jpg)
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)
![Page 32: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/32.jpg)
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
![Page 33: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/33.jpg)
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)
![Page 34: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/34.jpg)
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
![Page 35: Software](https://reader034.fdocuments.in/reader034/viewer/2022051620/56813082550346895d965ec9/html5/thumbnails/35.jpg)
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