Software Engineering Explored

Testing memories in embedded systems

2010-01-06T07:49:00.000-08:00

In embedded software, memory plays an important role. To see that memory works correctly; we have to test memory. There are two aspects of testing a memory.

Memory tested at manufacturer end and memory tested at the developers end. Due to advance in technology, defects in the memory due to manufacturing process are few and can be tested against. But at the developer end, memory can fail in many ways and to test the memory against those failures, it requires lots of time and resources in programming. Other question is whether memory tested at the start of the program execution is good enough or tests shall be conducted at regular interval during execution of the program.

To understand the algorithm to test the memory against failures, we must first see what are the different ways in which memory can fail? There two categories in which errors causing failures are divided, hard errors and soft errors.

Hard errors

Memory uses a sometimes very complex net of wiring and circuitry. Wires break, socketed chips rattle loose, corrosion creates open circuits, and chips fail.

Any of such error occurring due to electrical connections between processor and memory or absence of memory or loose connection of memory is called as hard error. These errors are again divided into three types: Address bus error, data us error and control signal error. Although it is relatively easier to derive and algorithm and test memory against address and data bus errors, it is some what impractical to test control signal errors.

Data line errors:

These are errors which occur due to malfunctioning of data line connecting processor to the memory. In this case wrong data is written on and read from the memory location.

For example, “Stuck together” where one or two bits contain same value irrespective of data transmitted on the data line or “stuck high” and “stuck low” where a particular bit is always high or always low, as the case may be.

These errors can be tested against by making each bit or data line 0 and 1 independent of other bits.

Address line error

These errors occur due to cross connection or open connection in the address line. In this case data written is seems to be overlapping as data intend for one memory location is written on other.

Signal error

Due to failure of control signals, memory probably, will not work at all and can be easily detected. Although practically there are no generalized tests possible to test against these errors, theoretically it is possible to generate specific tests.

Soft errors

These are errors which corrupt the memory location contents and are transient. Tests to check the soft memory errors are generally based on the principle that “is it the same what we had written on the memory location.”

Tomorrow we will be working on developing tests against above mentioned errors.

What is hardware in loop simulation?

2009-12-23T06:15:00.001-08:00

A system in which hardware and software are both involved satisfying the intended functionality is called as embedded system. This kind of systems must interact with the outer world and hence the outer environment has profound impact on the correct working of the system.

But one cannot have the outer world ready at the time of development or testing of the system which system is going to be part of or it is not possible or advisable to develop or test such system in the real outer world in to gain confidence in the system. Consider an example of a navigation system for launch vehicles; we cannot afford to test them with the real launch vehicles which cost in billions. Take another one, a system which will control a nuclear power plant, can we risk lives if system doesn’t perform correctly in the real plant. Then, how to test these systems?

There is one method known as “Hardware in loop simulation”.
We develop the system in the host environment (normal PC) and burn (put it into) PROM and make the system ready. Now we find out what are the elements in the outer world, the system is going to interact with and how there responses would be if system sends them a particular signal at the time of operation. Create a model out of the outer environment and simulate the outer world in the model. Test the system with that simulated environment. So you don’t have real hardware in picture still u are testing their responses to the system under test.
There is another advantage this testing can be done while system is still under development so that to fine tune the expectations to be implemented in the system.
You can test the control units with extreme conditions that might not be feasible in the real world.

Regression testing

2009-10-28T06:41:00.001-07:00

Regression testing is process of finding defects in features of software which were working perfectly prior to bug fixation or inclusion of new features. So most of the test cases will be already present and we have to just re-run them. If new feature has been added, we might have to create new test cases.
Why we need regression testing? The answer for the question lies in the design process. However perfectly we design our system or software, there may be some interdependency among various functions and modules of the software called as coupling. As a result, a small change in one function can have catastrophic effect on the other. So to be assured that, any change done to fix a bug in one module has not affected any other module, we use regression testing.

Qualifying a component for regression testing: When any build comes for regression testing, we have to check whether or not the build worth testing. It may be possible that the build doesn’t satisfy the major requirements, so there is not point putting efforts in testing various smaller requirements. So it is advised that always test critical and difficult parts of the software at the first glance and then move on to the trivial and smaller parts. This process of qualifying software for detailed testing is called as smoke testing.

These are the four types of tests one shall run on the software before qualifying it for further testing.
1) Customer based tests: Find out all scenarios in which software is going to be used and run test cases to test software functionalities in those scenarios. Think at higher level i.e. product level and ask what are the test case critical for your customer and run them on priority. Operation profile of the software may be handy
2) Complex tests: Find out which are the test cases which will test majority of the important features of the software.
3) Expected failure tests: From the past experiences and intuition one can find out what are the ways in which the system can fail and try to test those things first before moving to other features.
4) Big picture test: Test the performance of the software and any other quality attributes. If software doesn’t satisfy these attributes tests then avoid testing other features.
Hence one can now understand that regression testing in not about blindly running already created test cases but there are some other subtle issues to be taken care of.

Make code readable and understandable: Naming conventions

2009-10-07T10:10:00.000-07:00

Uniform naming conventions shall be followed for variables and functions names throughout the code. One can decide upon the naming notations available (Hungarian, Camel, and Pascal etc) as per the requirement and comfortableness but once chosen, notation shall be followed throughout the code.

a) Names shall clearly state the intent of the variable or function. The most important consideration in naming a variable is that the name fully and accurately describes the entity the variable represents.
For example variable that current payload status is better named as curr_payload_status than cps.

b) Names should be as specific as possible. For example, one can use variable name date to represent current or today’s date. It’s almost a good names but it can represent any date and not the specific today’s date. It can be better named as currentDate.

c) Names should represent problem domain than the solution. They must represent what then how. For example, if one is dealing with temperature obtained by sensor, one shall name it as sensor_temp rather than obtain_temp.

d) Variable should be of Optimum length neither too long nor too short.
For example, for representing no of sensors in payload, numberofsensorsinpayload is too long where as n is too short. Optimal length name will be num_sensors

e) If variable stores result of some computation like total, average, maximum or minimum then names shall be prefixed or suffixed (one shall be followed throughout the code) with these quantifiers.
For example to represent average of all sensor data, average_sensor_data would be good name as compared to avg or avg_data etc.

f) Loop indexes should be given more meaningful name rather than just i, j, k if loop indexes are to be used outside the loop or loop body is longer than a few lines.

g) For naming any status variable, better name than flag should be given. For clarity, they must be assigned values and compared to enumerators and global variables which are defined as named constants.
characterType= =CONTROL_CHARACTER is more meaningful than statuflag==0X80

h) Temp should be avoided as much as possible. Instead of that a better name should be given to temporary variable which states the intent of the variable.
Temp= sqrt(b^2-4*a*c)
root[0]= (-b +temp)/2*a
root[1]= (-b -temp)/2*a
It is not advisable to use temp to store the result of expression as it is used in two places after that. Better name and code would be like
Discrimant= sqrt(b^2-4*a*c)
root[0]= (-b + Discrimant)/2*a
root[1]= (-b - Discrimant)/2*a

i) Boolean variable shall be named as done, error, found, success or OK. One can use them as isDone, isError, isFound, isSuccess etc.

j) When using an enumerated type, you can ensure that it’s clear that members of the type all belong to the same group by using group suffix.
Like Enum color
{
color_Red;
color_Green;
color_Blue;
}

k) When naming constants, name the abstract entity the constant represent rather than the number the constant refers to. NINE is a bad constant name for no of channels While NO_OF_CHANNELS is a better one. As no of channels can vary, they can be changed at one place only.
Avoid

