Software Engineering A practitioner’s approach (Roger S. Pressman)

1. Software EngineeringA practitioner’s approach(Roger S. Pressman) (c) Ian Davis

2. Software products • System software • Complex deterministic algorithms • Application software • Focus on user interfaces and reports • Dependent on underlying tools/forms etc. • Real-time software • Low level code and interfaces • Time critical considerations (c) Ian Davis

3. Software products cont. • Engineering, scientific, math software • Number crunching algorithms • Must be accurate and correct • Highly reusable • Embedded control software • Must operate in fixed memory space • Must be robust • May have to operate in real time (c) Ian Davis

4. Software products cont. • Personal computing software • Focus on ease of to use • Configurable to needs, menus, options etc. • Must integrate results from different products. • Dependent on foundational classes. • Artificial intelligence • Ad-hoc approaches to improving behaviour • Seeking probable good behaviour (c) Ian Davis

5. Management myths • Follow corporate rules and the software will write itself. • Buy the latest hardware and you will get the best development environment. • Don’t worry about schedules. You can hire more people, if they prove necessary. • The employees will tell you when things are going wrong. (c) Ian Davis

6. Customer myths • A general outline is all that is needed to start programming. Details can come later. • Changes can be easily accommodated because software is inherently changeable. • Change during definition 1x overhead • during development 1.5-6x overhead • after release 60-100x overhead • The programmer knows best. (c) Ian Davis

7. Practitioners myths • The job is to get the program to work. • The only deliverable is a working program. • Quality is measured by the finished product. • Schedules are unimportant. • One can always reduce the end functionality. • No one expects software to be ready on schedule. (c) Ian Davis

8. Software lifetime • 1 to 3 years to develop • 5 to 15 years in use. • Development maintenance ratios • 40/60,30/70,10/90 • (From Software Engineering Concepts) (c) Ian Davis

9. Software development ratios • Planning - 1/3 • Implement - 1/6 • Component test - 1/4 • Systems test - 1/4 • (Fred Brooks - Mythical man month) (c) Ian Davis

10. Lifetime development ratios • Analyze & design - 16% • Implement - 8% • Test - 16% -- Total 40% • Adapt - 12% • Enhance - 36% • Fix - 12% -- Other 60% • (From Software Engineering Concepts) (c) Ian Davis

11. Software sizing • Trivial: 1 programmer 1-4wks 500 lines • Small: 1 programmer 1-6mos. 1K-2K • Medium: 2-5 people 1-2yrs. 5K-50K • Large: 5-20 people 2-3yrs. 50K-100K • V. Large:100-1000 4-5yrs. 1M • Huge: 2000-5000 5-10yrs. 1M-10M (c) Ian Davis

12. Productivity • Trivial: 25-100 lines per day • Small: 8-100 lines per day • Medium: 2.5-100 lines per day • Large: 4-50 lines per day • V. Large:1-12.5 lines per day • Huge: 0.1-5 lines per day (c) Ian Davis

13. Differences in productivity • A good programmer can be 10 times more productive than a bad one. • The parable of the two programmers. • One did things by the book, did a poor job with excessive staff, and got promoted. • The other spent time thinking, wrote all the code, made it look too easy, and was fired. (c) Ian Davis

14. A programmers day • Writing programs - 13% • Reading programs and manuals - 16% • Job communication, meetings - 32% • Personal (phone calls, time off) - 13% • Miscellaneous (coffee, travel, chats) - 15% • Training - 6% • Reading and responding to mail - 5% (c) Ian Davis

15. A programmers problem • 39% of time unavailable for projects. • 50% of remaining time spent understanding task to be performed. • Doing well if can devote 1/3 of time to being productive. • Adding more programmers to a late project makes it later - Brooks law. (c) Ian Davis

16. The underlying trend • Under ideal circumstances: • effort  lines of code ^ 1.5 • Jobs take twice as long as expected • More than half one’s time is wasted (c) Ian Davis

17. The governments nightmare • Of $6.8M for 9 federal projects studied • 47% ($3.2M) delivered but never used • 29% ($2.0M) paid for but not delivered • 19% ($1.3M) abandoned or reworked • 3% ($0.2M) used after modification • 2% ($0.1M) used as delivered • (U.S. Government Accounting Office 1979) (c) Ian Davis

18. Managers responsibilities • Hire the best people for the job • Divide project into discrete activities • Accurately estimate activity costs • Monitor progress very closely • Avoid long delays between milestones • Stay on target • How does a project get to be a year late? • One day at a time. (c) Ian Davis

19. Managers responsibility cont. • Carefully document progress • It is important to recognize achievements • Identify outstanding problem areas • It is important to resolve problems promptly • Providing leadership and drive is vital • Blame and failure are very poor motivators • Success is a very strong motivator • Nothing succeeds like success (c) Ian Davis

20. Budgeting • Work out costs of salaries. • Allow10% for other costs. • Salaries dominate the entire cost of a project • Things that improve productivity are cheap at just about any price. • Happy people are way more productive! (c) Ian Davis

21. Management styles • Ad hoc • Individual effort, little leadership or direction • Repeatable • Costs, schedules, functionality tracked • Defined • Development activities documented, code/rules standardized and understood by organization. • Peer review, training, meetings etc. (c) Ian Davis

22. Management styles cont. • Managed • Development process constantly monitored. • Feedback from monitoring assists development. • Concern with quality assurance • Optimized • Feedback on usefulness of approaches used to improve management and engineering process. • Management learns from it’s own mistakes. (c) Ian Davis

