Software Architecture, Process and Management Tools for Software Projects

Transcription

1 Software Architecture, Process and Management Tools for Software Projects Allan Clark School of Informatics University of Edinburgh Semester Two

2 Previous Lecture s Estimation Exercise Recall from the previous lecture I asked you all to estimate how long it would take to complete a given task I asked how long you estimate a developer would take, stating that the developer needn t be yourself I meant a suitable developer, in other words if you didn t think you personally could complete the task because you lack certain skills you could think of a more appropriate developer But I didn t say this

3 Previous Lecture s Estimation Exercise To remind you all of the task in question: Write a Java to HTML translator It needn t do any error detection/correction But nor need it translate invalid JAVA You cannot use an existing one, but you can use libraries for parsing text or even parsing Java itself.

4 Turan If you have very low estimate, one way of testing/showing your estimate is to have a go at some code Linus Torvalds: Talk is cheap, show me the code

5 Turan If you have very low estimate, one way of testing/showing your estimate is to have a go at some code Linus Torvalds: Talk is cheap, show me the code However, Turan obviously thought this was a bit easy so he decided to do this using only his right hand He didn t say whether he was right-handed or not He also chose to do this in a single-file Obviously that gave him a huge advantage and surely more than made up for using a single hand Although I do not yet have the data to back up this claim

6 Turan 6:15 pm Started working on the project. I decided to implement it in JavaScript so that it would be easy to see HTML results. 6:18 pm I already have a simple UI, textarea for Java source input, button To HTML and output area. Time to get these components working! I thought it will make sense to start with getting Java keywords (public, final, catch, while) highlighted. I googled java keywords, got their list from Oracle web site. First idea was to tokenize everything using space character as a separator. Then go through the tokens and if any of them match just surround them with. 6:31 pm After few fails, keywords are being successfully processed now.

7 Turan 6:45 pm Next step: Strings. As we know that Java code will always be valid, it could be easily implemented with regex. 6:50 pm Done! got keywords and strings highlighted. Next: detect annotations, classes, constants (mostly using Java code style convention). 7:20 pm Great! Everything seems working! Testing Time! 7:31 pm Comments.. are really tricky.. /* foo / int i; / bar */ 7:31-8:20 pm Some RegEx magic and comments are also working! 8:20-8:45 pm More testing minor fixes

8 Turan These time comments available at: You can try out his code here: A single HTML file with Javascript and CSS injected NTS (not too shabby) As an aside, both those urls (and most others) are valid Java 1 public static void main(string[] args) 2 { 3 System.out.println ("An inserted url"); System.out.println ("compiles Ok!"); 6 } Line comments on a line of their own were failing for me

