Lining up the support structure at the start of a cycle with firm commitments ..

During the course of a software project, you need the support of a number of people. For those who are not so well versed with the various challenges involved in project management, handling the support and resources from outside the core team are one of the biggest challenges during the early stages of the project, during the middle of the project, and during the later stages of the project; which only means that handling the various supporting teams is one of the biggest tasks during a project cycle.
So consider the starting time of a project. The features that are required for the project to succeed have been generated (including the trade off about the ones that are critical for the project vs. the ones that can be cut when there are schedule risks), and there is a need to ensure that there is a formal kick-off for the project. What do you do in a formal kick-off ? Well, one of the key items is to ensure that the team knows what the project is about, what are the key features that will be there in the project, and other such details. Typically the product manager will give a presentation to the team about the aim of the product, the market, the revenue earned by previous versions of the product and the target for the current version, and a high level description of the features that are sought to be included in the project. For many of these features, the further detail that the product manager can give is about how these features were derives, whether these be from competitor analysis or specific requests by customers, or generated based on ideas by the team.
However, as part of the initial kick-off, there are many other discussions that need to take place. For making the software development project successful, there is a lot of support that is needed from other teams. There are teams that prepare the build and the installer, there are teams that work on the documentation and help files, there are teams that deliver components that are required for specific functionality in the product, there are teams that work to translate the product in other languages. Most modern organizations have these kind of dependencies; it is no longer possible to have a situation where a single team does everything that is required for the team (for example, if you have a product that uses video formats, you would rather be using a common component that uses different video codecs to work with these formats rather than write code for working directly with these video formats (it may not even be possible to write code for all these video formats due to technical and commercial limitations)).
It is easier to ensure that you have the support of your core team and more difficult to ensure that all these supporting teams are providing the required support. For this purpose, before the kick-off, you would need to work with all these teams, providing them details about your requirements and the schedule in order to get a commitment from them (in some cases, where there is a clash due to priorities for support, you may need to escalate before you can get the desired commitment). In all cases, unless you can get the required level of support from these teams in terms of commitment, your project is already at a certain amount of risk that you will need to manage in one way or the other.

Designing the same component to work with multiple product versions ..

Modern software applications have learnt to depend on the usage of multiple components as a part of their architecture and design. These components can be used for different functionality, typically specialized functionality that is either difficult for the developers of the product to write, or impossible because of some technological constraints (for example, for working with several video formats, the most feasible way is to use components provided by 3rd parties because they have the technology to read the codecs used and allow the product to work with these video formats).
When you consider the case of products that go through several versions, the components that they use may be the same across versions, and the component may follow a schedule that is different from that of the product. Hence it is even possible that 2 different versions of the product follow the same component; conversely, you would have the case where there are multiple versions of the components that are available, and for business reasons, it makes sense to allow only specific versions of the product to work with a specific component. Consider the following case:
Product released version 5 in 2012 and version 6 in 2013
The component used was version 2 in 2012 and version 3 in 2013
In many cases, the newer release of the component may contain some important new functionality for which the organization would want the users to upgrade to version 6 of the product and would not want the user to be able to take the version 3 of the component and use it in version 5 of the product. This may seem odd, but it makes perfect business sense to follow such a strategy to also drive sales of the newer version of the product.
Given the continuity of the software cycle and the need to avoid making unnecessary changes in software, the easiest way of implementing such a functionality is by asking the product to pass on the version number (along with other parameters which would be required for the smooth integration of the product and the component); there would be code in the component which will check for the version number of the product and work accordingly. This in my opinion is one of the most elegant ways of implementing these kind of checks; the advantage of such a system is that it also supports a system whereby the same component can display different functionality based on the product version where it is being used. So, you could be having a trial version of the product, which passed on the parameter related to the trial nature of the product, and this ensures that the component behaves in a different manner (for example, reading such a parameter could ensure that the component allows the user to view the video file but not make any changes in it, while somebody who has the paid version of the product could both read the video file and also make changes in it - and all this can be done through the same component).