a) Avoid names with similar meanings like input and inputValue, numRecord and recordNum etc.
b) Avoid variables with different meaning and similar name.
c) Avoid names that sound similar such as wrap and rap.
d) Avoid numerals in names like file1, temp1, temp2 etc.
e) Don’t differentiate variable names solely by capitalization like naming two variables as File and file is a bad practice.

What is LCSAJ?

2009-09-27T00:40:00.000-07:00

LCSAJ stands for Linear Code Sequence and Jump. Typically it contains three parts:
1) Initial step of the program code or a step to which control may jump and continue to execute after that.
2) The program terminating step or an instruction which lead to jump.
3) And the destination step of the jump.

Example:
Let’s there is a program which finds whether input number is prime or not.

1) Printf( “Enter the number:”);
2) Scanf(“%d”,&num) ;
3) bPrime=true;
4) for(int i=2;i&5) {
6) if( num%i==0)
{
7) Printf( “ %d is factor of %d”, i, num);
bPrime = false;
}
8) }
9) if(bPrime==true)
10) {
11) Printf( “Number is Prime”);
12) }
13) End of program.

To find all LCSAJs in code, find all jumps in the program. Those are: (4->9, 8->5, 6->8 and 9->13). All those instructions, to which control could jump from instruction other than the preceding one, are called as start of the LCSAJ.
In the above code starts of LCSAJ are: (1 (entry of the program), 5, 8 and 13).

Now find LCSAJ from each LCSAJ start. For LCSAJ starting at 1, control goes from instruction 1 to 3 and checks for condition at step 4. If the condition is false, then code jump occurs giving first LCSAJ, assuming all other conditions following it are true, (Initial step, branching step and destination step) (1, 4, 9). Now, the case where condition at step 4 is true, control flows from step 5 and then step 6, which is a condition statement. If that condition is false, a new LCSAJ would be formed due to jump which is (1, 6, 8). Similarly, LCSAJs (1, 8, 5) and (1, 9, 13) are also there.
Similarly, LCSAJs could be formed with every start of the LCSAJ.

100% LCSAJ Coverage implies 100% Decision Coverage. But there is a possibility of LCSAJs being infeasible while testing and also effort required for LCSAJ testing and coverage is more as compared to decision coverage.

IEEE 12207.0 Software life cycle processes

2009-09-24T09:42:00.000-07:00

IEEE 12207.0 is a standard which describes the various life cycle processes, activities and tasks to followed in various phases and parts of software life cycle. It is the standard which describes all activities and tasks for software development form cradle to grave from acquisition process to maintenance process along with some umbrella process like management process, infrastructure and training process.
It classifies all process into three parts: Primary processes, supporting processes and organizational process. Diagram below shows the structure of the standard.

Primary processes: these are processes which are performed by primary parties (which are involved in development, operation and maintenance of the software).
These primary parties are: acquirer who acquires the software, Supplier who supplies the software, Developer who develops the software, Operator who operates the software, and maintainer who maintains the software.

1) Acquire process: This process is collection of activities and tasks of the organization which acquires the system, software or service.
2) Supply process: This process is collection of activities and tasks of the organization which supplies the system, software or service.
3) Development process: This process is collection of activities and tasks of the organization which develops the system, software or service.
4) Operation process: This process is collection of activities and tasks of the organization which operates the system, software or service in its live environment.
5) Maintenance process: This process is collection of activities and tasks of the organization which maintains, track changes and keep running the system, software or service in its live environment.

Supporting processes: A supporting process supports another process (primary) in an integral part, as when needed, for successful completion of that process and quality outcome. There are eight supporting processes
1) Documentation process: It defines and elaborates the activities and tasks to be performed while recording the information of life cycle process; it can be requirements, design or any contract of the process.
2) Configuration management process: It defines all activities and tasks which are required for proper configuration management of project deliverable and artifacts.
3) Quality assurance process: It defines and elaborates various activities and tasks to assure quality of the product and process and ensure that product is developed as per requirements and adhere to their established plans.
4) Verification process: It defines activities (for acquirer, supplier, or independent party depending on the nature and time of conduction of process) for proper verification of the product being developed in varying depth based on the nature of the software.
5) Validation process: It defines activities (for acquirer, supplier, or independent party depending on the nature and time of conduction of process) for proper validation of the product being developed in varying depth based on the nature of the software.
Important difference between verification and validation is that verification is done for both process and product but validation is of product only.
Verification ensures that we are making system right.
Validation ensures that we have made the right system.
6) Joint review process: It defines all activities for reviewing the intermediate and final product and process. There are two parties involved in the process one is who is reviewing (may be independent) other being reviewed.
7) Audit process: It defines all activities and tasks which are essential for determining whether the process followed in development is compliance to the standard adopted. Here also there are two parties involved auditing and other being audited.
8) Problem resolution process: Defines activities and tasks for analyzing and removing the problems (including nonconformance), whatever their nature or source, that are discovered during the execution of development, operation, maintenance, or other processes.

3) Organizational processes: These processes are employed by organization for establishing and developing the underlying structure for life cycle process and producing personnel for improving the process and structure. These are umbrella process and are outside the project limits and can be employed and required across the projects. There are four organizational processes:
1) Management process: It defines activities and tasks for management for maintaining and improving the process including project management and execution of life cycle process.
2) Infrastructure process: It defines basic activities for establishing underlying structure for life cycle processes.
3) Improvement process: It defines basic activities and tasks (for all primary and supporting parties) for establish, measure, control and improve life cycle process.
4) Training process: It defines activities and tasks to produce skilled and adequately trained manpower for life cycle processes.
These are various processes in 12207. Software life cycle processes standard. We will discuss each and every process in detail in forth coming posts.

Unit testing techniques

2009-09-22T04:36:00.000-07:00

Unit is an atomic part of a program which could not be decomposed in smaller parts. Testing that part for its correct implementation is called unit testing. There are various techniques for conducting unit testing. These techniques are complementary to each other and find different set of errors when applied to unit, one after the other.

1) Specification based testing techniques: This technique generates test cases based on program's behavior,input domain and expected output.Following are specification based techniques
a) Equivalence partition: Under the technique, input domain of the unit is partitioned into various classes. Each class contains input values which would have similar effect on the code. Test cases select input values at random,from these classes.

b) Boundary value analysis: test cases are generated so that they can cover the boundaries of any condition in the code. Generally, it is performed after equivalence partition. One test case is designed for inside of the classes and as many as necessary to cover its limits.

c) Decision tables and cause effect graphing: Inputs for the unit can occur in any combinations. Those combinations are represented and analyzed with decision tables and cause effect graphing. Then test cases are generated for all the possible input output combinations.

d) Random testing: Test cases are generated at random according to the input domain and expected output domain specified in specifications.

2) Code based testing techniques: These testing techniques can be again classified into two categories:
Control flow based criteria: This varies as to how well and what part of code, the test case covers in the program control flow.
Data flow based criteria: In this, test cases cover the execution space between variable defined and where they are used in the program flow.

Let’s consider the control flow based criteria techniques:
a) Statement coverage: Test cases generated for this criterion must ensure that they execute each and every statement of the code.

b) Decision (branch) coverage: Code contains many decisions and corresponding branches for those decisions. To fulfill the decision or branch coverage criterion test cases must ensure that all the program decisions take the value true or false and execute the corresponding code

c) Condition (Predicate) Coverage: In practice, decisions compose of many conditions. Combination of values attained by these conditions decides the final outcome for decisions. To satisfy condition coverage criterion, test cases must ensure that all conditions present in the decision take the value true and false.

d) Modified condition/ decision coverage: There may be a case where we have tested the condition and decision in the program, but still individual effect of each condition on the decision is not tested. There may be cases of short circuiting in logical expressions. To test the independent influence of every condition on decision modified condition/ decision coverage is used.

Nature of bugs found in code inspection

2009-09-21T00:09:00.000-07:00

