Implementation Software Life Cycle The phases necessary to

Implementation

Software Life Cycle • The phases necessary to develop and maintain a software system include: – Requirements (Specification) – Design – Implementation (Coding) – Testing (Validation) – Maintenance (Evolution)

A Generic Software Design Process

Design Phases • Architectural design: Identify sub-systems. • defines the relationship among major structural elements. • The division into subsystems and components, – How these will be connected. – How they will interact. – Their interfaces. • Abstract specification: Specify sub-systems. • Interface design: Describe sub-system interfaces. – describes how the software communicates with users. • Component design: Decompose sub-systems into components. • Data structure design: Design data structures to hold problem data. • Algorithm design: Design algorithms for problem functions.

Implementation • Translating the design into required programs and database, removing errors and delivering the finished product to the client • Programming/Coding is a personal activity there is no generic programming process. • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process. • The activities of design and implementation are closely related and may be interleaved. CMSC 345, Version 1/03

Implementation • These other activities could be included in implementation: • Testing • Installation • Documentation • Training of users • Conversion to new system

1. Confirm the detailed designs you must implement – code only from a written design (part of the SDD) 2. Prepare to measure time spent, classified by: – residual detailed design; detailed design review; coding review; compiling & repairing syntax defects; unit testing & repairing defects found in testing 3. Prepare to record defects using a form – default: major (requ. unsatisfied), trivial, or neither – default: error, naming, environment, system, data, other 4. Understand required standards Prepare for Implementation – for coding – for the personal documentation you must keep 5. Estimate size and time based on your past data 6. Plan the work in segments of ± 100 LOC

One way to Implement Code 1/2 1. Plan the structure and residual design for your code (complete missing detailed design, if any) – note the time spent 2. Self-inspect your design and/or structure – note time spent, defect type, source (phase), severity 3. Type your code – do not compile yet – apply required standards – code in a manner that is easiest to verify

One way to Implement Code 2/2 4. Self-inspect your code -- do not compile yet – convince yourself that your code does the required job • the compiler will never do this for you: it merely checks syntax! – note time spent, defects found, type, source, severity 5. Compile your code – repair syntax defects – note time spent, defect type, source, severity , and LOC. 6. Test your code – apply unit test methods – note time spent, defects found: type, source, severity

Coding Standards

Coding Standards • This is just how we, as humans, format our computer code. • The computer does not care at all about this. How you format your code will not (directly) affect how your programs runs, at all. • However, programming ( in practice ) is a team sports. Coding conventions can help the team work together better. • So why are these important? Why might it be bad?

The Good Common standards make a few good things happen: • Programmers can go into any code and figure out what's going on. • New people can get up to speed quickly. • People new to the programming language are spared making the same mistakes over and over again. • People tend to make fewer mistakes in consistent environments.

The Bad You’ll hear lots of reasons why coding standards are bad / pointless. • The standard is usually stupid because it was made by someone who doesn't understand programmig. • The standard is usually stupid because it's not what I do. • Standards reduce creativity. • Standards are unnecessary as long as people are consistent. • Standards enforce too much structure. • People ignore standards anyway.

Software Engineering 1. Software Engineering is an extraordinarily expensive undertaking. • Because of this, it usually requires the code to stay around for a while - How long did Microsoft have to maintain/patch/(defend in court) Windows 95? 2. Turnover rate is also very high for Software Engineers – by some estimate as high as 30%. • So, even at a good company with a low turnover rate, say, 15%, with 100 software engineers, that’s 15 people that need to get up to speed on a project – and 15 people that took all their knowledge about what they coded with them!

Software Engineering 3. Also note that the maintenance phase of a project can run 50 -80% of the total engineering effort. • So it’s very important for new programmers to be able to get up to speed in a relatively short amount of time.

What you can do • There a lot of things you can do, as a programmer, to make it easier for others to understand your code (we just saw why this is important. ) • Specifically, there are things you SHOULDN’T DO. Although lots of programmers do them.

Single Letter/Very Short variable names • • By naming your variables a, b, c, etc. , not only will no one know what they are, it also makes it impossible to search for them with a text editor. Two letter variable names are also almost as useless.

Naming 1. Naming • In naming functions and variables, do not use abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e. g. routine. X 48, Perform. Data. Function, Do. It, Handle. Stuff and do_args_method. 2. Capi. Tali. Sa. Tion • Randomly capitalize the first letter of a syllable in the middle of a word. For example: Compute. Raster. Histo. Gram().

Naming 3. Avoid Emotional Names • Choose variable names with irrelevant emotional connotation. e. g. : Marypoppins = ( superman + starship ) / god; This really confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about. 4. Uppercase l, looks a lot like the number 1 • Avoid using lower case l to indicate long constants. e. g. 10 l is more likely to be mistaken for 101 than 10 L is.

Masquerading Techniques Include sections of code that is commented out but at first glance does not appear to be. for ( j=0; j<array_len; j+ =8 ) { total += array[j+0]; total += array[j+1]; total += array[j+2]; /* Main body of total += array[j+3]; * loop is unrolled total += array[j+4]; * for greater speed. total += array[j+5]; */ total += array[j+6]; } Without the colour coding would you notice that three lines of code are commented out?

Documentation Document What not How Document the details of what a program is attempting to accomplish. Otherwise, if there is a bug, the fixer will have no clue what the code should be doing. Avoid Documenting the "Obvious“ Comments like /* add 1 to i */ are not necessary Keep comments up-to-date You don't have to actively lie, just fail to keep comments as up to date with the code. Units of measure Document the units of measure of any variable, input, output or parameter. e. g. feet, metres, cartons. This is very important in engineering work.

A coding standard • You could make up a coding standard for yourself. The whole point of this is to get you thinking about structuring/commenting your programs! 1) Each Source File should have a comment block at the top, with the date, the program filename, and a short description of it. 2) Variables names should be self describing, exceptions being loop counters in for loops, etc. – int my. Weight. In. Pounds; int timeout. In. Msec; 3) Function names should also be self describing – Check. For. Errors() instead of Error. Check(), Dump. Data. To. File() instead of Data. File(). 4) Use consistent case. camel. Case. Is. Fine 5) No magic numbers – any number other than 0 or 1 should have a constant defined for it. Example: – const int square. Feet. In. Square. Yard = 9;

A coding standard 6) Use meaningful comments to describe complex situations, avoid useless comments. 7) Use spaces in all assignment statements, and always use brackets in control / repetition statements for ( int i = 0; i < some. Constant; i++ ) { //do something } if ( a == b ) { //do something } This is sometimes referred to as “One True Brace” – and it should almost always be used.