What work does the testing team do at the start of a cycle - some answers

This post arose out of a question that a new manager of the team had for us, the middle management of the team. His basic question was that in the initial part of the cycle, where there were the requirement being framed by the product manager or the product management team (depending on how large the product was), and these requirements were being broken down into smaller features and tasks for the purpose of estimation. Even after this, there was the period where development of the features was happening, and this would be done by the development team who would finally deliver the required code to the testing team, and they could start testing. So, what was the role of the testing team. For the moment, this question was not meant to figure out what to do with the excess testing team at these periods of time, instead it was meant to understand the role of the testing team across the duration of the project cycle, from the beginning to the end. And there was a lot of understanding of what happened when the testing team got the features from the development team, but not in the initial parts of the project.

We had a detailed discussion with the manager about this, and helped him understand this from the perspective of the team. The first essential part was that the testing team did not just do testing, so we should call them them the QE team. Testing was what people saw them do, but there was a lot more work that they did. We finally walked him through a list such as this one below, and if you do not some do some of these in your team, maybe you can get some tips from here. And if your team does other work, then please share these in the comments.

- The testing team is an essential part of the breakdown of the features into tasks and also with the estimation. Members of the testing have an incredible knowledge of the features and the workflows because of their testing of the features on a regular basis; this knowledge can be more than the developers and the product management. So if there is a feature discussion, the testing team can help figure out the workflows that are impacted; in one case I saw the QE member causing embarrassment to the product manager when the QE pointed out that the workflow that the product manager was advocating could be done in much less change than what the product manager was advocating. After that, the product manager made sure that the QE team was involved in all such discussions.

- There are numerous cases when the previously released product needs a patch or a dot release. In such cases, the actual development change can be very small, but the testing of that patch or dot release can take much more time, and need many testing team members for one or less development team members.

- When the team is developing automation for testing, the initial time period of the project cycle helps give them a time required for developing automation scripts for features that are already released (and the automation ensures that the testing of these features takes less actual testing time and more regular automation runs).

- When the developer is busy doing the coding, that is the time when the QE team member finishes up writing or modifying the test plans and cases.

- During the design process of the feature, typically the QE team members plays an essential role, working with the product manager, the workflow / UI designer and the developers to work out the actual details of the feature in terms of implementation. This can take many iterations if the feature is complex, and in my experience, in many cases, the QE team member has pointed out several intricacies of current implementation that need to be taken care of in the design.

Designing software so that features can be stopped at a later point of time ..

Not sure whether the title of the post made sense, so am going to add more details right here. Let us take the case of Lisa, the user of the software. The software does greeting cards and allows users to take their own photos and add texts and the like. Now, some years back, the software had a facility that allowed users to take their final creations and save them to Yahoo Photos (which existed many years back, but does not exist now, especially after Yahoo had bought Flickr). In later versions of the software, the makers of the software would have removed this link to Yahoo Photos and modified the usage to point to some other site where photos could be hosted under a free account.
However, like most other users, Lisa does not upgrade her software application every time a new version of the application is created. So, even though the software in later versions is upgraded, every time Lisa uses the features in her software which connects to Yahoo Photos, some problems may occur. It could be that the error is something which makes sense, or it could be an error that makes no sense to Lisa, or it could be that the API call failing is something that is not handled well within the software and could even cause the software to crash whenever Lisa tries uploading photos to Yahoo Photos, which would not be a very good experience. In fact, in most of these cases, the experience that Lisa faces is not something that is a good user experience, and can cause dissonance and dis-satisfaction at the hands of Lisa.
For makers of commercial software, such a situation is very harmful, and yet you will find a number of software makers who are not ready to handle such a situation. And when you are trying to get your customers to upgrade their software, such problems are going to make it more unlikely that customers would appreciate the experience and want to upgrade. So, what do you do in such a case ?
Well, it is pretty important that the design of the application is done in such a way that features can be turned off later. So, the way to do this is to by making each such dependent feature call into a specific web site and ask for a specific parameter. If the parameter is a go, then the feature will launch and the user will get that specific feature. At the same time, if the parameter is a no-go, there would need to be some error handling that will inform the user about the problem, and also alert them about a web page where they would need to go for more instructions on what to do, and they can also be provided an explanation. Such a technique ensures that users do not feel that they are running into errors that cannot be handled. The beauty of this type of handling is that even if this problems comes in a product version that was released many years back, you can still go ahead and ensure that the users do not face major errors; and in fact, if the functionality is important to your users, you can inform them about the problem and that it has been handled in the latest version and show them an upgrade path.

