Software Construction

Construction refers to the hands-on part of creating something. Known as implementation / coding and debugging & verification and validation (testing). Focus at coding, debugging, some detailed design and some testing (esp. unit testing). Quality of construction substantially affects the quality of the software. According to McConnell (1993): 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.

Coding principles

Coding principles and concepts are closely aligned programming style, programming languages, and programming methods. Before you write one line of code: Understand of the problem youre trying to solve. Understand basic design principles and concepts. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate. Select a programming environment that provides tools that will make your work easier. Create a set of unit tests that will be applied once the component you code is completed. As you begin writing code: Constrain your algorithms by following structured programming [Boh00] practice. Consider the use of pair programming Select data structures that will meet the needs of the design. Understand the software architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting.

 Create a visual layout (e.g., indentation and blank lines) that aids understanding. After youve completed your first coding pass: Conduct a code walkthrough when appropriate. Perform unit tests and correct errors youve uncovered. Refactor the code reorganization technique that simplifies the code without changing its function or behaviour.

Defensive Programming

When the programmer makes necessary assumptions and creates code that anticipates potential problems and specification changes.

 According to Tushar Mehta (2009), defensive programming involves: a) finding problems in the existing code by identifying code inconsistencies and understanding typical uses of the software, b) anticipating and preempting both potential problems with the existing specifications as well as likely changes in user behavior and design specifications, and c) 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 isnt broke, dont fix it. 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. o 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 customers real requirements. But, inspections cannot check non-functional characteristics such as performance, usability. Focus at detecting defects. Program inspections are very effective in discovering defects. A formal process that involve a team of several members o Fagan originally developed this method at IBM in the 1970s with four suggested roles author, reader, tester & moderator

Program/code Inspection Process

Advantages of Inspection over Testing

According to Sommerville (2004): 1. A single inspection session can discover many errors in a software/system. During program testing, errors can mask (hide) other errors. 2. 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. 3. Inspections can search for program defects and other

quality attributes of a program E.g. compliance with standard, portability, maintainability, efficiency.

Software reuse

Reuse - based software engineering

Requirements for Reuse

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 -? Application system reuse o 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 o Components of an application from sub-systems to single objects may be reused Object and function reuse o Software components that implement a single welldefined function may be reused 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. 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

Reuse - based software engineering

Requirements for Reuse

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 -? Application system reuse o 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 o Components of an application from sub-systems to single objects may be reused Object and function reuse o Software components that implement a single welldefined function may be reused 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.