Customers forum - Need to monitor and update

I was going through a forum for one of those new age smart watches, and one could see the level of frustration among some users because they felt that their feedback was not being taken. Now, there might be an argument that an organization cannot really respond to every level of feedback that might be posted anywhere, but in this case, this was a user forum that was present on the site of the product, and users have a reasonable expectation that any such forum would be a way to present their feedback and the company does respond on some of the feedback at least from time to time. However, there was a feeling that was developing among regular users on the forum that any suggestions they made were not being responded to. So, even if employees from the company were picking up the feedback, the response loop was not being completed and users were not getting the impression that their feedback was being responded to.
This led to a level of frustration among the users, and even if new users commented on something, they were told by the regular users that there was no point in giving feedback or suggestions since the company did not respond on the forum. This seems like a reputation that is damaging for the company. When you ask any customer representation or product management from reputed companies, they say that users are the source of a number of different suggestions and defects, and these provide the company an invaluable source from which they can iterate further and select future features. Getting such feedback, especially when people are searching for a consumer forum, come to the site and provide their feedback is something that companies should really want, and ideally, the company should train customer support as well as product management to monitor and intervene in customer forums - this helps in getting inputs and keep customers interested enough to come and monitor the forums. In fact, if you look at another angle, many companies spend a lot of time and money to have beta forums that float new features and get user feedback; this is not exactly a beta forum, but is still a way to get inputs.
What should ideally be done ? There should be customer forums where representatives of customer support and product management should be empowered to regularly monitor and post in, and even members of the product team should get a quick training on how to respond in user forums and visit them. Members of product teams in many cases typically have strong opinions on new features, workflows and so on - exposure to customers and their actual world problems helps to make them more open to new ideas and understand user workflows in a better manner.

Customer interaction - Ensuring that solutions to problems are put out frequently on the product page

Just selling a product is not enough. Unless a company is in a very niche area where there are very competitors, customers should be seen from the long term. There have been some good products that have failed because of inadequate attention being paid to ensuring that the customers are happy and satisfied. Every product will have defects (if somebody is claiming that there product does not have any defects, you can be confident that they are lying), the way forward is to ensure that you have the right strategy in dealing with such defects.
There are many defects that have a workaround. So, for example, a customer may be running into a problem with a specific workflow using a set of steps, and there is a certain defect in either the process of the workflow, or in the information generated at the end of the workflow. Now, there are certain customers for whom this workflow is not important enough, or was something that they tried only a few times, and did not try again, or that they feel that they will not try. There could be other customers for whom the workflow is very important, and they do not feel right about this workflow not working.
Along with the different impact of such a defect to customers, there are also differences with the way that the customers raise such issues. There are customers who will actually raise such complaints to the customer service team of the product, who will search for this issue and look for any solutions posted by the company or by other users, and will visit user forums seeing whether other users are also getting such solutions and whether the company has posted anything with regard to such solutions.
In earlier posts, I have mentioned how the company should be monitoring the user forums, looking at customer complaints and the like, so that they know whether their customers are facing issues, and so on. And it is not just looking for such complaints or issues, but reaching out to people who have reported such issues. This reach out gives customers a great feeling that the product is supported by people who are responsive to customer issues, and this increases their attachment to the product.
There is another higher level in terms of responding to customers. If the team reaches a point where they feel that the case is critical, or where a number of customers are reporting the same issue, the team should consider investigating the issue such that some kind of solution is available. This might mean interacting with customers to get more information about the problem, and then putting in the best possible effort to solve the problem and figure out a solution. This solution could be in the form of a small patch that is posted on the product site along with an article that details how to use the patch; it could be in the form of some steps that prevents the product from getting into a state where the defect occurs (for example, we once had a case where we could edit a specific registry entry and an application crash was prevented), or it could be in any other form.
The point to all this was to figure out that there was a problem that needed the attention of the product team (often this would be flagged by the customer support team, since they kept a track of what issues were becoming critical; but this could be seen by looking at items / complaints getting posted by users on other online forums), investigate the issue and figure out a solution. Once the solution was available, then the next step would be post an article that detailed the issue, and then list the steps needed to solve the issue. The advantage of posting these on a site was that the post would also bet picked up by search engines and when a user ran across the issue and did a search, they would quickly find the solution.

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 different characteristics of installation testing?

Which software testing methodology pertains to the quality assurance work and is focussed up on what is to be done by the customers in order to set up and install the software system or application successfully on their system?

The answer is “installation testing”. 

The installation testing may involve the below mentioned testing processes:

1. Full install/ uninstall process
2. Partial install/ uninstall process
3. Upgrade install/ uninstall process

About Installation Testing

- The installation testing is carried out by the software testing engineer in collaboration with the configuration manager. 

- Running an installation program is considered to be the simplest approach to installation testing.

