CSEB233 Fundamentals of Software Engineering

1. CSEB233 Fundamentals of Software Engineering Module 5: Software Implementation/Coding Badariah Solemon 2010

2. Objectives • To explain what is software construction and why it is important • To describe good programming principles/practices • To introduce the concept of ‘defensive programming’. • To describe software inspection as a static method to discover defects, errors or problems . • To explain the concepts, benefits and problems of software reuse. Badariah Solemon 2010

3. What is software construction? • ‘Construction’ refers to the hands-on part of creating something. • Also known as implementation / coding and debugging & verification and validation (testing). • Generally focus at coding, debugging, some detailed design and some testing (esp. unit testing). • Quality of construction substantially affects the quality of the software. Badariah Solemon 2010

4. What is software construction? (cnt’d) • According to McConnell (1993), construction may involves: • Verifying that the groundwork has been laid so that construction can proceed successfully. • Designing and writing routines and modules. • Selecting and creating data types and naming identifiers. • Selecting control structures and organizing blocks of statements. • Finding and fixing errors. • Reviewing other team members’ design and code and having them review yours. • Polishing code – formatting and writing comments (i.e. internal documentation). • Integrating software components (if built separately). • Tuning code – make it more efficient, smaller and faster. Badariah Solemon 2010

5. Why is software construction important? • Depending on the size of the project, construction may takes 30% to 80% of the total project time. The larger the time spent, the bigger the work affect the success of the project. • Construction is the pivotal activity in software development. • With a focus on construction, there is a great potential for the average programmer’s productivity to improve. • Requirements document and design documents can go out of date, but construction’s by product, the source code, is always up to date. • Ideally software project goes through requirements engineering and modeling activities before construction begins. In reality, construction is the only activity that’s guaranteed to be done! (Source: McConnel, 1993, pp. 5) Badariah Solemon 2010

6. Good programming practices Generic practices: • Start with a good design. Update the design documents regularly. Create additional design documents before adding major new features or functionality. • The program under development should be at all times functioning. The development process consists of adding new functionality without breaking existing functionality. • Work has to be divided into small incremental steps that can be typically accomplished and code-reviewed in one day. Even large-scale rewrites should be made incremental. • Every line of code written or modified undergoes peer review. The smallest team must contain at least two programmers so that they can code-review each other's changes. • Always attempt to work top-down in: • Design—start with high level objects. • Implementation—create top-level objects using low-level stubs. • Modification—change the top-level objects and the overall flow of control first. If necessary, use stubs, or fake new functionality using old implementation. (Source: http://relisoft.com/practice.html) Badariah Solemon 2010