9 Some Java Code 1 public boolean[] sieveoferatosthenes(int max){ 2 3 boolean[] primecandidates = new boolean[max]; //defaults to false 4 for(int i=2; i<max; i++ ){primecandidates[i]=true;} 5 6 for(int i=2; i<math.sqrt(max);i++){ 7 if(primecandidates[i] == true){ 8 //all multiples of i*i, except i, are not primecandidates 9 for(int j = i + i; j<max; j=j+i){ 10 primecandidates[j]=false; 11 } 12 } } 15 return primecandidates; 16 }

10 Some Java Code 1 public boolean[] sieveoferatosthenes(int max){ 2 3 boolean[] primecandidates = new boolean[max]; //defaults to false 4 for(int i=2; i<max; i++ ){primecandidates[i]=true;} 5 6 for(int i=2; i<math.sqrt(max);i++){ 7 if(primecandidates[i] == true){ 8 //all multiples of i*i, except i, are not primecandidates 9 for(int j = i + i; j<max; j=j+i){ 10 primecandidates[j]=false; 11 } 12 } } 15 return primecandidates; 16 }

11 1 Some Similar Java Code 2 public boolean[]sieveoferatosthenes(int max){boolean[] primecandidates 3 = new boolean[max]; /*defaults to false*/ for(int i=2; i<max; i++ 4 ){primecandidates[i]=true;} for(int i=2; i<math.sqrt(max);i++){ 5 if(primecandidates[i] == true){ /*all multiples of i*i, except i, 6 are not primecandidates*/ for(int j = i + i; j<max; j=j+i){ 7 primecandidates[j]=false;}}} return primecandidates;}

12 1 Perfectly Valid Formatted Output 2 public boolean[]sieveoferatosthenes(int max){boolean[] primecandidates 3 = new boolean[max]; /*defaults to false*/ for(int i=2; i<max; i++ 4 ){primecandidates[i]=true;} for(int i=2; i<math.sqrt(max);i++){ 5 if(primecandidates[i] == true){ /*all multiples of i*i, except i, 6 are not primecandidates*/ for(int j = i + i; j<max; j=j+i){ 7 primecandidates[j]=false;}}} return primecandidates;}

13 Alternative Perfectly Valid Formatted Output 1 public boolean[] sieveoferatosthenes(int max){ 2 3 boolean[] primecandidates = new boolean[max]; //defaults to false 4 for(int i=2; i<max; i++ ){primecandidates[i]=true;} 5 6 for(int i=2; i<math.sqrt(max);i++){ 7 if(primecandidates[i] == true){ 8 //all multiples of i*i, except i, are not primecandidates 9 for(int j = i + i; j<max; j=j+i){ 10 primecandidates[j]=false; 11 } 12 } } 15 return primecandidates; 16 }

14 Did the experiment work? Mostly yes: I had feared that the lowest estimate would be 3 days and the highest 5 days This would not have made my point at all In the end, I didn t have much to fear the highest and lowest estimates were: 8 hours 1 year Even if we take 1 year to mean it is still an estimate that is 48 5 = 240 times the lowest estimate Neither of these are bad estimates

15 Did the experiment work? Estimates vary wildly These are not necessarily caused by either estimator being poor at estimating how long a given task will take (though most of us are indeed poor at that) It is not necessarily caused by a difference in the competence/suitability/required knowledge of the two estimators (though this can be a large factor) Often it is caused by the two estimators simply thinking of two different sets of requirements One may be thinking of production quality code One may be thinking of a rough first attempt that allows other parts of the project dependent upon it to start Almost any estimate could be made correct by decreasing/increasing the scope/quality/function/performance

16 Today s Topic Let s get back on talk about tools for software projects Recall the rabbit hutch Remind me again how many of you think you could build this or something similar?

17 Do you own one of these?

18 Do you own one of these? and one of these?

19 Automating Drudgery Most of the techniques we ll talk about can benefit from automated tools, and some would be totally impractical without them e.g. the continual code changes involved in Extreme Programming Discussing all relevant tools is outside of the scope of this course. We will look at a few extremely useful categories, focusing on baseline open-source packages that everyone should be using unless their organisation has something better. We primarily consider useful individual tools, not integrated project management suites, because they are more widely applicable. That isn t to say project management suites aren t useful. Here though we wish to highlight the individual components that are useful on their own merit (outside of any integrated project management suite)

20 Tool Types Version control (e.g. Git) Build control (e.g. make) Debuggers (e.g. gdb) Unit/regression testing (e.g. JUnit) Bug/issue tracking (e.g. Trac) Documentation generation (e.g. JavaDoc) Project management (e.g. MS Project) Integrated suites (e.g. RUP) Others

21 1st Step: Version Control Before starting any project (programming or otherwise!) with edits occuring over more than a couple of weeks, you should set up a version control system If you do not, you deserve every one of the many troubles that will be coming your way Version control or conguration management systems like Git, Mercurial, or Subversion track and manage changes during development and maintenance of any long-lived set of files. They tell you who changed what, when.

22 Basic Version Control Features Have separate repository holding all versions of all files Changes in local copies do not affect the repository until a commit (a.k.a. checkin) Commits merge your changes with the repository files Locking or merge mechanisms prevent or resolve collisions between users Can provide complete history of all changes, reproducing state at any time and tracking who changed what when

23 /* * 12/ 26/ 93 ( seiwald ) - allow NOTIME targets to be expanded * 01/ 04/ 94 ( seiwald ) - print all targets, bounded, when tra * 12/ 20/ 94 ( seiwald ) - NOTIME renamed NOTFILE. * 12/ 17/ 02 ( seiwald ) - new copysettings () to protect target * 01/ 03/ 03 ( seiwald ) - T_ FATE_ NEWER once again gets set wit * 01/ 14/ 03 ( seiwald ) - fix includes fix with new internal i * 04/ 04/ 03 ( seiwald ) - fix INTERNAL node binding to avoid T */

24 Managing Software Releases Any decent company will have version control already Release to the public: modified snapshot of repository Typical sequence for a release: 1. Feature freeze (only bugfixes allowed now) 2. Release candidate (could ship if bug-free) 3. Candidate sent to testing team 4. Bugs are found, patched ; new release candidate Typically there are different code branches maintained at least production and development but often feature branches as well

25 3 Generations of Version Control 1972 Single file system Locking ensures only one person at a time edits any file Nearly unusable for multiple developers Examples: RCS, SCCS, VSS ($$) 1985 Realisation: file merging works! No need for locking Just merge later Allows multiple distributed developers or just separate copies Examples: CVS, Subversion 2002 Realisation: repository merging works! Distributed Version Constrol System no need for one central repository repositories and not just files can be merged as needed Useful even for single developers to handle independent sets of changes separately Examples: Git, Mercurial, bzr, Bitkeeper ($$)

26 Which Version Control Tool To Use? Surely everyone is already using VC for your own projects, even when not required? If not, set one up today and try using it for a few weeks The de-facto standard has changed from RCS to CVS to Subversion and now to... Post-Subversion there was market fragmentation with many 3rd-generation DVCS tools, but Git and Mercurial seem to be coming out on top. github is, in some quarters, becoming a substitute for a CV Mercurial has an excellent tutorial: Others like bzr, Codeville, SVK, darcs, arch/tla, ArX, fossil and monotone seem to have less market share, but perhaps its too early to tell.

27 Integrated Version Control Businesses often use commercial version control tools such as: IBM Rational ClearCase Microsoft VSS Borland StarTeam Except for possibly Bitkeeper, the revision control portions of these systems tend to be quite outdated and much harder to use than necessary What large commercial tools do often offer is a workow that is tightly integrated into a larger process model, of which version control is only a part. Various programs also help put a pretty face on version control, such as TortoiseCVS and TortoiseSVN (integrating version control into Windows) Emacs and Eclipse (integrating version control into editing and development)

28 Git Blame $ git blame sbsi_ numeric_ devel / Template / main_ Model. c 352 c44 ( ntsorman : 03: ) # ifndef NO_ 352 c44 ( ntsorman : 03: ) # include 352 c44 ( ntsorman : 03: ) # endif 352 c44 ( ntsorman : 03: ) ( allanderek : 24: ) # include < Ma 352 c44 ( ntsorman : 03: )

29 Build Control Build control tools like make automate the process of generating an executable or compiled version of a program or other file or document from source files: UNIX> make cc -c file1.c cc -c file2.c cc -o a.out file1.o file2.o UNIX> Does everyone know how to use make/gmake or ant? Does everyone actually use them or tools like them for your own projects even when not required to do so?

30 Build Control is not Scripting Proper build control programs like make are not the same as scripting tools like Apple s Automator They don t simply replay a series of actions but instead encode a complex web of dependencies so that only the next appropriate actions are taken (based on datestamps). That is, if your build process has 4,356 steps, and it is failing on step 3,963, make will start the build process at step 3,963 each time it runs, rather than doing the first 3,962 tasks over again from the beginning. This is the main advantage of something like make over simpler scripting or build control tools.

31 Other Build Control Tools Java s ant is more portable in some sense, though it is not as widely used apart from Java projects Python/Ruby/etc have a variety of build tools For more complicated projects needing to compile across many UNIX-like systems, consider autoconf/automake These are becoming outdated I have a bit of a problem with infrequently used DSLs Integrated development environments (IDEs) like Visual Studio and Eclipse usually replace makefiles with project files but those are not as easily shareable to other systems Note that build control is not just for compiling, it s for at least: making releases generating documentation running tests automating any other complex task! Goal: don t do anything by hand more than 3 times

32 Debuggers/Profilers Debuggers allow you to: Step through code line by line Set break points Allow state to be examined or changed They are essential for C/C++, but extremely useful even for interpreted languages Many IDEs include integrated debuggers, but there are separate command-line debuggers: gdb, jdb, pdb, etc. and many graphical ones: ddd, Insight, etc Profilers tell you where the time and memory are spent in your application If you optimise without a profiler there is a 99.9% chance you are wasting your time

33 Unit/Regression Testing Unit/regression testing frameworks make testing easy to do habitually, which makes everyones life easier and is required by Extreme Programming, as well see JUnit was developed for Extreme Programming on Java, based on a Smalltalk original It has been ported to many other languages: pyunit (Python), CppUnit (C++), NUnit (.NET), etc. There are also addons such as: Coverlipse to check Java code coverage QuickCheck to generate test cases in Haskell doctest to run tests embedded in doc strings

34 Unit Tests 1... deep amoungst complex matrix operations... 2 for (int i = 0; i < something.height; i++){ 3 for (int j = 0; j < something.width; i++){ 4... complex code... 5 x = blah[j] + bleg[i]; 6 j = some_function(i); 7 z = blerger[i] + blerger[j]; 8... more complex code; 9 } 10 }

35 Bug/Issue Tracking Any software package with a decent-sized userbase will generate a lot of bug reports, complaints, and feature requests Bug/issue tracking software keeps track of all of those for you without it many fall through the cracks or end up dominating all your time and concentration. There is no standard, but Trac, GNATS, and BugZilla/ IssueTracker are widely used free tools also: Mantis, TestTrack Pro (Seapine $$) If your code is hosted at a site with an integrated configuration management package like SourceForge, github or google code it will come with bug/issue tracking.

36 Bugs vs Features Question: How do I distinguish between a bug report and a feature request?

37 Bugs vs Features Question: How do I distinguish between a bug report and a feature request? Answer: Don t In either case, the software isn t doing what your user(s) want(s) it to do: Either you think it is worthwhile and feasible to fix that state of affairs or you don t Everything is an issue, important factors are: Severity Urgency Priority Effort to fix Consequences of fixing (e.g. using more memory)

38 Document Generation No one actually writes documentation consistently, so it always gets out of sync with code similarly for comments Documentation generation software like JavaDoc (Java), NDoc (.NET), PHPDoc (PHP), and Doxygen (C++, C, Java, etc.) automatically generates documentation from your source code and comments Most of it is guaranteed to be up to date, and if developers know their comments are going to be used as-is for the reference manual then they won t consider it wasted effort to update their comments when the code changes

39 Generated Documentation Traps Even though generated documentation is often quite impressive looking, it is crucial for a human to go over it eventually to make sure it is also readable Often the result is nearly unusable because it is repetitive, lacks context, and is missing crucial transitions between sections It takes several passes between the source code comments and the generated output to make it all work ok Note that only reference manuals can be generated: user manuals must be written from scratch with the user in mind, and should never simply mirror the structure of the code.

40 Project Management Keeping track of all the sub-tasks in a large project, such as: who they are assigned to in what order they have to be done how long each will take is a pain (at best) Project management software like Microsoft Project ($$) helps with this Main feature: automatic Gannt charts and PERT charts Basecamp ($$) is a bit more ambitious: adding distributed time tracking Also many free programs, such as: Planner, GanttProject, KPlato, etc

41 Integrated Suites For open-source projects, integrated suites like GitHub and Google Code Hosting are freely available that do all the above and add (at least): Document release management Binary le release management Web hosting Discussion forums/ lists Proprietary workflow/process management tools like the IBM Rational Unied Process suite and Cruise Control (builds, runs tests, publishes results) are even more ambitious Integrated packages are great if you need most of their features; separate tools can be used at any time. Fogcreek offers several products such as kiln which are something of a half-way house between fully integrated and separate tools (in this case source code control and code review)

42 The Joel Test Is a substitute for a 6 month long approach for determining how good your software team is 12 yes/no questions No, difficult measurements: lines of code, average lines per bug etc

43 The Joel Test 1. Do you use source code control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do programmers have quiet working conditions? 9. Do you use the best tools money can buy? 10. Do you have testers? 11. Do new candidates write code during their interview? 12. Do you do hallway usability testing?

44 : The Joel Test Do you use source code control? If not, stop what you are doing, because whatever it is, you re doing it wrong Without source code control, multiple developers will not be able to work together Even if you could, SCC is so simple to set up Even for single developers being able to see previous versions is wonderful for bug-finding (amongst other things)

45 : The Joel Test Can you make a build in one step? Is there one step, that can build every kind of executable, all the documentation, all the various versions and platform-dependent releases Anything that takes more than one step can be messed up

46 : The Joel Test Do you make daily builds? Sometimes someone breaks the build A common mistake is to add a new source file and forget to add it to the source code control Everything works/compiles on the single person s machine but that file is missing from the repository and hence any references break the build for others A daily/hourly build catches these mistakes sooner rather than later Some teams have punishments for breaking the build, such as that the offender must babysit the buildbot or becomes the coffee-mule

47 : The Joel Test Do you have a bug database? If not, you will ship low quality code Even if you are single developer You are also likely to work on low-priority items

48 : The Joel Test Do you fix bugs before writing new code? Remember the feature matrix? The longer you wait before fixing a bug, the costlier it is to fix in both time and money

49 : The Joel Test Do you have an up-to-date schedule? I know writing a schedule is hard but sometimes other things depend on your code It keeps a tab on featuritis and helps decide what does and what does not go in

50 : The Joel Test Do you have a spec? Nobody disagrees with the statement: It s a good idea to have a spec I warned you about coding requiring good communication, writing a spec is good communication

51 : The Joel Test Do programmers have quiet working conditions? Speaks for itself Interesting read on the worst time to interrupt a programmer: programmer-interrupted/ A programmer takes between minutes to start editing code after resuming work from an interruption. When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute

52 : The Joel Test Do you use the best tools money can buy? Programmers are expensive, software isn t that expensive This doesn t mean to say that the best is necessarily expensive

53 : The Joel Test Do you have testers? A tester is cheaper than a programmer, don t pay a programmer to test Similar to asking a surgeon to take over a nurse s shift for a week but still pay the them the surgeon s salary

54 : The Joel Test Do new candidates write code during their interview? A couple of blog-posts about this went viral around 6 years ago Write a program that prints the numbers from 1 to 100. But for multiples of three print Fizz instead of the number and for the multiples of five print Buzz. For numbers which are multiples of both three and five print FizzBuzz. Numbers vary, but essentially a majority of those applying for programming jobs cannot do this

55 : The Joel Test Do you do hallway usability testing? Not overly relevant for us, but: Hallway usability testing: Grab the next person that walks past your office/desk Ask them to use the code you just wrote 5-6 people will tell you 95% of what there is to learn about usability problems in your code

56 The Joel Test Related to Tool Usage? 1. Do you use source code control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do programmers have quiet working conditions? 9. Do you use the best tools money can buy? 10. Do you have testers? 11. Do new candidates write code during their interview? 12. Do you do hallway usability testing?

57 The Joel Test As an aside, any of these questions are good questions to ask of any company you are interviewing Note, the interview can be as much you examining them as they examining you

58 Summary Every sane person should be using version control and build control tools Unit/regression testing is good and much easier with the right framework Bug/issue tracking can stop you from going mad Documentation generation is great, but does not eliminate hand cleanup At least use these tools until you find something better For a big list of project management tools for Linux, see The individual tools are not that important, but it is important that you use something for each of these tasks and that you know they exist

59 Related Reading Required Reading Eric S. Raymond. Understanding Version-Control Systems, 2007 update Of course, dates and details of specific tools are not examinable Martin Fowler. Continuous Integration, 2006 update Suggested Reading Sebastien Auvray. Distributed Version Control Systems: A Not-So-Quick Guide Through, 2008 Linas Vepstas. Call Center, Bug Tracking and Project Management Tools for Linux, 2002 update Ben Collins-Sussman et al. Version Control with Subversion, Chapter 1, Fundamental Concepts.

60 Any Questions Any Questions? Next time there might be a slightly longer quiz so please bring something to write on, even if that is just your phone, but it will probably be easier with a pen and paper.