Code inspection is an important process in any mission or safety critical system development. It’s a type of static testing in which code is not executed but critically analyzed in order to find some subtle bugs which are not detectable or require lot of efforts to detect in testing phase. The point of interest is what kind of defects one can find in code inspection. This article analyses bugs classes found in the code in code inspection process.

1) Maintainability of the code: No code is perfect when it has been written. It is bound to change, enhanced and modified for adaptation to different platforms. So it is necessary that code written is understandable and maintainable. Code inspection focuses on this goal. Under this, following points are looked for in code:
a) Code to comment ratio is proper and whether comments explain intent of the code appropriately and correctly.
b) Whether all the variable names and function names are meaningful and clearly state the intention.
c) Whether the coding standards or guidelines are adhered to.
d) Whether code has proper logical flow or not?

2) Design flaws: Code reflects design of the software. What if the deign itself contains flaws. Since software is tested against requirements and design, it is very difficult to detect these kind of defects in testing phase. In that case, code inspection provides an additional design review step. There are issues which will never fail the system but very dangerous from the quality point of view. For example, when designing system, one designs a structure to keep track of some of the hardware channels status like if they were empty or full etc. The very thought instrumental behind the design was that structure could be used bit wise and memory could be saved which would have not possible by using arrays. But this thought didn’t consider that system had some functionality which requires checking status of all channels at the same time like for averaging of all channels data. Since the data structure used was bit wise structure, one has to check all the fields of the structure one by one resulting in very lengthy and unstructured code which would have been very simple, in single loop if array has been used.

3) Structural flaws: Proper structure of the code is must for understanding and testing of the software. Following points which are given stress on in code inspection process:

a) Does every function implement single functionality and is testable?
b) Does length of the function justifiable or shall it be broken into smaller ones?
c) Is any dead or extra code present in the code?
d) Is any unreachable code present in the code?
e) Whether there are multiple exists for functions and can they be removed?
f) Does every variable, that has been assigned value in any conditional block, get initialized prior to usage?

4) Logical errors: These are errors which are infused in the coding phase by developer because of ambiguous design or unclear requirements. As there is no guard against them in requirements and design, these kinds of bugs are subtle,not obvious in nature,may occur once in many execution cycles or when a particular sequence of events occur.
For example, lets say, software works in sequence of steps like power on, operation on, check of automatic corrections,operation off and then power off. In operation phase, it first checks whether given number of passes have already been elapsed in operation then only does the automatic correction. The variable which keeps track of no of passes was reinitialized at the power on stage. Assuming that software goes to operation off state; again comes to operation on state without going to power off state. Now since this is a fresh operation, automatic correction shall be applied after given no of passes have been elapsed in this operation, but as variable keeping track of no of passes is not reinitialized hence contains last value, so software does not wait for given no of passes to elapse and starts performing automatic correction. This error will not hamper the functioning of the software but will surely hamper the algorithm which calculates the corrections to be applied to the data. These kinds of errors are found in the code inspection by hypothesis.

There is subtle difference between code walkthrough and code inspection
Code walkthrough is an informal process which is conducted by developer team. Peer reviews are kind of code walkthrough.
Code inspection is more formal process with formal team,roles and meetings. Code inspections report is asked for in project and process audits. Checklists are used for code inspection.

Improving code quality

2009-09-02T09:38:00.000-07:00

Code is implementation of design of your software. However robust and reliable you design your software it is going to give problems especially while maintaining, changing or debugging. It is therefore important that code written shall be quality one. So the question is how to write quality code. There is set of steps which if followed while coding can result in quality code.

1) Identify and implement coding standard: Coding standards provide a common platform to all involved in the development so that everybody can understand code written by other and can easily change and test it. Coding standard makes code more readable and understandable which is most important form the QA point of view who conducts code walkthroughs. These also prevent mistakes which are induced due to hidden characteristics (Like precedence order of operators) of the language in which code has been implemented. Standards specify naming conventions, mandatory things to do and not to do etc. It is not necessary that coding standard followed by one organization or even project be suitable or mandatory for the other. These shall identified as per the project needs and project critically. Like in an on board projects MISRA C standard shall be followed but it is too strict for any ground software.
Various coding standards available are:

2) Code walkthrough/ Inspection: This technique comes under static testing process and finds out bugs and violation in code without executing the code. Code walkthrough try to improve the structure, flow and understandability of the code and focuses on errors which are hindrance to maintainability and changeability of the code although it tries to find out logical mistakes in the code. Usually, a checklist, which contains a list of commonly occurring errors, is used in code walkthrough/ inspection. These some faults therefore are removed in the code before going for testing.

3) Proper commenting: Commenting is the best way to document your code. Commenting shall be mandatory for all projects but the extent of commenting may vary. For example for a critical medical software there may be 1:1 ratio of comments i.e. for every line of code written, there is a comment explaining the intent of the statement while for a website code it can 1:10 i.e. one comment for every ten lines of code. A format can be devised for comments at module level which may contain the version no of the module, purpose of the module, Functional requirement implemented in the module, inputs, processing and out of the module.

4) Use static code analyzer: These kinds of software are very useful in detecting trivial errors like connection not closed, file not closed, null pointer dereference (if applicable for language) etc. Using these tools can save time as well resources for code walkthrough as majority of the trivial errors will be detected by these tools and they can focus on major logical errors. There are many static code analyzer are available both commercial and open source. FindBugs is one of such open source code analyzer software for JAVA

Coverage types in white box testing

2009-08-24T10:03:00.001-07:00

White box testing generally focus on the structure of the code and find bugs related to the structure of the code like some statement not executed, some condition is never met etc. It is very useful in detecting dead code and unreachable code along with bug which are initiated by execution of particular statement or satisfaction of particular condition.
For test adequacy criteria for white box testing we put some limit on the code coverage like we can state that white box testing is completed when 90% of the statements in the code have been executed. Coverage can be statement coverage, decision coverage condition coverage, or both condition decision coverage or modified condition decision coverage. These coverage criteria are ordered in the increasing power of revealing defects and the no of test cases required achieving them.

Statement coverage: If the test adequacy criteria statement is like all (100%) statements in the code shall be executed before testing is completed then tester has to design test suite in such a fashion that every statement in the code is executed at least once.
This type of coverage can reveal defects in improper assignments or computation but it cannot reveal defect that is originated from a missing statement.
For example we have a code
If (age<65 and married==TRUE)
{
statement1;
statement2;
}
else
{
statement3;
statement4;
}
For 100% statement coverage of this code we need two test cases one for if part and other for else part.
TestId1 age=30 and married=true statement 1, statement2
TestId2 age=70 and married=true statement3, statement4

Decision coverage: This coverage makes sure that each and every branch in the code has been executed. It execute all decision statement like if then else, for loop, while loop and ensure all the outcome of the statement have been executed. It is considered stronger coverage then statement coverage because decision coverage will automatically executes all statements and in addition it also verifies all decisions/branches.
Above mentioned example also satisfies the decision coverage criteria, where TestId1 covers if part and TestId2 covers the else part.

Condition coverage: Most of the time decision statements consist of more than one condition. For decision coverage we only require that the path shall be executed without bothering which condition has been satisfied for that. This can be dangerous when short circuiting occurs.
For example in the above mentioned code, we had 100% branch coverage but it has not shown the effect of the variable 'married==false'. To cover all the condition we have to rewrite the TestID1 as age=30 and married=false. Now in the decision we have two conditions taking all possible values.
TestId1 age=30 and married=false Decision outcome: false
TestId2 age=70 and married=true Decision outcome: false

Condition/decision coverage: In above example, we can see that although each condition has taken all possible outcomes but the decision has taken only one value (not all possible value). To address this problem, we have another criterion that is condition/decision coverage which mandate that all conditions take there possible outcomes as well as all decision outcomes are also taken or all branches are also executed. Taking the above example, we have to write another test case for this.