23. Democratic decentralized team • Difficult project (need innovation from all) • Total project size small (limited interactions) • Long team lifetime (people trust each other) • Modularity low (limit shared activities) • High reliability (team has self respect) • Lax delivery dates (largely unmanaged) • High sociability (team works well as a group) • May struggle with orderly performance (c) Ian Davis

24. Controlled decentralized team • Easier project (some responsibilities delegated) • Project size large (managed interactions) • Short team lifetime (some people expendable) • Modularity high (many divided activities) • High reliability (team respects self/leadership) • Lax delivery dates (somewhat unmanaged) • Low sociability(members have distinct roles) (c) Ian Davis

25. Controlled centralized team • Easier project (all responsibilities delegated) • Project size large (managed interactions) • Short team lifetime (people expendable) • Modularity high (divided activities) • Low reliability (team following orders) • Strict delivery dates (failure unacceptable) • Low sociability (members do not interact) • Unlikely to be innovative. (c) Ian Davis

26. A key management issue • Do you measured accomplishments or the hours spent working towards a goal? • If you measure hours, people will tend to do the minimum that they are paid to do. • Trusted/skilled individuals should be given freedom to work as and when they choose. • Good programmers work for pleasure first, and personal gain second. (c) Ian Davis

27. Time sheets • Time sheets serve as a useful aid. • Facilitates comparison with budgeted times. • Highlights time consuming problems/issues. • Preserves record of overtime worked. • Justifies funds absorbed by salaries. • Identifies delays due to sickness, etc. • Should be an viewed as aid - not a weapon. • Collection should be cooperative exercise. (c) Ian Davis

28. A jelled team • A group of people so strongly knit that the whole is greater than the parts.. • Once a team begins to jell, the probability of success goes way up. • The team genuinely wants to succeed. • The team has motivation, and momentum. (c) Ian Davis

29. Coordination and communication • Formal, impersonal • Paperwork, and forms • Status review meetings • Code inspections • Informal, interpersonal • Short but frequent informal chats • Regular group meetings • Concern, assistance and training (c) Ian Davis

30. Electronic communication • Interpersonal network • Correspondence via e-mail • Discussion via news groups • Online documentation • Executable demonstrations on web • Project planning on web • Helpful comments directly in code • Change history in code/system (c) Ian Davis

31. Two observations on large software projects • The best way to deal with a large software project is not to let it become large in the first place. • The main function of design reviews, structured walkthroughs, and like design techniques is to buy time. • (Dick Dunn SEN V9 No 5 Oct 1984 pg 8) (c) Ian Davis

32. Design observation cont. • Provides visible “recognized” activities. • Produce “tangible” documents and results. • People who are thinking can “look busy” while actually being busy thinking. • Design steps can become goals in selves. • Risk that project will be overly influenced by people who are good at generating paper; instead of most technically qualified people (c) Ian Davis

33. Scheduling strategies • Linear sequential model • Prototyping • Incremental model • Spiral model • Component assembly model • Concurrent model • Formal methods • CASE tools and 4GL’s. (c) Ian Davis

34. Linear sequential model • Uses conventional engineering cycle. • Even active supporters question its efficacy. • Changes cause confusion as team proceeds. • Uncertainty natural at start of projects. • Customer must have great faith/patience. • Major blunder likely to be detected late. • Time waiting for steps to be completed can exceed time spent on productive work. (c) Ian Davis

35. Prototyping model • Overall objectives followed by quick design. • Focus on what will be visible as input/output. • Leads to better detailed requirements faster. • Approach liked by developers and customers. • Risk that customer will like what see too much! • Risk that developer may settle for shoddy work. (c) Ian Davis

36. Incremental model • Stagger software development start points. • Cross between linear and prototype model. • Core product started early. • Optional/advanced features begun later. • Less risk of systemic delays. • Critical core problems identified earlier. (c) Ian Davis

37. Spiral model • Incremental model. • Anticipation of many versions of software. • Prototyping may be employed at any stage. • Difficult to control evolutionary approach. • Demands considerable risk assessment. • Early versions of software may be painful. (c) Ian Davis

38. Component assembly model • Basically similar to the spiral model. • Attempts to use existing components. • Attempts to enlarge available components. • Definitely of value when components exist which have the necessary functionality. • Currently most useful for user interfaces. • Skews code towards existing components. (c) Ian Davis

39. Concurrent development model • Let time and need determine activities. • Activity driven by user needs, management decisions, and review results. • Responsibilities more readily driven by capabilities. • Treats software development as a network of evolving activities. • Very hard to manage. (c) Ian Davis

40. Formal methods model • Mathematical specifications for software. • Early proof and verification of design. • Detects ambiguity, incompleteness, and inconsistency much better. • Very time consuming and expensive. • Extensive esoteric math training needed. • Hard to communicate method to customer. (c) Ian Davis

41. 4th Generation techniques • Core software auto magically generated • Dependence on high level instruction • Well suited to small scale projects • Development often assisted by wizards • Auto magically generated code unclear. • Very hard to maintain, modify or rework. • Easy to confuse/break 4GL tools. (c) Ian Davis

42. The development process • If the process is weak the product will suffer. • Obsessive over-reliance on process is dangerous. • Duality between process and product. • Structured code .v. flowcharts • Data encapsulation .v. object modeling • expenditures .v. budgeting • progress .v. project plans • Product important - process only means to end. (c) Ian Davis