Collecting information to add in a Readme document updated just before release ..

When you release any software product, there will always be problems. Further, there will be information that will need to be passed onto the customer that can be important, such as the level of Operating System support. Hence information needs to be passed onto the customer, early, either before the actual installation, or when the customer wants to read information about the product on the site of the product:
- There will be some defects or problems in workflow that came too late to be fixed.
- There will be defects or problems that the team decided were not worth fixing and could be passed onto the customer.
- The operating systems that are supported by the application (including the service pack numbers)
- Workarounds for some common issues that could be facing the customer, which could be a description of the problem being faced, the workaround that the customer can use (such as some tweaking of files on the product end, or some patch on the site of the product that could be downloaded by the customer and fix the problem).
- Information about some third party applications used inside the product, including links to their support pages and the like.

These are important information. At times, the development team may feel that a problem that is specific to a particular component or a version of an operating system may not be important, but for the customer who is suffering from such an issue, it is important. And it is important that the team should strive to provide this information to the customer in an easy way, typically providing this information in the form of a Readme document.
However, there is some debate about when the Readme should be prepared. Since the Readme is also supposed to also capture details of issues that were not fixed late into the cycle, the Readme should be made ready as late as possible. But for products that are available in multiple languages, there is the need to have this document translated into all the languages, and in the full form. Hence, there is a limitation of scheduling to determine when the document should be prepared.
We finally made a determination where we tried to figure out when we can prepare the Readme document, and worked backwards. We worked with the team that did the localization of the Readme and tried to figure out the latest by which the document could be localized. Based on that date and some discussions, we finalized a date to that effect, and that was the date which was the final date for the English language version of the Readme document, and then added in some more days for the preparation of the Readme (which included the time taken for collection of all the data and information required for the Readme document to be prepared). This ensured that all late breaking information was captured and yet there was enough time to prepare a Readme document to be included with the installer, and also be available on the site of the product.

Developing a list of features for current and future versions of the product - Part 11

This is a series of posts that talk about the features that make up an application, and more importantly, the series of steps through which the list of features for the application are collected. There are a number of sources from which these list of sources are collected (in fact, it is important not to miss as many possible feasible sources as required). Once the list is collected, they need to be added to any sort of tool where the list can be consolidated, details added where required, and then the Product Manager can start ordering the list of features based on some specific criteria. In the last post (Developing a list of features for current and future versions of the product - Part 10), I talked about one way in which the features can be selected for the next version of the product, based on the product going in for a specific area of focus. So, there was a product that had social networking as the theme for the next version of the product, and as a result, those features were ordered higher in the list that had social networking as the theme.
This post will cover more such basis on which features can be prioritized and ordered for the next and future versions of the application. Another way in which features are ordered is by trying to group them into major and minor features. Typically, one of the major necessities of new feature development is to decide on a set of features that look cool, specifically those that look good at reviews. Now, these can be features that add on a major new set of functionality, or do something that can excite users. For example, if you have an application that provides remote control capability on a tablet, a cool new use could be to also to act as a controller for game devices such as the PS3 or the Xbox (now, this is just an example).
In the whole list of features that are available in the database, there will be many such features that are worthy of review and can excite user attention. A wise product manager would not like to add too many features in one go, but add a couple of such features for the next release, then save some for the next version, and so on. Adding too many in one release diminishes the focus on each of them, and also sets expectations for future releases that may be difficult to fulfill. Another important part of such a planning is about the resources for each such feature, and combined, the total resources required for developing and testing such features. Unless the resourcing for the application changes significantly from release to release, the amount of resources available per release will be around the same, and this also limits the amount of work that can be done for each release. In our experience, we always had time only for some new features, and some smaller features / modifications.
Doing some smaller features is important, since many of these are actually refinements of existing features and allows you to pass the message to your customers that existing features are also tweaked based on their inputs (and in fact, in many cases, you should be able to trace a direct path between customer feedback and the changes made in those features based on these feedback). Prioritizing some of these modifications should be done based on the critical nature of the feedback and the urgency of them. In many cases, these modifications are important for customer workflows, and this helps the Product Manager in doing the required prioritization.

Read more about how to do this prioritization in the next post (Developing a list of features for current and future versions of the product - Part 12 - TBD).

Developing a list of features for current and future versions of the product - Part 10

