1. Software Qualities

2. Unique Properties of Software (Teams: What are the properties of software that make it unique from other engineering disciplines?)

3. Unique properties of software malleable: –can replace ordinary switch with electronic, more "intelligent“ –the only replaceable component of a deep space craft artificial: –not tied to physical properties like civil or mechanical human-intensive: –almost no manufacturing: all engineering complex: –each bolt is different use: –applied out of scope of development young field

4. Software Qualities: Two types –External: –Internal: Two categories –Product: –Process:

5. Software Qualities: Two types –External: visible to users (e.g., speed) –Internal: visible to developers (e.g., verifiability) Two categories –Product: difficult to measure –Process: I can't show you how good it is, but I can tell you how hard we tried

6. Only external factors matter. It doesn’t matter if it’s written in C or Java or Lisp or 6502 machine language, so long as it does what it’s supposed to. The internal properties are just a means to achieve external properties.

7. External Software Properties Correctness Robustness Reliability Extendibility Compatibility Efficiency Portability Ease of use Functionality Timeliness Verifiability Integrity Maintainability Reusability

8. Correctness Ability of software to perform tasks as defined by the specification. Note that this is not possible without a specification: –if you don’t know what it’s supposed to do, how can you tell if it’s correct? http://nazareneblogs.org/kpprobst/files/2010/06/politically-correct.jpg

9. Robustness Ability of software to react appropriately to abnormal conditions. This is a compliment to correctness. They do not overlap. http://www.agilemodeling.com/images/models/robustnessDiagram.JPG

10. Reliability The probability that software will provide failure-free operation in a fixed environment for a fixed interval of time (measured per unit time) Probability of failure is the probability that the software will fail on the next input selected (time-independent measure) These two measures can be easily related if you know the frequency with which inputs are executed per unit of time http://www.cartoonstock.com/newscartoons/cartoonists/rha/lowres/rhan322l.jpg

11. Extendibility Ease of adapting software to changes in specification Seems like an internal, but when the customer has to wait 6 months for an update, this becomes external Simplify designs, Decentralize the operations (data hiding, etc) http://t3.gstatic.com/images?q=tbn:ANd9GcS21oD- GtgyGDV38wxWan3dOFC_2jtrmiT_LUulLgp1ZaDJSU0ybA

12. Evolvability Tends to decrease with each release The lifetime of a system is thus limited The opposite of “brittleness” Fight brittleness by refactoring: i.e., changing the internal design to improve evolvability. http://www.google.com/imgres?q=evolvability&um=1&hl=en&biw=524&bih=711&tbm=isch&tbnid=Opv 0byTYL23EQM:&imgrefurl=http://blogs.discovermagazine.com/loom/2011/03/21/evolvability-my-story- in-todays-ny-times/&docid=Gja_CXod2gYEJM&w=600&h=468&ei=WfFbTtGSHO- rsAK4l5zHDA&zoom=1&iact=rc&dur=351&page=1&tbnh=126&tbnw=169&start=0&ndsp=12&ved=1t:4 29,r:1,s:0&tx=84&ty=74

13. Compatibility/Portability Ease of combining software with other systems Able to run on different hardware Examples –Is a plotting package compatible with a word processor? –Can our system be ported to the Mac? http://t2.gstatic.com/images?q=tbn:ANd9GcSiSlnFjejMo7GBh6JSR6GFgx-gB0-2UY-gHFXjfa2Z5uDPjCg35A

14. Efficiency Software places as few demands on resources as possible –Hard: real time systems –Soft: is it usable? http://t0.gstatic.com/images?q=tbn:ANd9GcS-NM-t4LoBbjRgRuFU0U1FEOaz6iUsL8ZFnRENOzm9cryT1ZcJXw

15. Efficiency Say you buy a new computer. You could handle N cases before and the new machine is twice as fast. How many cases can you handle?

16. Efficiency Say you buy a new computer. You could handle N cases before and the new machine is twice as fast. How many cases can you handle? Depends on the algorithm: –linear: 2N –N 2 : 41% more –2 N: Just 1 more

17. Ease of use What does this mean? http://spotfireblog.tibco.com/wp-content/uploads/ease-of-use-BI-software1-300x225.jpg

18. Ease of use What does this mean? –How fast an average user can learn to use it? (installation, operation, monitoring). –How much does the system help the user? How do you measure it? –?

19. Measuring ease of use Non-trivial issue Ease of use contributed to 3 Mile Island Nuclear Power Station failure Advice: Help the user identify problems and perform tasks