TestId3 age=30 and married=true Decision outcome: true
By looking carefully we can remove this extra test case by modifying above test cases as

TestId1 age=30 and married=true Decision outcome: true
TestId2 age=70 and married=false Decision outcome: false
These two test cases now will give 100% condition coverage and 100% decision coverage.

Modified condition/ decision coverage: As we can see from above test case, all combinations for all the conditions in a decision are not required in any of the above criterion. Modified condition/ decision coverage mandates that all the possible combinations of the conditions in the decision shall be executed for each outcome of the decision.
For example test cases for the above mentioned code will be
TestId1 age=30 and married=true Decision outcome: true
TestId2 age=70 and married=false Decision outcome: false
TestId3 age=70 and married=true Decision outcome: false
TestId4 age=30 and married= false Decision outcome: false

To identify and write test cases for such criteria we use binary table and assign each condition true/false value and based on that find out the decision value.
100% MCDC coverage is mandatory for the any software which is safety critical of level A according to DO-178B

These are the various coverage criteria in white box testing.

Ten things to include in design of an embedded software

2009-07-20T04:57:00.000-07:00

Software component of the embedded system is different than the normal software. This software has to interact with the environment via interfaces, perform tasks in real time etc. It’s not just lines of code which maps the input domain to output domain. So while designing any embedded systems software one has to take care of some basic fundamentals.

1) Decision making strategy: This should be decided in design itself that what mechanism will be used for decision making. There are various flow controls provided by languages, like if then else, switch statements or lookup tables.Since embedded systems are generally real time systems, it’s always required that the decisions are taken quickly. For that look-up tables are most
efficient way of doing so. Another advantage being added is code becomes more readable and understandable.

2) While designing data structures to be used in code, try to have fixed size arrays.
Fixed size arrays save memory allocation- de-allocation overhead. Also it should be taken care that size of the array is in power of 2. This saves the cost of multiplication overhead which is replaced by simple shift operator.

3) Always byte alignment of the underlying hardware should be mentioned. Whether the underlying architecture is ‘little endian’ or ‘big endian’ should be mentioned so that errors are avoided in coding. There should be explicit padding while defining structures, if the complier
doesn’t provides that, because it reduces the fetch cycles of the data.

4) A state diagram should be provided with clearly identified states and the triggers which are responsible for transition from one state to another. Commands that are to be accepted in a particular state shall bedecided and mentioned.

5) Proper hamming distance shall be maintained between command words so that invalid commands are not accepted as valid commands.

6) There shall be a feedback loop so that the status can be updated or maintained and any glitches in the system can be identified.

7) Always have built-in self test routines so that system starts from correct state.

8) Implement watchdog timer so that if system is in infinite loop, it can reset the system.

9) Limit the use of temporary and global variables as usually embedded systems have limited memory.

10) Se if the functionality can be implemented in the hardware effectively and efficiently.

Four root causes why Code goes haywire?

2009-07-09T09:12:00.000-07:00

Code written by us is not the last one but it will be modified maintained and enhanced by many others. There are many reasons why code becomes unmanageable after some time. In this post I will be considering four reasons.

Root cause 1: Creating libraries of business functions without considering their domain module.
It’s a general tendency to club similar functions together in one library file. For example, while developing a banking application, we tend to write the all interest functions together without worrying whether that interest is calculated on loan or deposit. Loan and deposit are domain modules of the application here.
Another example of the similar mistake can be the reservation system; we tend to write the payment and reservation functions in same file as they are linked but we do not consider that their domain is different.
First of all, it will be very difficult to enhance such systems, if at all, you are able to do some modifications in to that worst effect is seen while performing regression testing. Your small modification will affect many unrelated functions.

Root cause 2: Mixing up the business logic with the presentation logic.
If user is borrower, screen 1 should appear; if user is depositor, screen2 should appear. All these are parts of presentation logic. These decisions shall be handled at the presentation layer of the application without disturbing the business logic.
Your loan calculation function checks whether the call for interest calculation is from batch processing or online is a classic example when you mix the business logic with the presentation logic.

Root cause 3: No proper layering of functions and communication mechanism.
We shall never keep utility function with domain specific at the same layer. For example, the utility function for date formatting shall not be at the same level of a domain specific function like interest calculation. There are general rules which shall be followed:
• Module residing on the same level shall communicate with each other via predefined interfaces.
• Module at upper layer can access the lower level functions but not vice -a- versa.
This will also enable user to put some common part of a function, which is used across the domains, in lower level and more specialized part for the specific domain in the upper layer.

Root cause 4: Not organizing code as per functional domain.
Do not keep all your files at the same hierarchy irrespective of their domain. Always make separate folder for keeping files which are related to one domain. This will improve the maintainability of the system as the code written is well organized.

What is Parameterized Unit Test (PUT)?

2009-07-04T19:25:00.000-07:00

Unit testing
Unit is an atomic entity of any program which performs a specific task and can be tested independently (well almost). To test that unit of a program for its correct functionality is called as unit testing.

For unit tests we have to write unit test cases. Developer themselves write unit test cases for their unit and run those against developed units. Typically, a unit test can be divided into three parts.

Exemplary data: Data which we input to the test case.
Method sequence: Based on the test inputs, this calls several methods of code-under-test.
Assertion: Test case fails if the assertion fails. There is another reason why a test case can fail and that is if exception is thrown but not caught.

Example 1: A typical unit test case.

public void AddElementTest()
{
//exemplary data
int capacity = 1;
object element = null;

// method sequence
ArrayList list = new ArrayList(capacity);
list.Add(element);

// assertions
Assert.IsTrue(list[0] == element);
}

This test case considers a particular array and tests that if one element is added to the array it should be at first place. It does not consider any other array lists and does not test their behavior.

Traditional unit tests do not take input, so the intuition is to pass parameters. Hence parameterized unit tests come to light.

Example 2: Consider the example given below. It is more generic than the test case given above.
public void AddSpec2
(
// data
ArrayList list, object element)
{
// assumptions
PexAssume.IsTrue(list != null);

// method sequence
int len = list.Count;
list.Add(element);

// assertions
PexAssert.IsTrue(list[len] == element);
}
}

This parameterized unit test case is for the whole class of objects and only for single instance of that class. It can be applied to all array lists present in the code and we don’t have to write test cases for each of them.

One other advantage of parameterized unit test cases is that they clearly separate two concerns; to write specifications for the system parameterized unit test cases (PUT) used, can be done by humans only. And to generate test cases inputs which based on the specifications and code written maximize the code coverage. This can be done by tools. PEX is one of a tool which analyzes your code and generates test inputs for PUTs .More on PEX later.

PUTs provide us with ability to specify a system’s behavior on the level of the actual software API and in programming language.

This is all on the parameterized Unit test, in future posts I will be explaining how to conduct PUT using PEX tool.

Which architecture fits your application?

2009-07-03T10:44:00.000-07:00

Client server is not the only architecture your application can be built on. There are many more. You should consider all the alternatives before zeroing in on the one you select. Designing algorithm and data structures for an application is necessary. However, when application size and complexity increase, design problem goes beyond above mentioned things. Designing and specifying system’s overall structure becomes the next task. The structure may include gross organization, global control structures, protocols for communications, synchronization and data access, allocating functional requirements to different components, scaling and performance etc. These are all part of the architecture in which you wish to build your system.
So how to decide which architecture fits your application? For that fist of all, one should know how many types of architectures exist? What kind of application is mine? And last but not the least what kind of requirements I have to fulfill in order to make it a quality application.

I will be explaining architecture styles in series of my posts. Today I’ll be explaining two architecture styles.