- This approach is some times called “package software” and it typically deploys a set up program that is nothing but a multi- configuration wrapper using which the software can be easily installed on a variety of machines as well as many operating environments. 

- All the possible configurations should be given an appropriate level of installation testing so that they can be released to the customers without any hesitation. 

- There are some cases of the distributed system in which the software is to be released particularly in to a target environment that is live such as an operational web site. 

- In such cases the installation or you can say software deployment involves changes in the database schemas and installation of the new software system or application.

- Some deployment plans are created for these kinds of circumstances. 

- These deployment plans consist of back out procedures that are aimed at rolling back the target environment if the deployment does not show up as successful. 

- The deployment plan should be tested before deploying them in an environment that is an exact copy of the live environment. 

- Synchronizing the data in the test deployment environment with minimum disruption can increase the organizational requirements of such a plan. 

- This type of implementation plan includes:

1. Up grade of a multi tier application and
2. Testing of the processes which are carried out during installation.

- Such kind of testing is often compared with the “dry run”. 

- Implementation testing is nothing but another name for installation testing. 

- A successful installation of the software system or application will surely make the customer happy but an unsuccessful installation will disappoint the customer. 

The situation can get even worse; it can badly damage the user’s system. This is an example of how a lack of proper installation testing can ruin your impression of the customer. Now you must be wondering what you should do to avoid such embarrassing situations? 

- You should test the installer thoroughly and also with the combinations of manual and automated processes on various machines with several kind of different configurations. -“Time” is the factor that limits the scope of the installation testing. 

- Executing even a single test case takes a hell lot of time. 

Steps involved in Installation Testing

Below we are mentioning the steps involved in the installation testing:

1. Decide for how many different system configurations you want to test the installation.
2. Prepare a basic hard disk drive and format it with the default file system.
3. Install a common OS like windows on this hard drive.
4. Install some primary required components on this hard drive.
5. Create images of this HDD and this will enable you to create configurations on the drive.
6. Make different sets of each configuration like OS that can be used for further software system.

What is meant by Domain engineering? What activities are involved in domain engineering?

Domain engineering is nothing but also known as product line engineering. This article is focussed up on the domain engineering and the activities that are involved with it. 

About Domain Engineering

- This is the process that re- utilises the entire domain knowledge in the production of the new software systems or applications.

- The domain engineering is an important concept under the systematic re- use of the software systems and applications. 

- There is a domain by the name of “application domain” consisting of the systems that share commonalities.

You must be wondering how it is possible to cater to the varying needs of the customers by working with just a few domains. 

- The developers make it possible by repeatedly building similar software systems or applications in one domain with many variations to cater to the wide needs of the customers and clients.

- They do not develop a new system starting again and again from the scratch. 

- Effective development is achieved by re- using the portions of the already existing software system or application in the domain. This way time is also saved.

- One of the activities in domain engineering is domain analysis and it involves:

1. Identifying domains
2. Bounding the identified domains
3. Discovering commonalities and variabilities among all the systems in a particular domain.

Purpose of Domain Engineering

- Domain engineering aims at improving the quality of the software systems and applications through the re- cycling of the already existing software artifacts. 

- Thus, the new software systems and applications developed with the domain engineering are not actually new as a whole but are variants of the other systems and applications within the same domain that were built earlier. 

- Domain engineering has helped in maximizing the business profits and a reduction in the time to market has been observed. 

- The overall cost of the project is also reduced and is evident in the implementation phase of the domain engineering. 

- With the domain specific languages, the code size can be restricted both in the terms of numbers and methods. 

- In the domain engineering the developers are forced to use their knowledge that they gathered during the previous software engineering processes. 

- With the development of the re- usable artifacts, the cost of the software is reduced and the quality is improved. 

Domain engineering consists of three phases and the above principle applies well to all these three phases.

1. Domain Analysis 

- This phase involves defining the domain and collecting information about it and produce model based on the collected info. 

- With such a model, the common points as well as variant points of the domain are identified and thus the development of configurable requirements is facilitated.

- Domain analysis is not be confused with the requirements engineering.

- The effectiveness of the domain engineering stays only when the re- use of the software artifacts is deployed in the earlier phases of the software development life cycle of that software product. 

- Potential sources of the domain analysis include:

(a)  Design documents

(b)  User manuals

(c)   Requirements documents

(d)  Standards and

(e)  Customers as well.

     2. Domain Design 

   - This phase makes of the domain model produced in the first phase and produces a generic architecture appropriate for this model and to which all the systems within the domain can adhere to. 

    - With the configurable requirements produced in the previous phase, a standardized solution is obtained. 

  - The solution that is generated in this phase is common for all the systems within that particular domain.

     3. Domain Implementation

     - This phase involves creation of a customized program in that domain. 

What are strengths and weaknesses of Extreme Programming - XP?

The extreme programming is bound with some strengths and weaknesses that we are going to discuss in this article. Extreme programming was brought in to use during the era of nineteen’s. At that time it came to be recognized as one of the best agile software development practices and still holds the same reputation despite arguable views of its many critics.