This is a series of posts on how to define a list of features that will be used for current and future versions of an application. If an application needs to be successful, it is important that the application have a great list of features that attracts reviews as well as users. For this purpose, it is important to draw upon a significant list of people and users who can generate a list of features based on their usage of the product, and then it is upto the team, primarily the product manager, to organize these features into a list that will be defined by the priority of the features and the way that these features are managed in terms of which feature will make it into the current version of the product, and which feature will be added to future versions of the product. In the previous post (Developing a list of features for current and future versions of the product - Part 9) I talked about how a tool was used to capture these features, and how the Product Manager would be able to use the tool to review the features and decide the level of detail that is required for each of these features.
In this post, I will talk about how the Product Manager will try and group these features together into a logical set based on the overall feature set planned for the product. This is much easier to do when it is decided to have the next version of the application feature a specific area. So, let us consider the case of a software that generates greeting cards, after giving the user a chance to upload specific image clips, or use stock photography that is made available by the application, allows the user to add details in terms of messaging as well as using pre-determined messages and various other features. The software would let users do all this and then enter email id and name of the person to whom they would send out the email to. Now, the makers of the software felt that their competitors as well as the market were getting focused on using social networking for sending these cards as well. So, once the user has made a card, it was not required to send the card only in a 1:1 situation (which is what email would typically do), but the software would allow the user to post the card on the Facebook profile of the person to whom the card was intended for more people to see; similarly, the card could be posted on Pinterest, or sent via Twitter, and so on. All of these are new age social networking features that were missing in the application.
So, now the overall thrust area of the release was there (there would always be some minor areas that were also present, but these were the broad areas that the product would focus on). For this purpose, the Product Manager would review all the features in the tool that are focused on social networking, get an initial list, and then do a quick prioritization of the features that seem the most important. This would be an initial prioritization, and in most cases, this initial list would be presented to senior management of the team for a review as well, and changes made if required after discussion. Thus, the final selected features from the list would be taken up, with a mix of major and minor features being there in the list (with the ones that are not selected having a note added about why these features were not selected, and some of them might get the tag about being rejected as well). Once this final selected list is available, the team can then use this list for further detailing.

Developing a list of features for current and future versions of the product - Part 9

This is a series of posts that detail the need for a product team to generate a list of features that can then be applied to the current and to the future versions of the product. Having a list of features that is comprehensive as possible is necessary to ensure that the product has the best chance to success. An important part of such an effort is to ensure that all possible sources of information regarding possible features that can make it into the product are obtained, for prioritization. This has been the focus of previous posts such as the last one (Developing a list of features for current and future versions of the product - Part 8). Since we had listed down a number of possible sources for features, we should start now trying to figure out some of the ways that this list of features can be prioritized for the current and future versions of the product.
So, how do we decide on how these features can be prioritized ? Well, the most important step is to decide on the kind of process used for documenting these features. Based on several teams and tools that I have been involved with, one of the most important conclusions that we came up with was to use the default tool that is used for feature collection to collect features for future versions, or to get it tweaked if the feature tool is not able to support features that will not be implemented in future versions. So, if you are using Scrum based development, ensure that the tool you are using for scrum is capturing all the features, and then you can start doing prioritizing and ordering of such features. Other teams have been comfortable using even a simple tool such as Microsoft Excel to capture the list of features and then additional columns to capture order, timeline and other such information needed for feature ordering.
Another important part of the overall process was about deciding the level of control over the tool and the process used for the same, which would also include the level of information required. In the process we had implemented, the Product Owner has overall authority and responsibility for the ordered feature list. As a part of that, there was a process (widely publicized to the team and to other stakeholders) where a new feature could be added to the overall list. At this time, it was also mentioned about the categories of information and the level of detail that was asked for, with some of this information being mandatory, and other information being on a good to have basis.
Once the information was added to this database, the process was that such information would be added to a new status called review. It was important to realize that unless any feature was approved by the Product Manager, the feature would not move into the prioritized list (although there was a weekly reminder to the Product Manager about ensuring that pending items were reviewed by the Product Owner). The Product Owner had the power to add additional people who were allowed to review the list along with the Product Owner (this was very useful when the list of such features was large, which was typically the case when the product was moving into a final stage of the schedule, or also when the Product Owner had sent out a request email asking people to enter details into the feature database).

This is turning out to be long, so will add more in the next post (Developing a list of features for current and future versions of the product - Part 10).

Developing a list of features for current and future versions of the product - Part 8

