Meetings Good Practices

1. Meetings Good Practices • Slides already online • Printed material to be distributed now • You are responsible for material in those slides and printed material • [HINT] Quiz over the material next class!!!

2. Team Notebooks • One for each team: Graded. • There is no predefined format for the notebook. • Meeting records • Email • Individual contributions • Drafts • Task assignments • Team processing documentation • to protect you: describes your contribution to the team.

3. Software Qualities

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

5. 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

6. Software Qualities: • Two types • External: • Internal: • Two categories • Product: • Process:

7. 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

8. 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.

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

10. 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

11. 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

12. 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

13. 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

14. 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=Opv0byTYL23EQM:&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:429,r:1,s:0&tx=84&ty=74

15. 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

16. 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

17. 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?

18. 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 • N2: 41% more • 2N: Just 1 more

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

20. 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?  • ?     

21. 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      

22. 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

23. Timeliness • Can it be delivered when needed? http://t0.gstatic.com/images?q=tbn:ANd9GcS6lezevvLfIaQV3DvN8boa1oyjWyFZlITx9ss45a-V2FQqwE2p0w

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

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

26. 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

27. 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

28. 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

29. 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

30. 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.

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

32. 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 CMM Maturity Level 1: Initial

33. 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 CMM Maturity Level 2: Repeatable

34. 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 CMM Maturity Level 3: Defined

35. 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 CMM Maturity Level 4: Managed

36. 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 CMM Maturity Level 5: Optimizing