1 / 42

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

Software Engineering A practitioner’s approach (Roger S. Pressman). 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

gerald
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related