This is a series of posts that detail the need for a product team to generate a list of features that can then be applied to the current and to the future versions of the product. It can be said in a majority of cases that a weak feature set leads to the failure of a product; as a result, it is required that the feature team and product management spend as much time as possible to ensure that all possible sources of feature requests have been looked at to determine a possible list of features for the product (for current and future versions of the product). In the previous post (Developing a list of current and future versions of the product - Part 7), I went into details of how to generate a reward based method of getting feature requests from customers and others. I will add more details of more sources for getting features and adding these to the overall feature list for prioritization and development.
We have already looked at many sources for the product. Some of those sources are people who are pretty familiar with the product and hence may have already run out of ideas (these are typically people such as the product managers, the team and a number of traditional customers). What is required is the provisioning of fresh people to look at the product and generate ideas for features based on somebody looks at things fresh. Well, where do you get such fresh people from ?
Every release there are new customers who are introduced to the product, and some of them will be of the form that they will have an opinion. You need to mine such people for getting information on where they feel some features of the product need improvement, where their work flows are not being met, and equally importantly, which are the features that would be great in the product, and are not present (these may or may not be present in the feature set that competitors have).
There are many ways to get information from customers, and we have talked about some of those ways in previous posts. Another way is to set out a survey which attempts to reach out to new customers, and asks them about which features they need help on, and other questions that will help in generating data related to which features need improvements, and which are the new features that need to be present in the product.
Another set of sources is in terms of vendors. In today's model of software development, there are many teams that will be using external vendors (in addition to the core development and testing teams) for a variety of needs; some companies have totally hived off their testing processes to external vendors, other use them for converting the software to different languages, and preparing help / documentation about the product. A number of these will be people at the vendor's end who have not worked with the product before, and they can provide some fresh ideas about what worked with them, and what did not work. Doing this on a regular basis, when they are getting some training on the product, and also when they are involved with actual work is important. The problem is, if the development team is working with these vendors, they tend to dismiss feature ideas or workflow queries from these vendors, instead of evaluating them to see whether these queries could actually work out to be feature improvements or new features.

In the next series of posts, I will talk about how to organize these features, and put them in a form that they are useful (Developing a list of features for current and future versions of the product - Part 9 - TBD)

Developing a list of features for current and future versions of the product - Part 7

This is a series of posts on how to resource a collection of features for the current and future versions of the product, develop these features, and then prioritize these features such that a list of such features can be laid before the team. Once a list of features has been generated, reviewed, necessary details added and dependencies evaluated, they form the basis for the future development of the product. However, it is critical to ensure that the feature list is formed after an extensive evaluation of all possible sources. This series of posts has been concentrating on how to obtain features from different sources, with the previous post (Developing a list of features for current and future versions - Part 6) focusing on getting a list of features and feature modifications / additions from the team members. Team members are very close to the product and can provide a lot of incremental improvements, and with their study of competitors, can also suggest features that it would be useful for the product to add. This post will look at another source from which features can be suggested (and keep in mind that even though some of them may sound odd, generating even a couple of features based on a new source can be very useful).
In a previous post, I had suggested using surveys and also collecting information based on customers usage of various features in the software. This post takes a more specific instrument to collect features; basically a contest that asks customers and others to suggest the most useful features that a product can have. This is a new avenue that has shot into higher profile in the past couple of years, and I have seen it adding a few more features to the existing list of features for a product, overcoming the skeptical nature of the team and the product manager. It is a bit hard to ensure that the team management and the product manager are exploring new avenues for generating a list of features; normally they would already have a list of features from previous such exercises, and after looking at some competitors, they would feel that they already have a good list of features and don't really see the need for looking at fresh sources of generating features (which would help in refreshing and re-prioritizing the existing list that they already have).
In the recent past, I have seen some organizations and products trying to use crowd-sourcing (god, I hate using buzz-words) as a way to generate a list of features for the product; and when you add a prize at the end, it can turn out well. So, the simple way to go about this would be:
1. Prepare a timeline for how long do you want this exercise to continue, when would start informing people and when you would end the process of collecting the list of features
2. Define whether there are any selected categories in which you want features (this can be helpful when there are certain areas of the product that you feel that you are weak in)
3. Define the level to which you want people to prepare the features that they are submitting - something like a top level definition, or a more detailed description in which they define the entry points into the feature, the processing in the feature, and the exit points from the feature
4. Define the prizes that top contributors will get, and also define whether you need to get more information from these contributors during the time period that the feature development work is happening; also define more aspects about whether there is the need to have agreements such as a Non Disclosure Agreement in the same time period.
There will be many more details during the planning of such an exercise, but these are the top level details that you should be looking at while starting an exercise to obtain features from people.
Once you get such a program running, there is a good chance that you get atleast a couple of features concepts that have not been thought through from other sources and which can be useful for your product. And in the end, if you have decided that you will take one or more such features in your product, be sure to advertise the feature and also get the contributor (if he or she has been happy with the interaction with your team) to be part of your coming out exercise of the product.

Read more about generating a list of features in the next post (Developing a list of features for current and future versions - Part 8)

Developing a list of features for current and future versions of the product - Part 6