1) Pipe line architecture
The characteristics of Pipe line architecture is that there are set of component having set of input and set of output. Component reads input, processes it and gives the whole processed input as output to the next component Components are connected by Pipes. Components are independent of each other and do not share their states. Another thing they do not know about the component upstream and component down stream.

Advantages of the Pipe line architecture
• Allows programmer to see input/output behavior of system as composition of behavior of individual component.
• Supports reuse; any filter can be used any other system needing same functionality as provided by the component.
• Easily enhanced as new filters can be added without affecting the existing system.
Disadvantages
Not good for handling interactive application.
Need of parsing and unparsing the data entering into the component.
Example of such architecture is UNIX command execution. UNIX provides facility to connect two commands through pipes where output of one command is send to other command as input.
Other example would be complier where each component has a specified function like lexical analysis, parsing etc and provides the processed input to the next phase.

2) Event based, implicit invocation
When a component wishes to communicate with other component, it explicitly calls a method of that component. But in some applications we need application to react to events without any explicit calls.

In this approach, instead of calling a method, component registers an event. Other components register their interest into that event and associate a procedure with that event. Now whenever that event is raised by component, all the procedures registered with the event are automatically invoked.
Announcer of the event does not know which component will be affected by the event.

Advantages of implicit invoke event based architecture.
• Easy to extend as new component can easily replace old component by registering for those events.
• Reusability as any component can be used just by registering for the event.
Disadvantages
• No control over the execution of the procedures.
• Problem with data transfer as the component which raised the event does not know when the response will be complete.
Best example of this kind of architecture will be databases management systems which have triggers which are executed whenever a new record is enter in order to check for integrity checks. Debugger in the programming environment also follows the same architecture.

Everything goes wrong if your first step is wrong.Part 2

2009-07-01T05:59:00.000-07:00

Analyzing the requirement was the first step towards the correct requirements.

Second big thing you shall do is to document them properly in specified format.There are many standard templates available for writing specifications. IEEE 830 template is one of them. Template helps you to organize your specification under proper headings and makes sure that you don’t miss any critical specification that needs to be address.Keep functional and non functional, rather performance or quality requirements separate.

After finalizing your template one shall chose tools available for requirements definitions or management. Many requirement management tools are available in the market.‘DOORS’ is one such tool developed by Telelogic, now IBM. These tools help you to keep trace of your requirements in design and test cases. For tracing, every requirement should be given a unique identifier.

Third thing you should keep in mind, when you are documenting requirements, is that no duplicate requirement is included and no valid requirement is omitted from the document. Each and every requirement shall be elaborated in sufficient manner in order to avoid ambiguities. It’s very important that you keep your language simple so that everybody can understand written requirements.

Before you document requirement you shall always consider the feasibility of the requirement under specified constraints. You shall ask yourself questions like what is the risk associated with the requirement, what if this requirement is not implemented, is there any problem integrating this requirement with any other or does it conflict with any other requirement. You shall also consider legal and ethical issues associated with the requirements.

Assign every requirement its priority and user who will execute that. If possible, provide the dependency of the requirement on other requirements.

Finally when requirements are documented.. send it for validation process.

Everything goes wrong if your first step is wrong.

2009-06-30T05:08:00.000-07:00

Any sphere is equal to 4 times the cone which has its base equal to the greatest circle in the sphere and its height equal to the radius of the sphere…..
Did you get that?? …No……Then read this
V= 4/3 pi * r 3 Where V= volume, and r= Radius.
Both statements convey the same message. Which will you prefer? Second,right? Same is the case with software requirements; more are they simple,more is possibility that they are understood and implemented right.

Requirement definition and analysis phase is considered as cradle for any software project. If you make mistake in this phase, it is less likely that you will be correct at any phase of the lifecycle. Impact of poorly expressed requirements can be unmanageable, as they can have domino effect that leads to time consuming rework and schedule and budget overrun.

Defining and creating good requirements is a big challenge that IT industry faces. But what do you call a good requirement? Don’t worry!! Pick up any software engineering book and its there. A good requirement is complete,correct, consistent, clear, modular, feasible, testable so on and so forth.

However, the question arises how to get a good requirement and manage that requirement. First and fore most step is requirements analysis and to document systems specifications. To understand the value of this phase, we must first look into difference between system requirement and user
requirements.

User requirements are usually the first attempt for the description of the requirements, they are not well organized, sometimes ambiguous and some implied requirements are not stated. User requirements are from the business perspective and they define servicesthat software shall provide with specified constraints to enhance the business. They are used by user for acceptance testing.
Example of user requirement for a Library system would be The library system should provide a way to allow a patron to borrow a book from the library.

System requirements are written keeping the system in mind and are detailed explanation of the services and constraints of the software. These are precise, cover all aspects and address quality requirements in quantifiable manner. These are used by developers and designer for developing the system.System requirement for the above mentioned Library system would be The library system should provide a withdraw interaction that allows a
patron to withdraw a book given the ISBN and copy number of the book to be withdrawn. The interaction fails if: the book is already withdrawn, the book is not in the library's collection, the patron has already withdrawn 5 books, the patron owes more than $5, and book is on hold by someone else.Otherwise….. All cases are to be described.

Although system requirements are derived from user requirements they are more structured and complete. So there should be always a phase calledrequirement analysis phase which translates user requirements into system requirements documented in the document called SRS.

This was the only first step that we have discussed in order to getdirection right.
In future posts, I’ll be explaining more techniques to get you requirement right in the first attempt.

Five reasons why not to use global variables?

2009-06-29T03:03:00.000-07:00

Introduction
Global variables are those variables which can be accessed and modified by any module.
They are declared in outermost scope so that they are visible to every inner scope module.

They are usually considered as bad practice because of their non locality.They create mutual dependencies and increase complexity of program.However, there are some places where global variables are suitable to use.When one wants to avoid frequent passing of parameters form one function to another, global variables can be of use. They are used to pass information
between modules that do not share called / caller relationship such as concurrent threads and signal handlers or interrupt routines.

Why they should be avoided when unnecessary
As explained in the introduction section, global variables induce interdependency between modules thus increasing complexity of the code making it hard to analyze it.Here I give you other reason for not to use global variable unless absolutely necessary.

Reason 1: Non locality
Global variables are declared in the outmost scope. So if a function uses it in the innermost scope we have to keep track that whether that variable have been modified before that is been used in the function. Functions are easy to analyze when their variables are localized and have minimum influence of other modules over them. If you code is large enough, then another problem called thrashing (related to paging in OS) may occur (only if there is no spare memory left) while executing your code as the variable and code may be on different pages.

Reason 2: Implicit coupling
Coupling between modules of the code should be as low as possible in order to make it maintainable in future. When you use global variables in code,they induce coupling between modules.

Reason 3: Concurrency issues
This case arises when your application is multithreaded. If more than one thread try to access the same variable at the same time, which might result in deadlock situations. Special precaution should be taken to avoid such situation resulting in extra code. We have to implement lock and unlock functions to ensure single thread access to the global variable. There may
be a possibility that threads get obsolete values.

Reason 4: No access control or constraint checking
Global variables can be get or set in any part of the program without worrying about the rules to access them as there are no rules. This greatly hinders security when you are using third party tools.

Reason 5: Difficult to test
Code which use global variables are difficult to test as there is no easy method to set a clean environment between run. It will be very difficult to test modules in isolation as Unit test suggests. There will be some implicit effect of other modules on the module in form of global variables, so it will be difficult to pin point and debug code.

These are five reasons why you should avoid global variables as far as possible.

Why we need code walkthrough when we have testing in place?

2009-06-26T22:02:00.000-07:00

