Software implementation

Uploaded on


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Software Implementation Coding Process The coding activity starts when some form of design has been done and the specifications of the modules to be developed are available. The programming team must have a designated leader, a well defined organization structure and a thorough understanding of the duties and responsibilities of each team member. The implementation team must be provided with a well defined set of software requirements, an architectural design specification, and a detailed design description. Also, each team member must understand the objectives of implementation. A famous experiment by Weinberg showed that if programmers are specified a clear objective for the program, they usually satisfy it. Incremental Coding Process A code is written for implementing only part of the functionality of the module. This code is compiled and tested with some quick tests to check and when it is passed, the developer proceeds to add further functionality. The advantage is easy identification of error in the code as small parts are tested. Test scripts can be prepared and run each time with new code to ensure the old functionality is still working. Other methods • Test driven development The programmer first writes the test scripts then writes the code to pass the tests. The whole process is done incrementally. • Pair programming More than one programmer implements the code and thus algorithms are checked in a better way. Advantages 1. Common ownership of programs 2. Informal review by both 3. Supports refactoring Refactoring It is a technique to improve existing code and prevent this design decay with time, caused by changes. It is a change made to the internal structure of software to make it easier to understand. Refactoring though done on source code, has the objective of improving the design that the code implements. The main risk of refactoring is that existing code may break due to changes. Therefore rules: 1. Refactor in small parts 2. Have test scripts available to test existing functionality. With refactoring, code becomes continuously improving. Thus the design rather than decaying evolves and improves with time.
  • 2. Need for refactoring arises when.. 1. Duplicate code exists in code 2. Methods become long 3. Classes are large 4. Parameter lists are long 5. Too many switch statements 6. Too much communication between objects 7. When one method calls another method which simply passes the call or message chaining Common code refactorings • Improving methods 1. Extracting functionally cohesive codes from a large method. 2. Add/remove parameters as per requirements • Improving classes 1. Moving methods to appropriate classes where they are actually required 2. Move field 3. Extract classes from a large class 4. Replace data value with object if the data is used frequently for operations • Improve hierarchies 1. Replace conditional with polymorphism: At times the functionality is defined by conditions in the code. It should be replaced with OOD by incorporating polymorphism 2. Pull up field/method: if a field or method exists in most of the subclasses, it can be pulled up to superclass. Good programming practices • Control constructs should have a single-in and single-out • Gotos should be minimized • Information hiding should be practiced • Nesting should not be deep • Module size should not be large • Do not leave catch block empty • Give importance to exceptions • Buffer overflow should be avoided • Arithmetic exceptions should be provided for • Memory leaks should be avoided Verification Techniques 1. Code inspection The inspection team includes the programmer, the designer and the tester. They are provided with the code to be reviewed and the design documents. In addition to defect, the inspection team also looks for quality issues like efficiency, compliance to coding standards etc. Often the type of defects the inspection focuses on are included in the checklist. Inspection is done through code reading. It starts with reading the innermost structure and reaching top. 1. Static analysis.
  • 3. Model checking (where model is checked for desired properties), dynamic checking (where input and output variables after execution of the program all compared to know if its executing correctly) and static analysis where program is methodically checked, generally by the aid of software tools. Two methods for finding errors are to look for unusual patterns and to directly look for errors. Verification Techniques • Proving correctness or the axiomatic approach 1. Basic assertion P{S}Q 2. Axiom of assignment Pxf{x:=f}P 3. Rule of composition P{S1}Q,Q{S2}R P{S1;S2}R 1. Rule of alternate statement P^B{S}, P^~B=>Q P{if B then S}Q P^B{S1}Q,P^B{S2}Q P{if B then S1 else S2}Q 1. Rules of consequence P{S}R, R=>Q , P=>R, R{S}Q P{S}Q P{S}Q 1. Rule of iteration . P^B{S}P . P{while B do S}P^~B Code metrics 1. Size measure: The non-comment and non-blank lines are counted. Halstead’s measure or COCOMO model can be implemented for size. 2. Complexity metrics 1. Size is related to complexity. Bigger the program, the more complex it is to understand. 2. Cyclomatic complexity 3. Halstead’s measure of ease of reading 4. Live variables exist from its first to last reference within a module. More the number of live variables, it’s more complex. Another data usage-oriented concept is span, the number of statements between two successive uses of a variable is referenced
  • 4. at n different places in a module, then for that variable, there are ( n-1) spans. 5. Style metrics 1. Module length 2. Identifier length 3. Comments 4. Indentation 5. Blank lines 6. Line length 7. Embedded spaces 8. Constants definition 9. Reserved works 10. gotos