Software Engineering A practitioners approach Roger S Pressman

Software Engineering A practitioner’s approach (Roger S. Pressman) 12/20/2021 (c) Ian Davis 1

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 12/20/2021 (c) Ian Davis 2

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 12/20/2021 (c) Ian Davis 3

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 12/20/2021 (c) Ian Davis 4

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. 12/20/2021 (c) Ian Davis 5

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 1 x overhead – during development 1. 5 -6 x overhead – after release 60 -100 x overhead • The programmer knows best. 12/20/2021 (c) Ian Davis 6

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. 12/20/2021 (c) Ian Davis 7

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) 12/20/2021 (c) Ian Davis 8

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

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

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

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 12/20/2021 (c) Ian Davis 12

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. 12/20/2021 (c) Ian Davis 13

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% 12/20/2021 (c) Ian Davis 14

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. 12/20/2021 (c) Ian Davis 15

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 12/20/2021 (c) Ian Davis 16

The governments nightmare • Of $6. 8 M for 9 federal projects studied – 47% ($3. 2 M) delivered but never used – 29% ($2. 0 M) paid for but not delivered – 19% ($1. 3 M) abandoned or reworked – 3% ($0. 2 M) used after modification – 2% ($0. 1 M) used as delivered – (U. S. Government Accounting Office 1979) 12/20/2021 (c) Ian Davis 17

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. 12/20/2021 (c) Ian Davis 18

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 12/20/2021 (c) Ian Davis 19

Budgeting • • Work out costs of salaries. Allow 10% 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! 12/20/2021 (c) Ian Davis 20

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. 12/20/2021 (c) Ian Davis 21

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. 12/20/2021 (c) Ian Davis 22

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 12/20/2021 (c) Ian Davis 23

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) 12/20/2021 (c) Ian Davis 24

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. 12/20/2021 (c) Ian Davis 25

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. 12/20/2021 (c) Ian Davis 26

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. 12/20/2021 (c) Ian Davis 27

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. 12/20/2021 (c) Ian Davis 28

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 12/20/2021 (c) Ian Davis 29

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 12/20/2021 (c) Ian Davis 30

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 V 9 No 5 Oct 1984 pg 8) 12/20/2021 (c) Ian Davis 31

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 12/20/2021 (c) Ian Davis 32

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

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. 12/20/2021 (c) Ian Davis 34

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. 12/20/2021 (c) Ian Davis 35

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. 12/20/2021 (c) Ian Davis 36

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. 12/20/2021 (c) Ian Davis 37

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. 12/20/2021 (c) Ian Davis 38

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. 12/20/2021 (c) Ian Davis 39

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. 12/20/2021 (c) Ian Davis 40

4 th 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 4 GL tools. 12/20/2021 (c) Ian Davis 41

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. 12/20/2021 (c) Ian Davis 42