This is a series of posts that talk about developing a list of features for the software product. One of the major factors that determine whether a product is successful is having the right set of features, and getting the right set of features is not an easy task. It takes a lot of effort for ensuring that you have the right set of features, and the team and product manager should ensure that they do their best effort for preparing the list of features, and then prioritize them according to the features that should be incorporated in the current version, and those that should be kept for the next versions of the product. Once you have a list of features, you can spend time on prioritizing it for the current and future versions of the product. In the previous post (Developing a list of features for the product - part 5), I talked about how to get feature ideas from the reviewers of the product, from their experience of seeing multiple products trying to attract the same set of customers. This post will continue in the same and talk about more areas where feature requests can be generated, and added to the overall list.
One of the biggest sources of information about features (and yet one that should be considered with a lot of thought) is the development team. Day in and day out, the team is working on the product and they get a very detailed idea of what the product is like, what are some of the shortcomings of the product, and what are some of the features that are built solidly. In our teams, it invariably turned out that atleast 15% of the features that were done in a release were built based on the feedback from the team, collected from them at regular intervals of time. Doing so also increases the morale of the team, ensures that they are fully committed to the feature set of the product and to the features (the managers of the team may feel that it is not necessary to do so, since the team would anyhow be committed to the product, but you would be surprised at how such steps increases the level of involvement of the team in the future of the product).
How do you collect these features from the team ? On a regular basis, the product manager of the product should do brain-storming sessions with the team, and should also have a repository where the team members can add features, add more details to these features and even build upon these by adding use cases and examples. Such avenues can lead to some incredible feature ideas, that the product manager would not even have thought about; even though many of them would be like feature improvements rather than new features (but as we have discussed before, feature improvements, if they are big enough changes, can be almost like new features). The team, while working on the product, would have noticed many areas where the workflow could be improved; competitor analysis shows them where a feature could be modified to seem like a feature that the competitor has; their interactions with customers would show them where there can be improvements to the features and what the paint points are.
At the same time, the product manager should ensure that these feature requests from the team are seen as requests from somebody who is very deeply involved with the product (a lot of people would argue that the team is too involved and too biased in certain ways), and hence there needs to be a lot of filtering and some amount of modifications before those features can be added to the feature list. This is something that the product manager should ensure that the team has understood.

Read more about processes of collecting feature requests in the next post (Developing a list of features for current and future versions of the product - Part 7).

Developing a list of features for current and future versions of the product - Part 5

These are a series of posts on the process of generating a list of features for the software product; such a list of features can be aggregated, built upon and prioritized for the current and future versions of the product. These are important to ensure that you have the best of features for the future of the product, features that will make the product successful. However, before you can do that, you need to ensure that you have reviewed all the ways that you can generate a list of features, including from customers, from reviewers, and from other stakeholders. In the previous post (Developing a list of features for current and feature versions of the product - Part 4), I talked about the help pages for the product on the site of the company, and how data analysis of customer visits to such pages can help determining which features are popular and also which features cause the maximum problems to customer. In this post, I will add more details on the capturing of feature requirements from different sources.
A person who views different software products that do the same kind of work typically has a very good idea of which features are the most exciting, the ones that are the most sought after, and the ones that get good reviews. For example, if there is a new version of a software that helps users do printing, then the organization would go to technical experts from different media organizations such as Cnet, New York Times Technical Section, and many others, and look for a good review from them. Now, this process is not so easy as picking up the phone and requesting a review. For many of these media people who write the technical columns which review new products, they are experts and also fairly busy people, and they need to be approached in all seriousness, providing them with the product, time to play with the product, a list of the top features currently features in the product.
When such a discussion finally takes place, the reviewer will typically spend time with the person from the organization (typically this would be the Product Manager of the specific product), and it is during this conversation and the show and tell that the product manager will be able to generate a fair number of comments. These comments would be able to provide the Product Manager with a list of items that the reviewer feels are done well, which are sellable and which excite users. At the same time, the reviewer will also provide a list of features which are missing something, features that the reviewer feels are incomplete or with workflows not optimized for the intended users of the application; and most important, the reviewer will also have a list of features that are important for the customer, but for whatever reason, are not present in the customer. It could be that such a feature got discussed but was dropped from being included in the product for some reason.
With such a list, some study will reveal a list of big features, big feature modification and small improvements that can be done in the feature level, these would need to be balanced against features resourced from other stakeholders, and eventually a list of prioritized features can be generated, which can then be set against the current version of the product, or the next version.

Read more about this in the next post (Developing a list of features for current and future version - Part 6).

Developing a list of features for current and future versions of the product - Part 4

