Learn Software Development » Coding

Construction Practice – Type of Software Egineering practice

ashish — Tue, 20 Oct 2009 19:34:42 +0000

The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end-user. A set of fundamental principles and concepts are applicable to coding and testing.
1. Coding principles : A number of fundamental principles that can be stated are :
- Preparation principles
* Understand the problem you are trying to solve.
* Understand the basic design principles and concepts.
* Pick an appropriate programming language.
* Select a programming environment.
* Create a set of unit tests that will be applied once the component you code is completed.
- Coding Principles
* Constrain your algorithms by following structured programming practice.
* Select data structures.
* Understand the software architecture and create interfaces.
* 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.
- Validation principles
* Conduct a code walk through when appropriate.
* Perform unit tests.
* Refactor the code.
2. Testing Principles : It is a process of executing a program with the intent of finding an error. A set of testing principles that have been adapted are :
- All tests should be traceable to customer requirements.
- Tests should be planned long before testing begins.
- The Pareto principle states that 80% of all errors uncovered during testing will likely be traceable to 20% of all program components applies to software testing.
- Testing should begin “in the small” and progress toward testing “in the large”.
- Exhaustive testing is not possible.

Testing details during the SDLC phases

ashish — Sun, 06 Apr 2008 18:06:30 +0000

Details of testing requirements during broad phases of the SDLC:

REQUIREMENTS ANALYSIS

Test activities that should be performed during this stage are:

• Have a clear, concise and formal statement of the requirements; this means that the requirements statement should record the information as
1. What the program must do?
2. The input and data formats?
3. The output data formats?
4. How exceptions, errors and deviations are to be handled?
5. Hardware & Software required?

• Start developing the test set at the requirements analysis phase – data should be generated that can be used to determine whether the requirements have been met. To do this, the input domain should be partitioned into classes of values that the program will treat and for each class a representative element should be included along with the boundary values and any non extreme input values that requires special handling. The output domain should be treated in a similar fashion.

• The correctness, consistency and completeness of the requirements should also be analyzed – whether the problem is being solved, check for conflicts and inconsistencies among the requirements and consider the possibility of missing cases.

DESIGN

The design document should contain:
• Principal data structures
• Functional algos, heuristics/special techniques used for processing.
• How the program is organized?

Testing activities should consist of:
• Analysis of design to check its completeness and consistency – no steps or special cases should be overlooked. Internal interfaces, i/o handling and data structures should be checked for inconsistencies.
• Analysis of design to check whether it satisfies the requirements – both the requirements and design document contain the same form, format, units. All the functions listed in requirement document should be included in design document. Also, the design should yield the expected values.
• Generation of test data based on the design – the tests generated should cover the structure as well as the internal functions of the design. Standard extreme and special values should be recorded.
• Reexamination and refinement of the test data set generated at the requirements analysis phase.

PROGRAMMING/CONSTRUCTION

The main testing points are:
• Check the code for consistency with design – areas to check include modular structure, module interfaces, data structures, functions, algorithms and I/O handling.
• Perform the testing process in an organized and systematic manner with test runs dated, automated and saved.
• Ask some colleague for assistance – the programmer should explain the product to the party who will then question the logic and search for errors with a checklist to guide the search.
• Use available tools like various compilers and interpreters that are available on the system for the implementation language being used because they differ in their error analysis and code generation capabilities.
• Apply stress to the program – testing should exercise and stress the program structure, data structure, internal functions and the extremely visible functions or functionality.
• Test one at a time – Pieces of code, individual modules and small collections of modules should be exercised separately before they are integrated into a complete program because errors are easier to isolate when the number of potential interactions are kept small.
• Measure testing coverage/When should testing stop? – the metrics used to measure testing thoroughness include statement testing(whether each statement has been executed at least once), branch testing(whether each exit from each branch has been executed at least once) and path testing(whether all logical paths have been executed at least once).

OPERATIONS & MAINTENANCE

Testing during maintenance is termed regression testing. The test set, the test plan, and the test results for the original program should exist. Modifications must be made to accommodate the program changes, and then all the portions of the program affected by the modifications must be retested. After regression testing is completed, the program and test document should be updated to reflect changes.

What is branching ?

ashish — Thu, 27 Dec 2007 14:36:20 +0000

Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file, or a directory tree) in such a way that the newly created object has initially the same contents as the version branched off from, and (more importantly) development (creation of new versions) can happen in parallel along both branches. A branch is an agreed split in path of an item [item, product, or system] into 2 paths. Each path can maintain independent changes to the configuration item(s).
Branching is integral to version management, software build correctness, and release management. It enables parallel development of a new system and provides concurrent support of multiple releases by labeling each instance of a branched configuration item and establishing a mapping between the label and the module revisions. Some revision control systems have specific jargon for the main development branch – for example, in CVS, it is called the “MAIN”. A more generic term is “mainline”.
The basic concept of a branch: A line of development that exists independently of another line, yet still shares a common history. A branch always begins life as a copy of something, and moves on from there, generating its own history. Software branching is commonly seen when adapting one software product to different environments or targeting customers in software industry. Branching also generally implies the ability to later merge the differences accrued to an object on a branch back onto its parent branch. Often the changes are merged back to the trunk (even if this is not the parent branch).

Problems in trying to implement coding standards

ashish — Sat, 13 Oct 2007 16:50:11 +0000

Coding standards sound like the best thing possible; they help in getting uniformity, they enable easy transition, they promote easy code review and preparation of documents such as SDK’s, and so on. So why would you not be able to get coding standards implemented across development teams ?
Mostly it is due to individuality. Most developers are used to writing code as they are most comfortable, and having to modify this approach to write to a common standard is hard.
A lot of developers start work in smaller places where there is less pressure to follow standards, and only then move to places that encourage standards. But by the time they are in a position to follow standards, they have already got a set style.
Trying to enforce a coding standard without explaining the reasons is bound to cause a lot of resentment and lead to a feeling that a ‘process’ decision has been taken by a manager. In fact, given the number of reasons in favor of having coding standards, it is far more effective to get the senior coders bought in first, and they will be easily able to drive adoption.
Trying to take an external style and enforcing it for the entire team may fail. It is better to let the team develop a standard that works for the entire team and use that standard.
In many cases, such as developers writing in Perl , there is a feeling that trying to enforce a standard crimps their style.

Coding standards for different languages

ashish — Sat, 13 Oct 2007 16:25:48 +0000

Nowadays code can be written in a number of different platforms and architectures. For example, earlier, you would have primarily C and C++ as the different languages in which code was written for a majority of applications, but now there are so many different languages and platforms that the same coding standards cannot be used for all of them. So, here is a compilation of possible coding standards for these varies languages and platforms:

1. C (link)

2. C/C++ for embedded development (link)

3. Visual Basic 6 (link)

4. Visual Basic .Net (link)

5. .Net Conventions (C#, VB .Net, J# .Net) (link, link2)

6. Java (link, link2)

7. HTML (link, link2)

8. Perl (link, link2, link3)

9. Python (link, link2, link3)

10. PHP (link, link2, link3)

11. Ruby (link, link2)

12. JavaScript (link, link2, link3)

13. CSS (link, link2, link3)

14. ActionScript (Flash) (link, link2 (PDF))

15. C++ (link, link2, link3)