Software Engineering Best Practices Practical things we can

About IMS Health In Canada from 1960 n Offices in over 100 countries (HQ in US) n Canada’s leading supplier of health information n – – – Pharmaceutical consumption rates/patterns Prescription estimates Disease & treatment patterns d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 2

About me BSc, MSc Mc. Gill (Physics) n 16+ years in software industry n Held positions as software architect, software engineer, project manager n Matrox, Clinidata, IMS Health n In charge of development standards & methodology at IMS Health n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 3

Agenda Introduction n Caveats n Best practices n Where to get more information n

Introduction What is Software Engineering? n What is a Best Practice (BP)? n How

What is Software Engineering? n “The intelligent application of proven principles, techniques, languages, and tools to the cost-effective creation and maintenance of software that satisfies users’ needs. ” [Dav 95] d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 6

What is a Best Practice (BP)? n “A principle, technique, or rule about Software Engineering that is applicable regardless of the development methodology, language, or application domain. ” [Dav 95] d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 7

How these BPs are chosen They’re proven in the field n Personal experience n

Caveats List is not exhaustive n Not everything has to be followed n Not everything works all the time n Not every BP is compatible with each other n Not necessarily for project managers or leads only n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 10

Best Practices General BPs n BPs for Construction n BPs for Test n BPs

Best Practices General BPs n BPs for Construction n BPs for Testing n BPs

Quality First Users won’t tolerate product of poor quality, no matter how quality is defined n Quality cannot be “retrofitted” n It’s better to have poor efficiency than poor reliability n High quality = low productivity n Most every BP ultimately traces to ensuring Quality in software products n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 14

Triage “A system used to allocate a scarce commodity, such as food, only to those capable of deriving the greatest benefit from it. ” [You 97] n Major application is in requirements management n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 15

Triage (cont’d) Classify requirements using Mo. SCo. W rule: “Must have”, “Should have”, “Could have”, “Wish to have” [Sta 97] n Focus only on “Must have” requirements first n Must actively & continuously manage this with all stakeholders (Users, development, QA, Marketing, management) n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 16

Top 10 List of 10 most serious risks to project n Include status, context, possible resolutions n Update every week n Raises awareness of project risks n More timely solutions possible n Improves visibility of progress n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 17

Configuration management Use CM tool (Source. Safe, etc. ) n Archive all versions of all intermediate Artefacts (specifications, code, testplans, user manuals, etc. ) n Assign name/version number n Have a baseline as early as possible n Control ALL changes to baseline n Track every change n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 18

Defect tracking Log of all defects found in all stages of life cycle n Include also suggestions n Must have version number from CM tool n Easier post-mortem analysis n Easier metrics gathering n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 19

Have standards Promotes discipline n Ensures uniformity of artefacts n Use of common language n Easier maintenance n Availability of tools n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 20

Don’t follow standards Good methodology is one that makes sense to the company n Don’t have to follow every single step n Adopting new methodology often accompanied by huge productivity drop n Fix fundamental problems first n Be careful when following trends n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 21

Miniature milestones Milestones that are achievable in 1 -2 days n Good for crisis or project recovery n Good for team motivation n Increased status visibility n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 22

Avoid Waterfall methodology n n n n Trying to freeze requirements, design, … Trying to plan details from beginning to end Not suitable for new, unfamiliar projects Not adaptable to changes Pushes risks to tail-end of project Testing way too late Integrating way too late * d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 23

Use Iterative methodology Project goes through many iterations n Each iteration includes usual 4 stages n Each iteration refines requirements, design, build, tests, … n Each iteration adds more and more features n Users see value with each iteration n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 24

Iteration d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health

Iterative methodology Embraces changes, not resists them n Emphasis on working software, not documents n Creates working system as early as possible n Continuous testing, continuous integration n Risk driven: greatest risks handled first n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 26

Release early Define & create release process and actual release deliverables as early in project life-cycle as possible (iterations) n Minimizes integration problems n Avoids “end of build” rush n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 27

Framework group A group to define company-wide common architecture, development tools, & methodology n Promotes reuse of common components n Decreases risks n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 28

Do a post-mortem At project end, key players analyze every problem that occurred in project n Goal is to document, analyze, and learn from mistakes n Metrics can also be gathered n Usually takes 3 -5 days n Great benefits to future projects n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 29

Best Practices General BPs n BPs for Build n BPs for Testing n BPs

Captain’s Log Keep a log of what was done n Can be written or electronic n Especially important for build n Easier recall of what or why n Easier post-mortem analysis n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 31

Daily build System completely rebuild every day (usually overnight) n Treat it as heartbeat or synch pulse of project [Cus 95] n Fixing broken build is given top priority n Minimizes integration risk n Easier defect diagnosis n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 32

Daily smoke tests A set of tests that exercises major functional areas of system n Should be automated n Run it after each Daily Build n Update the set as more functionality are added to each iteration n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 33

Fix bugs as soon as found Don’t wait “until later”; “later” never comes n Fix while code is still fresh in memory n No new features until bugs are fixed n Greatly increases quality of product n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 34

Single-step through every line of code Step through code in debugger n Step through EVERY SINGLE line of code that was added, changed, moved n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 36

Branch, path, and other things Test every branch n Test every path n d.

Do Inspections Catches high percentage of bugs n Promotes good coding practices n Promotes use of coding standards n Great for people new to project or code n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 38

Create a glossary & index Every document should have glossary & index n Especially important for User documents (requirements specs, user manuals) n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 40

Be boring n Which is better? – “There are three types of special commands. Regular commands come in four varieties. ” – “There are three types of special commands. There are four types of regular commands. ” [Dav 95] d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 41

Speak the reader’s language Don’t put technical terms in documents destined for Users n

Where to get more information S. Mc. Connell, Rapid development. Microsoft Press, Redmond, Wash. , 1996. n A. M. Davis, 201 principles of software development. Mc. Graw Hill, 1995. n Bibliography lists 31 other books, papers, and web sites. n d. Loo 2002 -Mar-08 Software Engineering Best Practices - (c) 2002 IMS Health 44