This is a series of posts on the way that teams try to derive a list of features that they need for basing their features sets for the current and future versions of the product. The better a list of features that you have available with you, the better will be the options available with you for generating a list of great selling features. However, even before you can get started with the process of defining which feature to use in the current release vs. features that should be done in future releases, you still need to generate such a list of features; and your attempt should be that such a list is as comprehensive as possible. In the previous post (Developing a list of features for the application - Part 3), I talked about getting features from the posts that users make in online forums. There is an increased tendency for people to use forums to present their problems and a lower percentage of people point out features that they would like. However, since these represent features suggested by actual users, such features should be considered seriously. This also ensures that users appreciate that their suggestions are also being incorporated and increases their involvement in the product.
Another way for you to determine which features are being used the most as well as which features are causing users problems is through the statistics on help items. If you are into providing more information to your customers, one easy way is to have all your application help online along with other areas that would be helpful to users such as How to help videos, Tutorials, Solutions for major bugs, and so on. Now, such items on your company's servers are typically indexed easily enough and will show up when users search for such items. Along with such help pages, it would be easy enough to provide a small section where users can put in their suggestions.
Once these pages are up, monitoring the suggestions provided by users along with the statistics on which of these pages are accessed by users can provide invaluable help to a team that is trying to make sense of this data. So, for example, if you have provided a video on how to use a particular feature, and this is being accessed the most by your users, and they also provide feedback, then a team tasked with trying to evaluating this data will be able to determine which part of the feature works well, which part does not, and also about suggestions for improvement. There are many teams and organizations that try to make sense out of such data, and they have managed to determine which features are the ones where users are reporting problems, and once they even managed to determine that a feature that was a technical masterpiece did not seem to have much user attention (atleast not to the level that was required by the team).
Continuing on this line will enable a team to make improvements to their existing features or even do major modifications, which can actually almost seem like new features if the change is big enough.

Read more about this feature collection and analysis in the next post (Developing a list of features for the application - Part 5)

Developing a list of features for current and future versions of the product - Part 3

This is a series of posts, meant for talking about the processes and methods of determining the list of features that is needed for a software application (both for the present and the future of the application). This entire process of generating a list of features is important, since it means that the team has put in the effort and the thought process of evaluating the various inputs that go into preparing a list of features, optimizing them, determining the ones that are feasible vs. the ones that are not, and then finally prioritizing them in terms of determining the ones that will go into the current version of the product vs. the ones that will go into the next version of the product. In the previous post in this series (Determining the features of an application - Part 2), I had gone into some details of the mechanisms used to collect feedback and some ideas of features from customers. I will continue on the same lines in this post as well.
- One of the best ways of determining which features are liked by your customers and which are not can be seen by monitoring user forums where users post their feedback (it is a different matter that most users post only when they have an issue or need some clarification, not when they like something). So, you could have a feature that is often commented upon, and if your team members are monitoring such communication on the user forums, you will soon realize that in a significant percentage of cases where the users have some sort of issues, they also point out the way that the feature does not work as well as the way in which they think it should work.
Once you get to this point, you will realize that defining features is not just about trying to get something new in your product; instead it may be far more useful to figure out some of the features that are already implemented and not working properly or designed in such a way that users are not seeing them as useful or easy to complete. In many of these case, the feedback will be numerous enough and detailed enough that you could drop an existing feature or re-design it in a totally new way. Such a change cannot just be called a modification of an existing feature, because the extent of change determines the amount of effort that would be put in. We have had cases where after evaluating some of the feedback from our users, we essentially were shocked at the extent to which a prized feature was causing problems to customers and we eventually put in a fair amount of effort to completely change the feature. And it was a success, since the new feature proved to be far more successful with customers; in fact some of the customers on the earlier version of the product actually upgraded to the latest version of the product since they found the reviews of the re-designed feature to be very useful in their actual workflows.
Running into such a case can be actually game changing for many teams, since this would give them a mechanism to evaluate the performance of a feature, learn why customers could be rejecting a feature, and how to be a success just by modifying an existing feature.

Read more about the feature gathering and refinement process in the next series - Part 4 - TBD.

Developing a list of features for current and future versions of the product - Part 2