Background
There are many techniques employed to build confidence that your software works correctly. Code walk through is one of them. It is considered by many as “waste of time” and argued as “when we have testing in place why to go for walkthrough?” When deadlines are to be met, developers tend to avoid this phase. But in this post I will be explaining why you should have code walkthrough before you send your code for testing.
Before that there are some facts
HP found 80% of the errors detected during inspections were unlikely to be caught by testing.
HP, Shell Research, Bell Northern, and AT&T all found inspections 20 to 30 times more efficient than testing in detecting errors.
IBM found inspections gave a 23% increase in productivity and a 38% reduction in bugs detected after unit test.

Reason 1: Testing cannot be exhaustive
Before we go for the reason, let me explain the difference between fault and failure.
Fault is any programming or design bug that is present in the software.
When fault is activated, it results into failure. Not all faults result into failure all the time.
Testing cannot be exhaustive, that is, each and every condition and path in which software will be executed, cannot be explored. So there may be some faults that are not activated in testing and gone undetected to customer end. Faults found at testing are only subset of the faults present in the software. To detect those inactivated and potential faults we have to rely on the code walkthrough.

Reason 2: Maintainability
Testing only concentrates on the functional and performance requirements conformance. It never considers that how software has been written, if it works and satisfies requirements. However, when software has to be maintained (either perfective, enhance or adaptive) in future, one has to deal with code and if code is not written in legible and understandable manner, every thing goes for a toss. Code walkthrough ensure that code is written in way that future modification can be done by any programmer, there are proper and adequate commenting, function and variable names are self explanatory and coding standard are followed, which are not done in testing.

Reason 3: Reuse of the code
In my opinion reuse is a hyped term. We seldom use piece of code in our software in effective manner because either we are not aware that such an item is available of the self or we are not able to understand that code. If code walkthrough are conducted then other (committee members) come to know that such an item is available of the self, if required in future, as well as they have very good understanding of the software in the hand. So their knowledge can be handy in future when some other developer wants to reuse the same code in his software.

Reason 4: Effectiveness
A well conducted code walkthrough can produce stunning results. According to paper by Jack G Ganssle, IBM manages to remove approx 82% of the bugs before testing. Each bug found at code walkthrough saves 9 hours of development time down the lane. Cost incurred is very much low when defect is detected in code walkthrough phase than found in the testing phase. Finally code walkthrough adds value to your code.

So don’t consider it a “hassle factor” and opt for code walkthroughs.

CMMI Organization

2009-06-26T06:05:00.000-07:00

In the series of CMMI posts this is the last article and in this I will be explaining how components of the model have been organized.

At the top, in a particular maturity level, there are various process areas which are to be satisfied by organization, to be at that level. For example an organization at level at 2 shall satisfy requirement management process area, planning project, process and product quality assurance etc. I will explain requirement management process area in all examples below.

Below process areas, there are goals; goals can be classified in two namely, specific goal and generic goals. Specific goals are goals which are to be achieved in order to satisfy that particular process area; while generic goals are required by many process areas and have organization wide presence.

For example in the PA1 there is specific goal (SG1) “Requirements are managed and inconsistencies with project plans and work products are identified.” This is specific goal as it has to be implemented to satisfy only PA1 and not any other PA.

Same PA has generic goal (GG2) that says “The process is institutionalized as a managed process”. There can be many other processes which can institutionalized as this PA so that’s why this is a generic goal.

Specific goals are further divided into specific practices and generic goals in generic practices. Below generic practices, there are generic practices elaborations which are guidelines to implement generic practices.

For example, SG1 has a specific practice (SP1.1) “Develop an understanding with the requirements providers on the meaning of the requirements.”

Generic practices are categorized into four groups and those groups are called as common features as explained in the previous post.

For example under the common feature “Commitment to perform” there is a generic practice (GP 2.1) “Develop an organization policy.”

Again these practices (Specific or Generic) constitute of various activities listed as SP1.1.1 and so on or GP1.1.1 and so on.

So this the basic organization of the CMMI model also explained in the figure given.

Model components

2009-06-25T05:10:00.000-07:00

Yesterday we had discussion about CMMI, its representation and what different maturity level. Today I will be discussing different terms used in CMMI and how those terms form the complete standard.

Process area: Process area is collection of best practices which when performed collectively; satisfy certain goals which are considered important for process improvement.

Specific goals: These apply to a process area and address the unique characteristics that must be implemented in order to satisfy the process are. These are required model [1] component.

Specific practices: These are activities to be completed to achieve specific goals of a process area. These are expected model [2] component.

Generic goals: These are generic because the same goal statement appears in multiple process areas or they have to be fulfilled to satisfy process area.In staged representation each process area has only one generic goal.Achievement of the generic goal signifies the control and improvement of the process. These are required model [1] component.

Generic practices: Generic practices provide institutionalization so that processes associated with process area are effective, repeatable and lasting. Categorized by generic goal and common features explained below.These are expected model [2] component.

Common feature: These are not rated component. They are just a way of grouping generic practices. There are four common features as given below with their abbreviations
1) Commitment to perform (CO)
2) Ability to perform (AB)
3) Directing implementation. (DI)
4) Verify implementation (VI)

[1] Required model component: These components must be achieved by organization’s planned and implemented process. These are essential to rate any organization.
[2] Expected model component: These are components which organization will typically implement in order to achieve require component.

Do you know CMMI? Think again

2009-06-24T01:51:00.000-07:00

What is Capability Maturity Model Integration?

Model
Model is simple representation of real world. It shows overall picture of the thing without going into intricacies of it.
Maturity
Definition varies form one to another but generally mature process is considered to be well defined, analyzed and repeatable along with being effective.

According to the SEI, CMMI is a framework for management, engineering,support best practices organized into 25 topics called process areas.
Other definition may be it is integrated model (many models like CMM software, CMM system engineering, CMM People and many more are integrated into it), which provides a framework to be used by organizations to improve their processes.

CMMI has two representations namely staged representation which all we are aware of, and continuous representation slightly unheard term.
Let’s talk about what is difference between two.
One major difference is staged representation talks in terms of maturity levels with five maturity levels, where as continuous representation talks in terms of capability levels with six capability levels.
In staged we just achieve two generic goals to reach at the top level while in continuous representation we have to achieve six generic goals (What are generic goal is topic of next post).
In staged representation process areas are group together in levels that means if organization is at this level it shall conform to all process areas at that level, while in continuous representation process areas are divided into four groups namely process management, project management, engineering and support.

Now I will briefly discuss what five maturity levels one by one
1) Initial
No process is being followed and success is matter of heroics of one person. Past success cannot be repeated.

2) Repeated
Some processes like requirement management, project planning is defined and past success can be repeated and ensures that practices are retained at the time of stress. Mile stones are defined and work products are visible to management at those points.

3) Defined
Processes are well understood and defined in standards, procedures, tools and methods. Processes are consistent across the organization and project can define own standard by tailoring organization set of standard according to tailoring guidelines. Difference between level 2 and 3 is that scope of processes and standards. At level two every project has different standards and processes. At level 3 standards, process, methods are established at organizational level.

4) Quantitatively managed
At this level quality levels are established and used as criteria for managing the processes. Quality and process performance is understood in statistical terms and managed throughout the life cycle of the project.
Special causes of variations are analyzed and steps are taken to prevent their occurrences. Decisions are taken based on fact and not at whim.
Difference between level 3 and level 4 is process predictability. Processes are qualitatively managed at level 3 where as at level there are managed quantitatively.

5) Optimizing
It focuses on continuous process improvement using innovative technologies.
Process improvement objectives are established and used as criteria for managing the processes.
Process improvement addresses common causes of variations.
Difference between level 4 and level 5 is that level 4 addresses special cause of process variation and provide statistical predictability for the process, while level 5 addresses common cause of variation and strive to achieve established quantitative process objectives.

That’s all for today, tomorrow I will discuss, what are the terms used in CMMI like generic goals, specific goals, generic practices, specific practices, common features etc, and how the standard is organized with these terms.