What is static testing and what are its components ?

What is static testing? Static testing can be defined as a kind of software testing methodology in which the software is tested without actually being compiled and executed. Therefore, static testing is just the opposite of dynamic testing where the software is compiled and executed and then tested. Static testing does not goes into the detail of the software application but, checks for the correctness of the program or source code, document and algorithm. Basically syntax of the program is checked in static testing.
It is done manually by a team of professionals and qualified individuals in the concerned field. Major errors can be found out using this methodology. The writer of code himself/ herself can review the source code to check out for errors. There are many techniques followed for static testing. But the most commonly used ones are the following:
1. Code inspections
2. Code walk through and
3. Code reviews
From the idea of black box testing techniques, we can say that the review of specifications and requirements forms an important part of static testing. This is also done manually, though this is a tough task. Static testing forms the verification part of verification and validation. Nowadays there are some methodologies available by which static testing can be made automatic. This an be done by passing the software code through a static testing test suite that consists of a compiler or an interpreter which checks the software code for verification and syntax errors. Errors found during static testing are much easier to correct than the ones that will be found later. Professionals handling static testing are typically testers and application developers. Static testing is only concerned with verification activities.
While carrying out static testing for software applications certain standards are followed which are namely, standards for integration, deployment and coding. Usually static testing nowadays is done by some automated program or a tool. The analysis done manually by professionals is commonly known as program comprehension or sometimes it is called program understanding. The quality of analysis varies from professional to professional. Some analyze software part by part while some take the whole software code into consideration. Nowadays reverse engineering and software metrics are considered to be methodologies of static testing. Static testing is popular when it comes to the field of verification of the software code, computer systems needing high safety and location of potentially harming code.
Static testing also involves some formal methods for analysis. In formal methods, the analysis result for a software code is usually obtained by carrying out some rigorous mathematical calculations and methods. Following are some mathematical methodologies that are used under formal static testing:
1. Axiomatic semantics
2. Denotational semantics
3. Operational semantics and
4. Abstract interpretation: this technique is based on the idea that every statement executes based on its mathematical properties and values of its declaration. Out of all this technique can be regarded as the best technique.
There are some other techniques apart from mathematical techniques that can be used for formal static analysis. They are called implementation techniques and have been listed below:
1. Model checking: this technique takes into consideration the finite state of the system. If the system is not in finite state, it is made finite by using the technique of abstraction.
2. Use of assertions
No matter how many methodologies we may use for static testing, there will always be some uncertainty of the execution of the program and flaws. It cannot be said that after static analysis the program will execute 100 percent properly.

Some related books:

Backward compatibility for software applications, what does this mean ?