This is a series of posts on the process of developing a list of features for the current and next version of your product. Without such a list of features, without having done the best effort to ensure that the list of features is perfect and suitable, the product will not be a success. It is the rare product that can be successful despite not having the best of research for the list of features; in fact, in most cases, a product may not be successful despite having made the best effort to ensure that the list of features has been well researched and prioritized. In the previous post (Developing the list of features for a product - Part 1), we covered how to generate a list of features, some of the sources of such a list of features, and the stakeholders for the same.
In the current post, I will focus on getting features ideas and refinements from one of the key stakeholders of the project, namely the customers. The customers of your product are one of the principal stakeholders, and it is their comfort with the product that determines whether a product is successful or a failure (actually even when a product is liked by customers, it can be a failure, but that is a different story (the success factor may not be enough to cover the costs of the product, or the desired success factors for the product)).
How do you get feedback from the customers ? Getting feedback from the customers is one of the first steps in deriving a list of features that are required by your customers. Here are a few of the methods:
- Incorporate a feature in the product that allows your customers to provide their inputs. This can be like a sort of survey mechanism, cloaked in some appealing language that appeals to the vanity of the customers (so that they do not get irritated by such queries - putting in language like 'we build this product based on inputs from our customers, and your inputs are essential for developing a great product'). If you are able to showcase later that some of the features were built on the advise of customers or even more so, if some features were built while having customers as consultants, it overall gets you a list of features that are desired by customers (I know a team that did this on a regular basis, and got a number of customers who would be part of this effort and would also upgrade their product versions due to their commitment to the product). However, for an effort like this to work, it is essential that you do this in a serious way. When the survey is being prepared, to get a list of concerns that people have or to get the features that they need in the product, you need to ensure that the queries are made with all seriousness. Preparing such queries is not an easy matter. Questions that seem obvious to people involved with the project can seem very apparent, but you need to get outside people involved. For people who are not so intimately involved with the product, such questions can turn out to be confusing or not well constructed. Hence, if you want such queries with customers to be useful, and also to have a connection with your customers, make sure that an expert team is chosen to prepare the list of questions, and only after due consideration are such surveys floated to customers. A further note of caution - floating such surveys to customers should not be done in rapid succession, there should be an adequate time gap between such surveys.

Read more about the feature gathering and refinement process in the next series - Part 3.

What are Rational Unified Process building blocks?

Whenever we talk about iterative software development process frame works, the first name that comes to our minds is of the rational unified process. It is not just a single hard coded prescriptive process rather it is quite an adaptable and flexible process frame work. 

This frame work comes with several facilities, the best one being that your organization can tailor it according to their needs. 

What is Rational Unified Process?

- Unified process when specifically implemented is called as the rational unified process. 

- Rational unified process is counted among the best products of IBM and the credit for its development goes to the rational software division.

- The RUP comes with a hyper linked base consisting of the descriptions of several types of activities and a few sample artifacts. 

- A part of the IBM’s rational method composer (RMC) is occupied by the rational unified process.

- It allows the users to customize the process as per their needs. 

What are building blocks of Rational Unified Process?

In this article we are to talk about the building blocks of the rational unified process.

- These basic best practices of the rational unified process were developed as a result of the combination of the experience of many companies. 

- The building blocks are:

1. Iterative development with risk as its primary iteration driver.
2. Management of the requirements.
3. Employment of an architecture based up on components.
4. Visual modeling of the software.
5. Continuous verification of the quality.
6. Controlling the changes

- These best practices are used in the following two ways:

1. For driving the development process of the rational’s products.
2. To be used by the rational’s field teams so as to assist the customers in improving the predictability as well as the quality of the software development efforts.

- The task involves the assembling of the explicit process framework for the field of modern software engineering. 

- The delivery mechanism developed by the objector was based up on the HTML and employed in accomplishing this task.

- This task resulted in the creation of the rational unified process. 

- A set of content elements or the building blocks form the foundation for the rational unified process and give a description of the product that is to be produced and the required necessary skills. 

- They also give a detailed step by step explanation for achieving the specific development goals. 

Now we shall list all the building blocks of the rational unified process and discuss them in detail:

1. Roles: This building block can be defined as set consisting of related skills, responsibilities as well as competencies.
2. Work products: This building block gives the representation of thing that would result when a task would be completed inclusive of all the models and documentation produced during the course of the completion of that task.
3. Tasks: This building block gives a description of the units of works that are assigned to an element from the role which will produce a result that would be meaningful.

There are 9 disciplines in to which the tasks are categorized within each iteration. There are 6 engineering disciplines and 3 supporting disciplines which together make up total 9 disciplines. The 6 engineering disciplines are:

1. Business modeling
2. Requirements
3. Analysis and design
4. Implementation
5. Test and
6. Deployment

The following are the three supporting disciplines:

1. Configuration and change management
2. Environment and
3. Project management

The organization and the management of the above mentioned building blocks need to be solid and flexible in order to make the rational unified process a success which otherwise cannot be achieved. 

What is the key difference between preventative and reactive approaches to testing?

There are two main approaches to testing namely:

1. Preventative approach to testing and
2. Reactive approach to testing

What is Preventive Approach to testing?

- Preventative approach to testing is analytical in nature but reactive is rather heuristic.

- The designing of the preventative tests takes place after the production of the software. 

- On the other hand, the reactive tests are designed quite early i.e., in response to the feed back or review comments given by the customers.

- But both of these tests are designed as early as possible. 

- On an overall basis, preventative tests are created earlier than the reactive tests. 

- The preventative testing approach is based up on the philosophy that the quality of the software system or application under testing can actually be improved by testing if it is done early enough during the software development life cycle.