7. Good programming practices (cnt’d) • Be consistent with formatting. • Be consistent with naming conventions. • Use global [identifiers] sparingly. • Don't assume output formats. • Add comment to your code – explain what and why • Provide useful error messages. • Recover (or fail) gracefully. • Push interface up and implementation down. • Know what you don't know – prepare for changes. (Source: Kim Moser at http://relisoft.com/practice.html ) Badariah Solemon 2010

8. Defensive Progamming • Defensive programming is when the programmer makes necessary assumptions and creates code that anticipates potential problems and specification changes. • According to Tushar Mehta (2009), defensive programming involves: • finding problems in the existing code by identifying code inconsistencies and understanding typical uses of the software, • anticipating – and preempting – both potential problems with the existing specifications as well as likely changes in user behavior and design specifications, and • streamlining the code to aid readability and simplify maintainability. • A good defensive programmer is sufficiently confident in her abilities to ignore the traditional belief that “If it isn’t broke, don’t fix it.” Badariah Solemon 2010

9. Defensive Progamming Example: Handle unexpected conditions Do you always have a "default" case in you "switch" statements? switch($some_value) { case 1: $another_value = 1; break; case 2: $another_value = 4; break; } return(1 / $another_value); What if $some_valueis not 1 nor 2? Notice: Undefined variable: another_value Warning: Division by zero Badariah Solemon 2010

10. Defensive Progamming Example: Process external systems data properly Validate your input What do you do with the data entered by the users? What about data of files or data retrieved from remote sites? Are you verifying whether it comes in the format that your application expects? Always validate external data in any case. This means that you should always check if data comes in the expected format, and do not proceed in case the data is not valid. Examples are taken from: http://www.phpclasses.org/blog/post/65-8-defensive-programming-best- practices-to-prevent-breaking-your-sites.html Badariah Solemon 2010

11. Software Inspections • An ‘old school’ approach. • A process to review, analyze and check static system representations such as requirements document, design document, and program source code to look for errors and problems. • Static – need not run the software on a computer • Generally, focus at source code. • Sometime also known as peer reviews or program/code inspections. • Inspections can check conformance with a specification but not conformance with the customer’s real requirements. • But, inspections cannot check non-functional characteristics such as performance, usability, etc. Badariah Solemon 2010

12. Program/code Inspection Process • Focus at detecting defects (i.e. logical errors & anomalies in the code). • Program inspections are very effective in discovering defects. • A formal process that involve a team of several members • Fagan originally developed this method at IBM in the 1970s with four suggested roles – author, reader, tester & moderator Badariah Solemon 2010

13. Advantages of Inspection over Testing • According to Sommerville (2004): • A single inspection session can discover many errors in a software/system. • During program testing, errors can mask (hide) other errors. • Incomplete versions of a software/system can be inspected without additional costs. • To test an incomplete program, need to develop specialized test to test the parts that are available. • Inspections can search for program defects and other quality attributes of a program • E.g., compliance with standard, portability, maintainability, efficiency, and etc. Badariah Solemon 2010

14. Drawbacks/Issues related to Inspections • Difficult to introduce formal inspections into software development organizations. • Software engineers (programmers) with experience are sometimes reluctant to accept that inspections can be more effective for detecting defects (errors) than testing. • Managers may be sceptical as inspections require extra costs during modelling and construction. • Inspections may take time to arrange and appear to slow down the development process. Badariah Solemon 2010

15. Software reuse • According to Sommerville (2004): • In most engineering disciplines, systems are designed by composing existing components that have been used in other systems • Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic reuse rather than ad-hoc reuse • Systematic reuse -? Badariah Solemon 2010

16. Reuse-based software engineering • Application system reuse • The whole of an application system may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families • Component reuse • Components of an application from sub-systems to single objects may be reused • Object and function reuse • Software components that implement a single well-defined function may be reused Badariah Solemon 2010

17. Requirements for Reuse • It must be possible to find appropriate reusable components • The reuser of the component must be confident that the components will be reliable and will behave as specified • The components must be documented so that they can be understood and, where appropriate, modified. Badariah Solemon 2010

18. Benefits of reuse • Increased dependability • Software/components/function has been tried and tested in working systems, so should be more dependable than new software. • Reduced process risk • Less uncertainty in development costs especially if a large software components are reused. • Effective use of specialists • Reuse components instead of people. The specialist can create reusable components • Standards compliance • Standards such as UI standard (e.g., drop-down menu) can be implemented as reusable components to improve dependability as users are less likely to make mistake • Accelerated development • Avoid original development, speed-up production and hence able to market product early Badariah Solemon 2010

19. Reuse problems • Increased costs • in understanding whether the application/component/function is suitable for reuse, in testing it to ensure its dependability and in maintaining the reused item. • Lack of CASE tool support • Not-invented-here syndrome • Some software engineers may think that writing original software is seen as more challenging than reusing other people’s software. • Maintaining a component library can be expensive • Finding and adapting reusable components Badariah Solemon 2010

20. Summary • You have been introduced to: • good programming principles/practices • the concept of ‘defensive programming’. • software inspection as a static method to discover defects, errors or problems . • the concepts, benefits and problems of software reuse Badariah Solemon 2010

21. References • Tushar Mehta (http://www.tushar-mehta.com/excel/vba/vba-defensive_programming.htm) • Sommerville, I. 2004. Software Engineering, 7th Ed. Addison Wesley: Boston. • McConnell, S. 1993. Code Complete. Microsoft Press: Bangalore, India. Badariah Solemon 2010