Software

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 Qualities Engineering 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 Qualities Any 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 necessaryforreliability (external) Ch.2

6. Classification of sw qualities"ilities" • Product vs. process • process usedtoproduce a swproduct • product  what is deliveredtothecustomer + intermediate(work) products (reqs, designdocs, test data, etc.) • Process quality affects product quality • processqualities  productqualities • e.g., processquality  carefulplanning of test data beforedesignthenproductreliability(productquality) increases • Configurationmanagement  maintaining & controllingrelationshipbtwallrelatedworkproducts Ch.2

7. Representative qualities The 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! • Otherreqs – performance & scalability do not exist in thosespecs. Software  specification • A mathematicalproperty (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 • Requirementsmight not be an accuratestatement of whatuserwants (humanwrites it) • Upshot is sometimeswehavecorrectappsforincorrectreqs •  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/ nostrictlinebtw) • if a requirement • exist in specs  subject of correctness • left in specs  subject of robustness • A process is alsorobustif it can accomodateunanticipatedchanges in theproductionenvironment Ch.2

15. Performance performance efficiency • efficiency: how economicallyswutilizescomputerresources, memory, processing time, etc. (internal) • performance: based on userrequirements (external) • Can be verified • complexity analysis (theoretical–averageorworstcase) • performance evaluation • measurement (measurewholesysbyhw&swmonitors • analysis (build a math model – lessaccurate, cheap) • simulaton (build model – moreaccurate, expensive) • Performance of a processdeterminesproductivity 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) • testedviaswmonitors – codeinsertedintothesw Modular design Disciplinedcodingpracticecontributesto Appropriate 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 modificationsareoftenmade w/o feasibilitystudy • Ifdesign is madeevolution in mind • sw can evolvegracefully • AmericanAirlines SABRE systemdesignedmid 60s • propermodularization is needed ! Studiesshowthateachreleasedecreasesevolvability of swsystems 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 lessthan sum of individualproductivity of teammembers • veryimportantqualityduetoincreasingcost of sw • hard-to-measure (differentmetrics, teamorganizations) 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 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 qualities Information systems • Based on storageandretrieval of data • Primarilydatabasesystems • ISsare data-orientedandcharacterizedby • Data integrity (corruptionsduetomalfunction) • Security (protectunauthorizedaccess) • Data availability (underwhatconditions data becomeavailable) • Transaction performance (#of transactionsperunit time) • Endusersareordinarypeople (salesclerks, adminstaff) • Human-computerintertaction & user-friendliness • Supportend-usercomputingtooffersimplecustomization Ch.2

31. Application-specific qualities Real-time systems • Respond w/in predefined & strictperiod of time • sound an alarm duetotemperature • flightswoperatingaccordingtoweatherconditions • response time is a correctnesscriterionratherthan a performanceissue • E.g., Mouse clicks causeinterrupts • One-leftclick: select an object • Two-leftclicks (close in time): opentheobject • Real-time systemsrequire‘‘fastresponsetimes’’ WRONG • Weneed a quantitativelyspecifiableandveirfiableresponse time • Real-time systems controloriented, requiresscheduling (priorityordeadline) Ch.2

32. Application-specific qualities Distributed systems • Independentor semi-independentcomputersareconnectedvia a communication network • New requirement • Supportfordevelopment in multiplecomputers • Gaveriseto Java (bytecode) and C# (componentsareloaded & executed on differentmachines) • Characteristics of DS • Amount of distribution – data, processing, orboth? • Partitioning of network – twoormoresubsets? • Toleratefailure of individualcomputers? • DS offernewopportunitiesforachievingpriorqualities • Replicating data increasereliabilityandperformance • Codemobility (e.g., javascripts)  improveperformance Ch.2

33. Application-specific qualities Embedded systems • sw is justonecomponent of ESs • ESsoften do not haveuser-interface • swcommunicates w/ hwratherthanhumans • coin-operatedvendingmachine • ESsareoftenreal-time in natüre • Inpractice, appsmayexhibitcommoncharacteristics • E.g., an IS beingdistributedhavingsomereal-time reqsandevenembedded in a largermonitoringsystem (example, a hospitalpatient-monitoringsystem) Ch.2

34. Quality measurement • Whengoals & neededqualitiesaredecided, weneedprinciples & techniquestoachieveandmeasurethem DEFINE A QUALITY andthen MEASURE IT QUANTITATIVELY • Research is going on achievingsuchparadigm 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 Ch.2