- However, one specification is to be followed for implement this approach to testing which is that test cases should be created for the validation of the requirements before the code is written.

- Preventive approach is followed because it can be applied to all the phases of the project and not just to the code. It also reduces cost of correcting the underlying faults. 

What is Reactive approach to testing?

- Reactive approach to testing is considered to be a performance testing activity in the field of performance management. 

- The developers often do not think about the performance of the software system or application that they are developing during the early stages of the SDLC or software development life cycle. 

- More often, the performance quotient is neglected till the testing of the system is complete. 

- This is known fact that the performance of a software system or application revolves around its architecture. 

- Designing an effective architecture is a high cost activity and in some of the cases the whole system is trashed because of the presence of the huge deviations in performance factors. 

- However, waiting for problems related to the performance to surface and then dealing with them is not always the best option. 

- So, performance testing is considered to be a reactive approach to testing since the system does not gathers much importance during the early stages of the life cycle. 

- Reactive approach to testing is more of a kind of a “fix it later” approach which is less effective than the preventative approach.

- Even quality control is a reactive approach to testing. 

- Every step of the production development cycle involves quality control. 

- It is not that the developers are simply sitting idle and noting down all the areas where potential issues are suspected after the final outcome.

Importance of both the approaches

- Actually preventative and reactive approaches are considered to be two “test strategies” which are used to define the objectives of the software’s testing and how they are to be achieved. 

- These two approaches also act as a determining factor in the cost and amount of effort that is to be invested in the testing of the software system or application. 

- In preventative approach the testers are involved right from the beginning of the project. 

- The specification and preparation i.e., test planning and test design is also carried out as soon as possible. 

- Preventative approach involves activities like:

1. Reviews
2. Static analysis

- Contrary to the preventative approach, in reactive approach testers are involved late in a project.

- The test planning and designing is started after the development of the project has ended. 

- Reactive approach involves techniques like exploratory testing.

What is the relation between installation testing and configuration management?

Installation testing as we all know falls under the genre of quality assurance work in the field of software engineering and is all focused up on what is to be done by the customers in order to set up and install the new software system or application successfully. 

Installation testing process is constituted of the following processes:

1. Upgrading of installation and un- installation process.
2. Partial installation and un- installation process.
3. Full installation and un- installation process.

What is Configuration Management?

- Configuration management is somewhat self justifying and is looked up on as one of the best practices available for handling the changes that are made in the software system or application during the project development.  

- It is also used as a means for the identification of the physical as well as functional attributes of the software system or application at various points of time during the development process. 

- The configuration management takes up the systematic control of the changes to be made to the identified attributes with the following purposes:

1. Maintaining software trace-ability throughout the software development life cycle.
2. Maintaining software integrity throughout the software development life cycle.

Relation between Installation Testing and Configuration Management

Both the above mentioned processes i.e., installation testing and configuration management share a relation with each other.  

- Installation testing is performed by the software testing engineer in collaboration with the manager handling the configuration management process known as “configuration manager”. 

- The configuration management process shows up the need to trace the changes. 

- This process has the ability with the virtue of which it verifies whether or not the final developed software system or application has all the enhancements, features and functionality that are required to be in the release. 

- In a way we can say that the configuration management checks how correctly the installation testing has been implemented. 

- It is done by the means of four below mentioned procedures that need to be defined for all the software systems or applications in order to ensure that a proper configuration management process is implemented:

1. Configuration Identification: 

It involves identification of the attributes defining all the aspects of the configuration item.

2. Configuration Change Control:

It includes a set of approval stages and set of processes that are intended to change the attributes of a configuration item and re- baseline them.

3. Configuration Status Accounting:

By virtue of this ability the configuration baselines associated with all the configuration items at any instant of time are recorded and reported.

4. Configuration Audits:

It occurs at the moment of incorporating the change. These can be divided in to two categories:

(a)Functional configuration audits: ensures achievement of the performance and functional attributes of the configuration items and

(b)Physical configuration audits: ensures proper installation of the configuration item with the requirements mentioned in the design documentation.

- In installation testing a complied version of the code is placed in a pre- production environment which also acts as the configuration item for configuration management. 

- The configuration management is carried out outside the usual software development environment so that the corruption to the code is limited from the past as well as the future releases.

- The set up program used in the package software acts as a multi configuration wrapper and each and every configuration in it should be tested appropriately so that it can be released with confident. 

In a way we can say that these two processes i.e., installation testing and configuration testing are locked with each other to some extent and this is what that keeps them related to each other.

What is meant by project velocity?

The project velocity is one of the terms that you come across while discussing about the iteration planning and release planning! The project velocity has a got a very important and  not to be ignored part to play in these two mentioned planning processes but still most of us are not aware of its importance. 