Backward compatibility can be defined as the quality or ability of a device to work well with input generated by a device of older technology. For example if the latest version of a music player can still play music of old formats and types, the music player is said to be backward or downward compatible. The best examples of backward compatibility are given by communication protocols. Forward compatibility is just the opposite of backward compatibility.
In the context of programming languages, a programming language is said to be backward compatible if it’s compiler of version “a” is able to read and execute the source code or programs written in the older version of the same language compiler i.e., in the version “a – 1”. A technology or an IT product can be called a backward compatible device if it properly and equally replaces the older device of the same kind. Even a particular kind of data format can be stated as backward compatible under the condition that the program or message written in that format is still valid under the improved version of the data. For example, the newest version of Microsoft Word should be able to read documents created by previous (could be many years previous) versions of Word.
Backward compatibility can be looked upon as a relationship between two devices having similar attributes. In a layman’s language we can say that a device is called backward compatible if it exhibits all the functionalities of the older device. In the relation of backward compatibility the new or modern version device is said to have inherited all the attributes of the older one. If it does not have those qualities, it cannot be called as a backward compatible device. There are two types of backward compatibility. They have been discussed below:
Binary compatibility or level- one compatibility: It can be defined as the ability of a program to work well directly with the new version of the compiler of the language in which it has been written without its recompilation or modification.
Source compatibility or second level compatibility: it can be defined as the ability of the program to work well and effectively with the new version of the compiler of the language in which it has been written, but, with recompilation of the source code and also with condition that the source code should not be changed.

Many programs and devices use various technologies to achieve backward compatibility. “Emulation” is one such technology. In emulation, the platform of the older software is simulated into the platform of newer software and thus providing backward compatibility. There are so many examples of backward compatibility available. A few have been listed below:
Blu ray disc players can play CDs and DVDs.
Newer video game consoles are able to support games which were created for preceding video game consoles like Atari 7800 and Atari 2600, game boy advance and game boy systems, Nintendo DS and Nintendo DS lite, Nintendo 3DS and Nintendo Ds and Nintendo DSi, play station 2 and play station 3 and play station, PSP and Psone, PS vita and PSP, Xbox 360 and Xbox, wii and Nintendo etc.
Microsoft windows are backward compatible with shims, where the software of the newer version is tweaked specifically to work with already released products. For example, when Microsoft would have released Windows 7, they would have tested existing software applications that works with Windows XP and Vista and made changes inside Windows 7 to ensure that it works with these software as well.
Mac OS X Intel 10.4 versions have been made backward compatible with Mac OS X 10.6 Intel versions through Rosetta which is a binary translation application.
Microsoft word 2000 is backward compatible with Microsoft word 97 and Microsoft 2008 is backward compatible with Microsoft 2007. The other applications of Microsoft office follow the same backward compatibility pattern.
Even some cameras show backward compatibility like Nikon f mount and Nikon DSLRs, canon EF mount and canon APS-Hs etc.

Different licensing situations in software development - Part 6

In the previous post, I was writing about easy availability of various items (software licenses), and ended up with a listing of the different kinds of open source licenses (the various names of the open source licenses were written down). In this post, I will continue on the subject of open source licenses, as well as the difference between closed source licenses and open source licenses. And open source software is a slightly vague term, which is in fact, further explained into free software and open source software (with the difference between them being that free software focuses on getting the software without charge into the hands of the user, while open source means that the focus is on ensuring that people have access to the source of the software and can make changes).
Here is a listing of all the open source licenses: http://www.opensource.org/licenses/category
Some of the terms used in the licensing debate cannot make sense unless you have read some explanations of them. For example, there is a term called "Copyleft". Copyleft is something that is very critical for makers of commercial software, since Copyleft not only insists that the software should be open source for anybody using that software, but if anybody uses the software and modifies it or extends it, these modified versions should also be made open source. So, if somebody uses that open source software, integrates it into their software, then the licenses compels them to release the modified version of the software as well. This restriction prevents most people who make commercial software to avoid the use of Copyleft software in their own software. If you are thinking of using Copyleft software, please be sure to check the exact terms of the license and also check with your legal team (most company legal teams I know are very hesitant in using copyleft software).
In Copyleft software, the initial owner of the software has not waived their rights, instead has ensured that there are some restrictions on the usage of that software in terms of commercial software. Read more at this Wiki: http://en.wikipedia.org/wiki/Copyleft

Read more in the next post ..