How do you know your software is quality one?

2009-06-23T05:48:00.000-07:00

In my last post I discussed three quality attributes mentioned in ISO 9126 and explained how to measure them. Today I will be covering rest three.

4) Efficiency: According to ISO 9126 efficiency is set of attribute that bear on the relationship between the level of performance of the system and amount of resources used, under stated condition. Efficiency is very much important for software otherwise the whole purpose of software goes in vain.
There are three sub attributes given for it

A)Time behavior: How much time does it take to respond to your action?
B)Resource utilization: Does the system uses system resources efficiently?

Measuring efficiency is some what easy as compare to other attribute. You can easily measure ‘Time behavior’ sub attribute without any tool like you can easily say whether system is responding in time or not, is it slow or not?
For measuring resources utilization there are some standard tools available. Memory utilization can be estimated while performing code walkthroughs of software.

5) Maintainability: It is set of attribute that bear on the effort needed to make specified modifications. All though maintainability is a subjective term but it can be said that it’s inversely proportional to the size of the code and complexity of the software. Many other metrics can be used for assessing maintainability of the software like cyclomatic complexity, coupling between modules, language used and coding, code to comment ratio etc.
There are four sub attributes for it

A)Analyzability: Can faults easily diagnosed?
B)Changeability: Is software easily modifiable?
C)Stability: Is software stable i.e. it does not stop functioning if changes are made?
D)Testability: Is software testable?

Measuring maintainability directly is a tough job but indirectly it can be related to many metrics as explained above.

6) Portability: It is asset of attribute that bear on the ability of software to be transferred from one environment to another.
There are four sub attributes

A)Adaptability: Can software moved on to other environment without affecting functionality?
B)Install ability: Can software be installed on any system easily?
C)Conformance: Does software conform to portability standards?
D)Replace ability: Can software easily replace other software?

Portability cannot be measure easily. But by measuring some other thing we can deduce the portability of the software. For example we can measure no of function to be changed in order to make software work correctly on other environment.
Portability will be inversely proportional to ratio of No of functions changed to Total no of functions.
These are six quality attributes and some measuring techniques to gauge our software’s quality.

How do you know your software is quality one?

2009-06-20T22:46:00.000-07:00

We all talk about having quality in our software. How to measure that quality? What are various metrics we should measure in order to say that our software is a quality software?
What should an acquirer specify to supplier to ensure development of quality software?

All these questions were answered in ISO 9126 quality standard. It contains all the quality requirements of software with minimal overlapping. But that is a theoretical part of it and some of things which it specifies are very difficult to measure, if not impossible.

So let’s discuss various quality attributes and their sub attributes and also explore how to measure them for particular software.

1)Functionality: It bears on the ability of the software to fulfill all functional requirements, stated or implied.
It has four sub attributes
a)Suitability: Can software perform the task expected of it?
b)Accuracy: Can software perform task in a correct manner?
c)Interoperability: Can software interact and work with other systems?
d)Security: Can software prevent unauthorized access to it.
We can easily measure this attribute as everything is visible and objective in nature. Either your software is accurate or not; either software secure or not. Every sub attribute can be measured directly and hence the main attribute.

2) Reliability: As per ISO 9126 STD definition of reliability is capability of the software to maintain its level of performance under stated conditions and stated environment.
It is further divided into three sub attributes:
a)Maturity: Has bug rate decreases as the software matured and comes to an acceptable level?
b)Fault tolerance: Does software has ability to avoid exceptional conditions and can avoid error states?
c)Recoverability: Does software has ability to resume work from the point it left when crashed or gone offline?
There is big question? Is reliability quantifiable? Can we measure it or at least predict it.
In best of my knowledge there are some models which can predict reliability but quantifying reliability is still a big NO. Reliability is very subjective in nature. Reliability for a e learning system may have totally different context than reliability of a on board system integrated with rockets.

3)Usability: It’s a set of attributes that bear on the effort required to use the software by stated or implied user.
There are four sub attributes
a)Understandability: Does user understands how to use the system?
b)Learnability: Can user learn how to use the system?
c)Operability: Can user operate the software without any special efforts?
d)Attractiveness: Is the user interface good?
It’s totally subjective in nature. Software which is very much usable for me may not be same for you. But still you can measure the attribute by measure some of its sub attributes. Like on can measure understandability by saying
Understandability = no of functions understood by user/ Total functions
Learnabilty can be measure as how many days does it take user to be well versed with the software? In this we can quantify usability

Not stretching my post more, I will stop here, will write three more quality attributes stated in ISO 9126 tomorrow.

We don’t think of V Model!

2009-06-19T22:13:00.001-07:00

I assume that readers are well aware of all other life cycle models like Water fall model, iterative and incremental model or spiral model. If not please go through my second post and then you can continue reading this.

All of the above mentioned models have some thing is common and that’s test after you build. That means you never worry about testing until you reach testing phase. But the cost and effort required fixing a bug increase exponentially as we move from planning phase to testing phase. So it’s advisable that u start testing activities as soon as possible. So there came a model which runs testing activities in parallel with development activities. Like you plan acceptance tests as soon as you get user requirements or unit tests as soon as component is build.

Various phases:
V model explains relationship of each phase of development cycle to its associated testing. Now let me explain what the relation is;

First of all we have requirement specification, so while finalizing requirement specifications we also finalize what all we be the acceptance test cases and perform acceptance testing as per those cases.

Next we translate requirements into system specifications and define various functionality that system shall provide and performance requirements that to be met.
So we can easily make test cases that shall be passed in order to say that system is functioning as per expectations and meeting performance requirements. So we design system test cases and perform system testing accordingly.

Once we are done with system specification, we ponder upon system architecture and design. What architectures to be considered is issue of another post. (It’s not all about server client). While deciding architecture and design we from systems integration plan and interface test. After developing components in which system is decomposed, we go for integration as per the plan and test case produce while designing.

Finally we decomposed our system into smaller components and start developing them, to test these individual components we write unit test cases.

As soon as we are finished with development, we are also done with half of the testing work. Now we just have to test components, interfaces, and system. That’s all as we have already produced test cases for each of this things wok will be easier and testing will be more accurate and bug oriented.

Various advantages that you achieve while using V model are Minimized project risks, improved quality, minimized cost and shorter life cycle period, and effective way of communication between stakeholders.

Deep into abstraction

2009-06-18T05:18:00.000-07:00

Do you know why IBM USB supports any pen drive you enter in it?
Answer is in this post¡K read on!

There must be technique or method by which lower level implementation can be hidden. There must be some thing that can be used by all the pen drives you have, so that all of them can be compatible with the USB.

Yes I am talking about abstraction and interfaces!
Oh my God! Both are the same thing¡K what to worry about! Use whatever you want on the day and be happy :) Why to worry?

No they are not the same; there are clear differences between these abstraction methods.

Abstract classes:
These are classes which contain variables and prototypes of the functions which are to be implemented by derived classes.

Interface:
These are collections of some functions that are to be implemented by the class which implements them.

Confused! What's the difference? Here are the differences:
Abstract class gives identity to the derived object like 'Object A is ' where as interface gives the capability or property to the object. Object B can sing or has salary.

The major difference is that abstract classes can have some functions implemented while interface can not have any implemented function just prototypes. Although both them cannot be instantiated. Other difference is that you can implement abstract class that you have inherited partially but you have to implement each and every function of the interface that is
implemented by your class.

One more difference is regarding the maintainability. Later on you find that there should be some change in interface you have already implemented in 50 classes? What? Go and change in 50 classes. While if you using abstract class you have to make change only at the one place. That means one should not use interfaces at any time? No. That's not the correct thinking. Consider an example; I have an abstract class Person