This article is centred on the project velocity and has been discussed in detail. Like the normal physics velocity, the project velocity gives the speed of the development of a software project. 

In other words, the project velocity gives the amount of work being and efforts being spent on the software project. 

About Project Velocity

- The project is simply the summation of all the estimates of the user stories that were involved in the iteration. 

- For the release planning, you add up the estimates of the user stories and for the iteration planning the estimates of the programming tasks are added up. 

- But anyway, both the factors can employed for determining the project velocity in the case of the iteration planning. 

- In the iteration planning meeting, the number of the user stories chosen by the customer is same as it was in the previous iteration. 

- There is a rule that the project velocity of the consecutive iterations must not exceed their preceding iterations. 

- These programming tasks are nothing but a broken down or divided version of the user stories. 

- The development team is supposed to take up or sign up for only the same number of tasks that were present in the previous iteration. 

- Such an arrangement proves to be a great help to the developers when they stuck in a sticky situation and need to recover and clean up from it and thus getting the average for the estimates. 

- The project velocity is suppose to rise when the developers are allowed to question the customers for other user stories when they have already finished their work and tasks like cleaning up are also accomplished.

Please do not think that you will get the project velocity consistent throughout the development cycle! It is expected to follow through some ups and downs. 

- But if a dramatic change is observed in the project velocity, then it is an issue of concern. 

- But there is no need to worry since all this can be kept in check by re- estimation and re- negotiation of the release plan. 

- It is not just in this case that the project velocity may change! 

- Even when the system is put under production for the maintenance tasks, again the project velocity is subjected to changes. 

- Division of the project velocity by the length of the iteration or the number of people involved. 

- Furthermore, the number of the people involved in the iteration is not an appropriate way for making comparisons between the productivity of two products. 

- This is so because each and every team has got its own different criteria for estimating the user stories and so we get some high estimation and some low estimation. 

- Important is to keep a track of the amount of work being done on the project so that a steady project velocity for the development can be maintained that can also be easily predicted.

The problem comes while making the first estimation! 

- At least for the following iterations you will have a clue that what project velocity is required. 

- If this measure is used properly you may be able to detect a major fault in your project much before the time at which you would have known with the help of the traditional development methods. 

What is meant by the term system metaphor? What is its use?

System metaphor- well this is a term which is related to the extreme programming but less known of! What is the system metaphor and what is its use and what is the need? 

We shall be discussing all these aspects of the system metaphor in this article. 

"A system metaphor in the simplest words can be defined as a story that any one includes customers, programmers and managers) can tell reading how a system works".

Reasons why we need to use System Metaphor

There are several reasons for why we need to use the system metaphor.  They have been listed below:

1. Architecture: The metaphor is consider to shape the software system or application exactly as it is required by us with the help of identifying the key objects and giving suggestions regarding the aspects of their interfaces. The dynamic and the static models of the system are supported by the system.
2. Shared Vocabulary: A common system of names for the objects and relationships that exist between them are suggested by a system metaphor only and thus it provides a powerful vocabulary for the developers and programming experts. The vocabulary created is shorthand and specialized.
3. Common Vision: System metaphor comes in to as a very handy tool that helps in enabling all the stake holders to agree up on the working of the software system or application. The key structure of how the problem and the solution have been perceived is provided by the system metaphor itself. Overall, this helps in understanding the working of the system well.
4. Generativity: A system metaphor by the means of its analogies can get you new ideas regarding the problem and its solution and can further dig out many other important issues.

How to choose a System Metaphor?

- Even though choosing up a proper system metaphor for your system may take some time and efforts, it is the best option that you have for exploring several possibilities just by looking at the system through various views. 

- If by combining two metaphors you are getting the one that is fit for your then go for it. 

- Now what if you come to know that you could have got a better metaphor for your system than what you have already opted for? No need to worry, you can still develop your system in that direction. 

- Such a measure will also help you in achieving a greater understanding of your problems. 

- What if you are not able to think of any good metaphors? 

- There are some naive metaphors always available to your rescue. Below mentioned are some examples of the system metaphors:

1. Use of a pension tool as a spreadsheet.
2. Using desktop metaphor for graphical user interface.
3. Buckets, lines and bins in C3 payroll.
4. Bills of materials in VCAPS.
5. A double entry system being used as book keeping and spreadsheet.

More about System Metaphor

- Suppose you sign a contract with a client for developing some software system, what you do next? 

- You search for a good system metaphor that will guide the development of your software system or application.

- A metaphor very well guides the development process of a project. 

- Not any one can choose a good metaphor, it requires skills, practice and of course deep knowledge.

- A system metaphor is nothing but a metaphor having a simple design and some essential qualities that the original needs to have.