Software Engineering A practitioners approach Roger S Pressman

Software Engineering A practitioner’s approach (Roger S. Pressman) Winter 2016 (c) Ian Davis 1

The Parable of the Two Programmers • http: //www. csd. uwo. ca/~magi/personal/humou r/Computer_Audience/The%20 Parable%20 of %20 the%20 Two%20 Programmers. html or • cs. uwaterloo. ca/~ijdavis/teaching/2016 winter/ cs 446/parable. pdf Winter 2016 (c) Ian Davis 2

Version Control Systems • • Cheap backup Quick restore Must also backup!!! Tools – GIT – SVN – Mercurial Winter 2016 (c) Ian Davis 3

Good Judgement • Good judgement – Learned by experience • Experience – Learned consequence of bad judgements – Experience is a dear teacher • A fool will learn from no other • Second Systems Effect – Do not be over confident – Always focus on what can go wrong Winter 2016 (c) Ian Davis 4

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 Winter 2016 (c) Ian Davis 5

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 Winter 2016 (c) Ian Davis 6

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 Winter 2016 (c) Ian Davis 7

Management myths • Follow corporate rules and the software will write itself • Throwing money at a problem will solve it • Don’t worry about schedules. You can hire more people, if they prove necessary • The employees will tell you when things are going wrong Winter 2016 (c) Ian Davis 8

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. Winter 2016 (c) Ian Davis 9

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. Winter 2016 (c) Ian Davis 10

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) Winter 2016 (c) Ian Davis 11

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

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

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 Winter 2016 (c) Ian Davis 14

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 Winter 2016 (c) Ian Davis 15

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. Winter 2016 (c) Ian Davis 16

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% Facebook ? ? ? Winter 2016 (c) Ian Davis 17

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. Winter 2016 (c) Ian Davis 18

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 Winter 2016 (c) Ian Davis 19

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) Winter 2016 (c) Ian Davis 20

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. Winter 2016 (c) Ian Davis 21

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 Winter 2016 (c) Ian Davis 22

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! – So it is worth the cost of keeping people happy Winter 2016 (c) Ian Davis 23

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. Winter 2016 (c) Ian Davis 24

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. Winter 2016 (c) Ian Davis 25

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 Winter 2016 (c) Ian Davis 26

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) Winter 2016 (c) Ian Davis 27

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. Winter 2016 (c) Ian Davis 28

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. Winter 2016 (c) Ian Davis 29

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. Winter 2016 (c) Ian Davis 30

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. Winter 2016 (c) Ian Davis 31

The team stages • • • Forming Storming Norming Conforming Performing -- • Destructing? ? Winter 2016 (c) Ian Davis 32

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 Winter 2016 (c) Ian Davis 33

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 Winter 2016 (c) Ian Davis 34

The Acid Test • Don’t impose ideas on a team which – The team does not think will assist • Generally speaking – We are not bad at knowing what will work – And sensing what is a waste of time – We are bad at getting down to work Winter 2016 (c) Ian Davis 35

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) Winter 2016 (c) Ian Davis 36

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 Winter 2016 (c) Ian Davis 37

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

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. Winter 2016 (c) Ian Davis 39

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. Winter 2016 (c) Ian Davis 40

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. Winter 2016 (c) Ian Davis 41

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. Winter 2016 (c) Ian Davis 42

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. Winter 2016 (c) Ian Davis 43

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. Winter 2016 (c) Ian Davis 44

SCRUM • Product owner – Provides incremental requirements • Scrum Manager – Coordinates – Monitors progress (Amount left / Time taken) – Resolves road blocks • Team – Develop in sprints (one small goal at a time) – Division of responsibility determined by need – Self organising (regular meetings/review) Winter 2016 (c) Ian Davis 45

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. Winter 2016 (c) Ian Davis 46

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. Winter 2016 (c) Ian Davis 47

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 Winter 2016 (c) Ian Davis 48