20. Functionality The range of things the system can do. How much is enough? It fights against all the others. creeping featurism. http://t3.gstatic.com/images?q=tbn:ANd9GcSLEwneb_VNFR- W4BecK59zQCO7Xqez2MM_zXFv7X6o8fJW8WQIbzyvmwQ

21. Timeliness Can it be delivered when needed? http://t0.gstatic.com/images?q=tbn:ANd9GcS6lezevvLfIaQV3 DvN8boa1oyjWyFZlITx9ss45a-V2FQqwE2p0w

22. Verifiability Can the system be verified? –Is it right? –How do you know? http://t3.gstatic.com/images?q=tbn:ANd9GcRNA_6F366Kzza y4oVW6RnjXJk47XXtgjSkQ5-3h7fOs0FAZhbg

23. Integrity Can it protect itself from outsiders? http://t1.gstatic.com/images?q=tbn:ANd9GcRPlFftJyopUVH7oYBDea- iBSVqYogVQNm1zA2Q6V9jrlvYAWnWTw

24. Maintainability Can we modify it? –60% of cost is here –corrective: bugs, 20% –adaptive: environment change 20% –perfective: improve functionality 50% http://t1.gstatic.com/images?q=tbn:ANd9GcTI-pD6HmkGldc7zVIoG1Sd4U- _uXrmCF2NMfwPAsfqIcLFbIhKtQ

25. Economy Is it affordable? Can we buy or develop it? Can we maintain it? –Programmer staff? –Licenses? –Hardware? http://t2.gstatic.com/images?q=tbn:ANd9GcTGBDsnuYcdqScCB-Vci0- sOlVAaF79BVxwmxYUDoAAnUSEb7TX

26. Reusability The ability of software elements to be used in different software systems. –Should be faster, more reliable. –It isn’t always –Seems to be more internal than external Consider the construction of a chemical plant. –We start with standard parts and assemble them. –Consider hardware: assemble standard parts. –Consider software? http://t3.gstatic.com/images?q=tbn:ANd9GcQF5q8ajvmuOk1lVLehOlrhwVaa7g1chxs8yIsOOt3xCl0AIy5W

27. Tradeoffs Integrity vs ease of use Economy vs functionality Efficiency vs portability Timeliness vs extendibility Correctness: never a good tradeoff Tradeoffs change with different applications –Information systems, real time systems, distributed systems, embedded systems

28. Process Improvement Challenges: –Software development is evolutionary and experimental. –Software development is not production. –The technologies of the discipline are human based. –There is a lack of models that allow us to reason about the process and the product. –All software is not the same: process is a variable, goals are variable, content varies.

29. Initial Ad hoc Little formalization Tools informally applied to process Repeatable Achieved a stable process with a repeatable level of statistical control Defined Achieved foundation for major and continuing progress Managed Substantial quality improvements Comprehensive process measurements Optimizing Major quality and quantity improvements Basic management control Process definition Process management Process control Software Engineering Institute Carnegie Mellon Capability Maturity Model http://photos3.fotosearch.com/bthumb/CSP/CSP509/k5099163.jpg

30. CMM Maturity Level 1: Initial Characteristics No sound SE management principles in place Ad hoc practices May be successful because of competent manager and team Activities are not preplanned, but response to crisis Unpredictable process Cannot predict time and cost of development To get to next level Initiate rigorous project management, management oversight, and quality assurance

31. CMM Maturity Level 2: Repeatable Characteristics Basic SE management practices in place Planning and management are based on experience with similar products (repeatable) Track costs and schedules Identify problems as arise and take immediate corrective action Key practices: quality assurance, CM, project planning To get to next level Establish a process group Establish a software development process architecture Introduce software engineering methods and technologies

32. CMM Maturity Level 3: Defined Characteristics Process for development fully documented Reviews used to achieve software quality Introduce CASE Tools To get to next level Establish a basic set of process management to identify the quality and cost parameters Establish a process database Gather and maintain process data Access relative quality of each product and inform management

33. CMM Maturity Level 4: Managed Characteristics Organization sets quality and productivity goals for each project Continually measure Statistical quality control in place To get to next level Support automatic gathering of process data Use data to analyze and modify the process

34. CMM Maturity Level 5: Optimizing Characteristics Statistical quality and process control techniques are used and guide the organization Process has positive feedback loop To maintain level Continue improvement and optimization of the process