Abstract Class Person
{
String Name;
String gender;
Int age;
String Occupation;
Int Salary;
String qualification;
String companyName;
getName();
getGender();
getAge();
getQualification();
}

Now I decide to inherit this class in class called salaried person. And I implement this class! So far so good! Now I want to have a class Student. Student has many properties matching with salaried person and I decide to inherit the same Person class. But wait what I shall do with the extra fields and functions that are forced on me?

Interface comes to my rescue. I can have an interface, interface_common, where getName().getGender() and getAge() can be put. I can create another interface interface_diff, that can have getQulification() and getSalary().
The abstract class can implement the interface_common and the more specialized interface_diff can be implemented by the class salaried person.

Hence interface has given us opportunity to reuse the same functions without have extra information loaded with our derived class. Consider two objects totally different but having single function in common. You will be clearer when to use interfaces.

Now coming to our original question why IBM USB supports any pen drive you enter in it? Because there are some interface decided and every pen drive has to implement those in order to get recognized. So interface are again at your service!

Confusing testing techniques :(

2009-06-17T10:08:00.000-07:00

There are a plenty of testing techniques ranging from ad hoc monkey testing to moral formal unit testing. White box testing, black box testing, Grey box testing and so on so forth. Being under graduate in software engineering or fresher in software industry, you may always confuse between one testing and other.

So let’s explore some of the most confusing and interrelated terms used in testing terminology;

1) Sanity testing and smoke testing

Sanity testing is a testing technique in which you take a specialized functionality of the whole system and travel deep into that and try to find out if the that functionality is working correctly in every aspect. Actually it follows depth first approach.

Smoke testing is testing technique in which you just check broadly whether the system in question worth testing. The scope of the test is whole system and follows breadth first approach.

Smoke testing is generally used in hardware testing, if hardware component produces smoke as soon as it is put in test that means that the component is not yet ready for testing and require more time. Same principle is applied to software too.

2) Regression testing and Retesting

When you fix a bug in code and you want to be sure that this fixing has not affected any other part of the program you re run all existing test case again

This is called regression testing.

Retesting is process in which we write different or more test cases for the same functionality in order to test it completely and satisfactorily after there has been testing with existing test case.

3) Load testing and stress testing

When you test a system for its robustness, giving inputs within the allowed range this is called load testing. For example if an application has to support 500 users, load testing will be done with simulating 500 users and noting the performance degradation of the application.

When you test a system for its robustness, giving inputs which are out of bound or beyond the scope of the system, it’s called stress testing. Like if your system supports only 100 users, and you simulate 110 users and see how the performance of the system degrades.

4) Integration testing and interface testing

When you combine two components that are independently developed you need to test that these two components work correctly together and perform the task assign to the integrated component in seamless manner. To test this you do integration testing.

When there is communication between two components, protocols and message formats are define to communicate. Interface testing confirms that the data passing from one component to another is in the correct and in specified format and follows the protocol decided upon. Whether two components perform the correct task is none of the concern of interface testing.

Hope after reading this post your doubts, about slightly different and confusing testing techniques, may have vanished.

IEEE Std 12207.0

2009-06-14T09:06:00.000-07:00

We talked about models in the last post,but what are the processes which are to be followed inside those models? There are various standards available and can be applied to the model as per the organisation. The most accepted and flexible standard is IEEE std 12207. It is in three parts 12207.0,12207.1 and 12207.2.
First one discusses various life cycle process, second deals with data and metric collection during life cycle and third is to help/ guidelines for implementing the standard.

We will discuss here 12207.0 std.
These standard discusses life cycle process to be followed. It recommends total 17 processes in three categories :
Primary life cycle processes : Acquisition, supply, development,operation and maintenance (5)
Supporting life cycle processes :Documentation, Configuration management,verification, validation,review&audit, and problem resolution.(8)
Organization life cycle processes: Training, management, infrastructure and improvement.(4)

These 17 process are divided into activities and these activities are divided into task.

For the development phase it recommends following activities:(in brackets given the output of the activities)
1) Project management and development plan preparation (PMP/PDP)
2) System requirement analysis (SRD)
3) System architecture
4) Software requirements analysis (SRS)
5) Software architecture (SAD)
6) Software designing (SDD)
7) Code and testing (Code and executable with designer level test cases and test results)
8) Software integration (Integrated software)
9) Software qualification test ( Test results)
10) System integration (Integrated system)
11) System qualification test ( Test results)
12) Delivery

These are various activities to be performed when you are involved in development activities!!
Of course, these are not mandatory for all systems developed and IEEE 12207.0 gives an Appendix for guidelines to tailor this standard as per your need.
Check out which of these activities are performed in your company and see what kind of standard does it follow(if at all it follows one :-))!

Agile Model

2009-06-13T09:06:00.000-07:00

We all know we have some standard traditional models that we follow when we develop any system.Water fall model, Rapid development model, incremental and iterative model , Spiral model to say some. Each model has its own advantages and suitability to particular project.
We follow Water fall model when we are sure that requirements are not gone to be change, at least not frequently,Incremental and iterative model when we are not sure what user really wants and there is possibility of putting system in operation with limited functionality, Spiral when we are planning new technologies in project or risk associated with the project are high.

These are all traditional methods of software life cycle. They follow a predefined path in the development task like requirements and design should freeze once project goes for testing. Testing phase starts only after development has finished excluding the developer level unit testing.

Now a days systems are so much complex and huge ; so much schedule constrained that applying traditional model will not produce as per expectations. Water fall model is to rigid to incorporate changes which are now synonyms with software; Incremental and iterative model requires lot of communication between stake holders and developer that take time and remember the saying in our industry "customer wanted it yesterday".

So keeping all these things into mind industry needed a model which is light weight, easily understandable and has desirable properties of existing process models.Agile was the answer!!

In Agile model we focus on iterations; each iteration not more than 2-3 weeks. Iteration consists of three phases requirement collection;design; implementation; test; feedback and again requirement collection. Requirements are not very formal in nature and generally are user stories(What are user stories we would talk later). After completion of each iteration team's internal meeting is conducted to track the progress and stakeholder(which is appointed by client in the organization itself) is invited for feedbacks.

Agile concentrates on four major parts of any development:
Leadership encouraging team work, self accountability and self organization; set of best engineering practices , disciplined project management and business approch aligned with customer needs.
Clear advantages of the model are that user is involved in every stage of the development and changes can be incorporated at any stage i.e flexibility. Only disadvantage is that it cannot be used when size of team is very large.
eXtreme Programing (XP) follows this model.

Half life

2009-06-12T09:11:00.001-07:00

IEEE/ACM Software engineering code of ethics says: Software engineers shall participate in lifelong learning regarding the practice of their profession……They shall continually endeavor to further their knowledge of developments in analysis, specifications, design, development, maintenance and testing of software…., together with the management of the development processes, to improve the their knowledge of relevant standards and laws governing the software and related documents.

That's not just code of ethics but its a way of survival in an industry which changes at whim for better, of course. Things which were very much ahead of their time are now obsolete, things which were thought as domain of software experts are now taught in undergraduate courses. If you just pick up any software technical magazine dated 10 years back, you would be surprised to see technologies, which are considered obsolete today, mentioned on cover page.

Phlliphe kruchten professor of software engineering in University of British Columbia says that half life of any software engineering idea is 5 years. That means what we studied five years back , half of that is, already, not of use. So we need to update ourselves.
In any interview we face, take it granted, this question would always be asked "Which technical journal or book did you read in last six months?" And if answer is none you can imagine your chances in interview.

Somewhere I read that you are what you read. So i have also started reading books, papers and technical journals. I know all you people working in MNCs are too busy to go through all these things. To provide you latest updates in our industry I have thought of this idea. I will be blogging daily and giving you relevant material on software engineering and software design.