Many different scale companies like small scale companies and large scale companies have been benefited by the use of this agile methodology i.e., the extreme programming. Over the years the extreme programming has guaranteed the customer satisfaction and has proved itself also. The software were delivered exactly they were required to be.

Benefits & Advantages of Extreme Programming

- The developers and programmers as well as the customers are empowered by the extreme programming so that everyone can confidently play up its part no matter at what stage the development process is. 

- The extreme programming has been well known for the spirit of team work it inculcates in the development environment. 

- Extreme programming as we know is an agile software development process based up on the releasing the software product frequently with every iteration of the development cycle. 

- Many other techniques like time boxing are also incorporated with the extreme programming to together make up a very efficient software development process.

- The extreme programming contributes greatly in the improvement of the productivity of the software.

- It also contributes in the introduction of the check points that facilitate the incorporation of the changes or modifications in the requirements at all the phases of the development. 

- Customer is given a lot of empowerment in extreme programming. 

- This is so because it lies in the discipline of the extreme programming to maintain frequent and most possible effective communication with the customer. 

- Extreme programming as the term itself suggests that the process involves the beneficial elements operating at their extreme level.

All these positive points of the extreme programming are its strength. All these plus points make the extreme programming popular among its users.

Weaknesses & Drawbacks of Extreme Programming

Now let us discuss some of the weaknesses of the extreme programming since every process has some pros and cons. Critics have pointed out many potential drawbacks such as:

     1. Unstable requirements

     2. The user conflicts are not documented

     3. Extreme programming lacks an overall design specification

- The extreme programming has always been under arguments due to the above mentioned weak points.

- It has been claimed by the critics of the extreme programming that having a customer aboard can be a source of stress to some developers and programmers.

- Some have also mentioned this as a factor that can lead to micro management i.e., the whole development process will be governed by the customer who literally does not have any proper technical knowledge.

- In some cases, the requirements are expressed as automated acceptance tests instead of being expressed as specification documents. 

- In such cases, the retrieving of the requirements takes place through incremental.

- Some even believe that the extreme programming is meant for the senior developers only and that the developers with less experience or less knowledge cannot handle it.

- The lack of the detailed requirements documentation can sometimes lead to what is called the scope creep.  

Who benefits from extreme programming and how?

Extreme programming has been benefitting almost every one since its advent! Here in this article we are going to see who is benefited most from the extreme programming.

It enables the users to give sufficient feedback so that it can be further improved up on. It gets the whole team sticking around the project at hand and regulates effective development of the software. 

In extreme programming, whoever contributes in the development is considered to be an integral part of the whole team. The customer is considered to be the business representative here. The business representative is supposed to sit with the tem in their working hours and work along with them.

Very simple practices like planning and tracking are used to make decisions on what should be done in the next iteration and when it will be complete. The team is driven by the business values and the software is released in a series of small fully integrated releases only when they have passed some customer defined tests.

In extreme programming, the code is obsessively tested by the extreme programmers and developers who work together in pairs making an effort to continually improve the design satisfying the current development conditions. 

With extreme programming, the entire system can be kept in an integrated and running condition. The whole of the production code is written in pairs and worked up on together. The code is written in such a way that every one is able to easily grab the logic that has been implemented. 

Core Practices in Extreme Programming

The below mentioned are the core practices involved in extreme programming:

      1.   Whole team

      2.   Planning game

      3.   Small releases

      4.   Customer tests

      5.   Simple design

      6.   Pair programming

      7.   Test driven development

      8.   Design improvement

      9.   Continuous integration

     10.  Collective code ownership

     11.  Coding standard

     12.  Metaphor

     13.  Sustainable pace

Who all are benefited from extreme programming?

- By looking at these core practices one can easily see that the extreme programming takes care of all the aspects of the programming as well as of all the stake holders who are involved in the development process. 

- With the extreme programming the developers and the customers are able to see the exact picture of the software system or application and its work flow. 

- All the team members of an extreme programming team sit together and work up on the problem. 

- It is beneficial for the whole development process to have a customer who is a real end user. 

- The main purpose of the customers is to define the customer acceptance tests which are then used to define the requirements and specifications of the system or application. 

- On the other hand the manager is considered to be responsible for the management of the external communication and the coordinating activities. 

- The contribution of every team member of the extreme programming team is unique in its own way and is the best that can be provided. 

- As such it is not necessary that only individuals with expert skills! But whatever they contribute is something special out of their abilities and skills. 

Two questions are taken care of in the extreme programming as mentioned below:

      1. What will be accomplished at the end of the due date of the software project?

      2. What is to be done in the next iteration?

These two questions are addressed by the following two activities:

      1. Release planning and

      2. Iteration planning

Above all,  the one that is benefited the most is the customer and after this comes the number of other stake holders.