Very early at the start of the selection you should determine what the exact criteria are for selecting a certain piece of software. You will ask the vendors questions. They will answer you. And then what? Look who has the nicest handwriting? You have to think about this up front.

It's even worse… the questions you will ask are a result of the criteria you want to judge. How else could you say something about your software selection criteria? Ok, let's have a look at some criteria I personally use. There is no real definite list of selection criteria. They can very from company to company, from individual to individual. I included the following selection criteria for illustration purposes (and remember, I'm a prototype "early majority").

Stability of the vendor

I work for a large corporation. If we buy a piece of software it will probably be part of our primary operation for more then 4 years. It would be a big problem if a supplier went belly-up. We would have no more support, no more security, our life-line would be compromised. So, I would be looking for a vendor with some great stability.

Stability can be found in companies that operate already for a long time; that have a large customer base; have a steady income and revenue. Stability is also determined by company size (more people, means better equipped to handle people leaving), and, by looking at the people in charge: are they in charge, how are stocks divided, etc.

Proven track record within our industry

It's a fine line between amateurs and professionals, if you can judge people only superficially in very short time. You don't want to have amateurs fiddling with your company. Look for a proven track record within your industry.

Fit-for-purpose (least possible changes to the standard software as possible)

Changes to software are always a concern. They are difficult to specify, to develop and in general to plan. To reduce the amount of specific changes made for your company, is a way to reduce a project risk. You have a lower risk of schedule and budget overrun. If that's very important, you have to look for the software that comes close enough to what you actually want: fit-for-purpose.

Mature technology

I don't care how a certain piece of software is constructed. I just want to be sure that I'm not a kind of test case, a field study to see how "this cool stuff actually works". Having a new system is difficult as it is… using some technology that doesn't work quite yet, doesn't make it easier.

4.2 Target process

There is always some part of your organization affected by the software you want to acquire. New systems generate generally new ways of working, new process flows. You don't have to have the new software to envision the working process of the near future. It's essential for the selection process you put something on paper on this subject right from the start. First you write, then you buy!

You can use fancy diagrams or just plain text to create stories everyone can read. If it's a current process that has to be transformed, invite a few key players from within the process at hand, and first draw up a picture of the current way of working; identify the current problems, and try to draw the desired situation from discussing how to solve their current problems. In general, I try to avoid to much consultants in this process, people who perform activities in their day-to-day operation are mostly the best informed domain experts you can find!

4.3 Legacy Systems

Old systems never die. Even after you removed the brown, ugly, very large box which contains the old bits and chips, the legacy systems lives on in peoples minds, procedures and policies. Vendors, who replace systems for a living, know these things, and they can anticipate struggles while transforming to the target process. To assist them in their anticipation you have to tell them what you are currently using and how your operation is built around it.

Going from mainframe terminal emulation to a Windows-based environment? The vendor will tell you to put some extra effort in training just for the operating system (like putting employees on some PowerPoint course e.g.), instead of only prepare training on the business application you are looking for. By telling your legacy, the vendors can help you better solve your problem. If you do it right, it can even be free consultancy.

You also need a good description of your legacy systems. This is needed by the vendor to determine how the system should operate within the complex of systems currently running at your company. Aspects to specify are:

• Infrastructure used (network,telecommunications)
• Platforms currently used (operating system, hardware, clients and servers)
• Needed interaction (interfacing) with other information systems
• Data needed to take with you to the new situation (dataconversion)
• Organization of maintenance and support

4.4 Expectations: time and money

You are at the start of your selection process. All may not be crystal clear. However, time schedules may already be stated, without any one knowing what should be done in the first place. Budgets can be formulated without any basis. The sad part of it is that stakeholders have already formulated their requirements. They may not have told you, but in their minds expectations are already in a particular direction. You should sort it out. You should get on paper the expectation the key stakeholders already have in their mind.

For this purpose, it is wise to have a look at the budget for this year. Look how much is reserved for this investment you are about to select.

"The problem is all inside your head, she said to me. The answer is easy, if you take it logically." If Paul Simon would write a song now about software selection, the title could just as well be 50 Ways to leave your old system. "We have a problem. The answer is easy. We need a new system." Now, that's fast thinking. But really, why do you need a new system? Why do you buy a new application?

Not for every problem, the answer is a new information system. It's an open door, but make sure from the start, that you select software for the right reasons. At the end of the process, the selected vendor should be able to fulfill the need you wanted to be fulfilled in the first place. For your convenience and to help the vendors to be able to provide the right solution for you, you have to pay a lot of attention in the answer of the big WHY.

4.1 Business case

"Business case" as a word may be hype. But, the purpose for it, is timeless. It is in essence the description of the problem you want to fix, or the opportunity you want to take; it's cost for realization, and the benefits it will bring.

If you are a sucker for bullet lists… this are the components that make up your business case:

• Description; a short explanation of the problem to tackle or opportunity to grasp.
  
• Reasons; a description of the reasons why the problem should be fixed or the opportunity should be taken.
• Assumptions: all the things you assumed to make this business case consistent.
• Benefits; the benefits for your organization the fixed problem or the opportunity will bring.
• Costs; what will it cost to realize the entire operation?
• Investment analysis; time to break even, etc.

Seems like a lot of work. It is. And it should be. Spending money is easy. Spending money wisely is a hell of a job.

You should consider how much of your business case you will share with the vendors that will participate in the process; if you tell them nothing, they will not able to anticipate to your needs and expectations; if you tell them to much, your companies strategic information can be compromised.

We all use a car for the same purpose; to get from one point to another, without getting tired. Despite the uniform use of the car, there are a zillion different kind of looks to the automobile. All is appealing to different people. The Alfa Romeo driver goes for slick Italian design, and doesn't care parts coming of the car once in a while. The Volvo driver goes for safety first, and doesn't mind he's driving in a soapbox strapped with a big rubberband.

In technology you have different kind of buyers. This has nothing to do with the purpose of the technology, but everything with the personal preferences of the individual. A simple, but effective way to categorize the buyers of technology (including software), is the "The Technology Adoption Life Cycle" (I use the version discussed in "Inside the Tornado" by Geoffry A. Moore). In this life cycle buyers are categorized by the amount of people that adopt a certain technology, in respect to the time after introduction of the technology. In a graphical overview you get a bell shaped figure (see the illustration below).

People are categorized by the time they will buy a certain piece of technology.

Innovators (technology enthusiasts)

These are the people that love technology, just for the sake of technology. They will use the coolest and the newest of all. Most of them will be employed in technology itself; the techies. They adore technology, but bring no cash. They have no money, the are not important decision makers.

Early adopters (visionaries)

They will see the possibilities new technology can bring for their company. They view technology as a very important way to differentiate their business from their competitors. The are important within their own company, they bring money.

Early majority (pragmatists)

This is a large group that believes in evolution not revolution. They will consider technology only if it's proven. They will not go for some hot new stuff, which has no proven track record. They have large legacy systems that must be maintained to perform their company's day to day operation, and not introduce something that might jeopardize that.

Late majority (conservatists)

They will adapt technology only if it's completely a common property, and mostly if it's very widely used. They go for market leaders only. Pricing is not a very big issue. Because it's very reliable, stable and statusful, they will drive that BMW.

Laggards (skeptics)

They don't believe in technology at all. Forget them. If you even started reading this tutorial, you do not belong to them.

I personally belong to the pragmatists. And most people that will perform a selection process in the scope that's described in this book, will be. Keep in mind what you are. It will determine how you will conduct the process; what selection criteria you will emphasize what vendors you will select. Keep also in mind that this document is written with a bias towards the early majority.

So, you are going to select some software. I don't mean an action game for your kids, but I'm talking about a real life, heavy-duty business application. Actually, the hard part is deciding which system to acquire anyway. It's so hard, we even have a name for all the steps together: the software selection process or acquisition process if you like difficult words.

And people are making it difficult, trying to make it look like a science. Let me make one thing clear, right from the start: the actual judgment on the selection is difficult, the only thing that really can help you there is experience, the process itself is easy and straightforward.

In this guide I will describe the first part of the software selection process, and my own experiences with it. It is actually the first round, of the total of two rounds that will bring you to your final choice: the request for information. The second part will be described in a future volume 2 of The Microwave Way to Software Selection.

This is not THE only way to do a software selection process. However, it's simple, straightforward and effective: the microwave way.

2 The Steps

The software selection process is a two step trip: first you create a large list of candidate vendors (the long list) who you will send a request for further information. You select the best suited for you (the short list) and go with them in detail on your needs (request for proposal).

The steps covered in this tutorial are the ones to get to the short list.

* Define your needs

* Define your selection criteria

* Create the long list

* Create the request for information

* Evaluate the responses

* Create your short list

You see, nothing you can't handle!

Relevant links

Software Marketing Disasters

Custom Software Development
Custom web applications bring Web sites to life. Stylus Systems can develop a software application from the ground up, providing you with exactly what you need, not just what we have available.

Offshore Software Development
MachroTech is a leading offshore software development company specializing in eCommerce solutions, custom software development and application integration. FREE Consultation.

Aventail clientless ssl vpn server
Clearview Systems supply Aventail SSL VPN servers to provide secure remote access to any resource from anywhere.

Artifact
Artifact helps companies manage offshore and onshore software development outsourcing engagements by providing an integrated set of project management, application life-cycle, and dashboard tools in a securely hosted, subscription-based service.

The Unified Modeling Language (UML) supports the entire process of modeling software. Modeling is the designing of software applications before coding. Its aim is to support the process from the requirements issued by users and other stakeholders until the actual coding of the application.

UML is a standardized way of notating different aspects of the process (hence the L for Language). UML helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements.

Because it is a language, UML is methodology-independent. A methodology defines the process that you use to gather requirements, analyze them, and design an application that meets them in every way. UML supports them all.

What does the language look like?

UML defines twelve types of diagrams, divided into three categories: four diagram types represent static application structure; five represent different aspects of dynamic behavior; and three represent ways you can organize and manage your application modules.

Structural Diagrams

Class diagram: a class definition as used within Object Oriented Design / Programming.

Object diagram: describes the relations between objects (instances of classes), it can be used if class diagrams are found to be too abstract (e.g. classes "student" and "course" will appear in the object diagram as "Sarah enrolls Project Management Course").

Component diagram: describes the software architecture, mapping of software components

Deployment diagram: shows the hardware for your system, the software that is installed on that hardware, and the middle ware used to connect the disparate machines to one another.

Behavior Diagrams

Use case diagram: a way to structure user interaction with the system (great for notating user requiremenst)

Sequence diagram: describes the flow of logic within your system in a visual manner

Activity diagram: used for business process modeling, for modeling the logic captured by a single use case or usage scenario. In each box an activity is represented and arrows from one to the next indicating next steps or alternatives.

Communication diagram: shows the message flow between objects in an OO application and also imply the basic associations (relationships) between classes.

Statechart diagram: document the various states that an object may be in and the transitions between those states.

Model Management Diagrams

Include Packages, Subsystems, and Models. These are UML constructs that help you organize all other diagrams.

At the end of the 1980s and the beginning of the 1990s the software engineering community had high hopes for CASE tools. „If we can automate everything, why not software creation itself?" Enter Computer Aided Software Engineering (CASE). James Martin even put the use of a CASE tool as a pillar in his Rapid Application Development method.

However, how it often goes with silver bullets, the tools didn't bring the much needed rise in productivity and quality. In mainstream software engineering it went silent on the CASE tools. But not for long…

The intoduction of UML (Unified Modeling Language) brought a couple of your ago new life into the CASE tools. Computer Aided Software Engineering covers the entire process from requirements determination to the actual coding, and all intermediate steps. CASE tools offer many benefits for programmers coding. As user requirements continue to drive system complexity to new hights, the CASE tools enable us to abstract away from the entanglement of source code, to a level where architecture and design become more apparent and easier to understand and modify.

The use of UML in the tools have made it possible to exchange between different tools, and have created a proper foundation for CASE in general. The popularity of enviroments like Rational Rose indicate that this time the tools may deliver what they promise.

Related links

Comprehensive CASE tool index

Use cases are a way to structure the information about requirements for a new information system. The term itself has a high level of appeal, "cases about how to use the system". The technique is semi-formal, it offers a framework for structure, but one can use plain language to describe the requirements.

It is this loose nature and the focus users of a system that makes this technique popular withing agile software development approaches like extreme programming.

What is a use case?

This technique is focussed around the communication between an information system and its users. A use case is a collection of interactions between a user and the system. The user has a specific goal to reach; so he or she is performing the interactions to achieve something. In use case language the user is called an actor. Actually the actor can also be another computer system that communicates with the system you want to build.

Every actor has one or more responsibilities. "Making sure the money rolls in by invoicing on time" e.g. To carry out this responsibility the actor sets some goals, that it tries to achieve by using the new system.

What is an interaction?

The new system printing on your screen "Hello world" is a form of interaction. Spitting out the DNA code for the cure of some dissease is also an interaction. You can use the term interaction for one interaction or a sequence of multiple interactions. So, "press a button" is an interaction, but so is "press a button, write on the screen".

The thing to notice is that a sequence of interactions is just that, a sequence, so no conditions, no if-this-then-that, just one single flow. This is also called a scenario. So, "scenario" and "sequence of interactions" can be considered the same.

During one high level interaction there can be a need to have several possible scenario's available, for certain situations a specific scenario. "When a customer calls for his invoice, I use scenario A, and when he calls for a new order I use scenario B". A collection of scenario's for a certain interaction is called a use case. In a sense a use case describes the "how to" instructions to reach a goal.

The difference between use case and scenario?

The use case takes place on a higher level of abstraction than the scenario's. The use cases can make use of one or more actors (user and/or systems) and a scenario discusses the interaction of one actor. So, to summarize…

The use case contains:

1. One or more actors

2. Goal

3. Scenarios used

The scenario contains:

1. One actor

2. Goal

3. Conditions under which this scenario occurs

4. Scenario result

Related articles

Structuring Use Cases with Goals

There are several tools available that will make your life easier by automating the requirement management process. In the end, they can't do the job for you - as seen, the tasks are complex and require high level of abstraction and analytical thinking. But these tools can keep track of things where human memory fails, and can perform the steps that need to be repeated.

To begin with, a database which provides proper access to all members of the development team is by far a better solution that passing around post-its in the office. So, such a tool should facilitate communication, with the office colleagues as well as with overseas department. Also, it should keep things organized, and allow you to identify a certain requirement and trace it back to its origins, even after having worked on the project for five years. It should also store how many changes has one requirement suffered, who initiated the changes, who approved them, when did this happen, and who performed the analysis of the impact the change would have on the entire system.

Some tools are less sophisticated than others, but still considerably useful - such as the old checklists. You will find many templates available on the Internet, you can start by using any of them and refine and adapt them to your needs. You don't know if you can actually use them, until you try. You can also see how the requirements management is integrated in the project management software you are already using.

There are also several products designed specifically for requirement management, such as RTM Workshop and Caliber-RM. They include a database with custom-defined accessibility access, and can be easily integrated with other tools (such as importing a Word document, since you'll do a lot of text writing, or combining with a project management software). They are quite intuitive and easy to use, and have some powerful features, such as underlining "suspect" requirements and defining traceability options.

They can be helpful, but they won't do the job for you, particularly where highly conceptualized and abstract thinking is necessary.

Remember that we've said, right at the beginning, that requirements have to be measurable, otherwise they are useless. Also, they need to be traceable and testable. From one diagram to another, we've seen how you can trace your requirements so you don't forget why you need such a complex option, and you don't feel tempted to replace it with an easier one, which would not suit the client.

One of the most common problems is called "requirements creep" - requirements that "creep" in, nobody knows why or from where, and they stick around, suffocating the options. This is why you need to keep track, in writing, of all the modifications made to all documents. Some requirements are legitimate, and were brought in later on, some were modified for good reasons, so you need to know, at all times, how to differentiate these from the statements that just came out of nowhere.

Another common trap is the so-called gold platting - more options, which bring very little value to the product, but increase the cost considerably. Some clients may be thrilled to have these options, but they won't miss them very much if they're not there - so you need to be careful about them.

A common sense rule says that you should be able to trace a requirement from the beginning to the finite product, in every stage. It's not enough for it to be present in the first and last stage, and it needs to occur in all the rest, to make sure it stayed consistent.

The functional criteria are easier to test, since you can see if the application fulfills the respective function or not. It's a bit trickier with the non-functional requirements, which is why you need to insist on making the measurable for the beginning. Instead of saying "the operation should be performed in the shortest possible period of time", define a time frame, in seconds, or minutes or whatever applies. Instead of saying "user-friendly" say "85% of second-grade children should be able to use the application". If you phrase it correctly from the beginning, you will have no problems testing it whenever necessary. Also, be realistic - don't ask for 100% success rate, particularly when you know that the system will have to perform the operation thousands of times per day. On the other hand, if you're dealing with maintenance for army rockets or with huge transactions involving the social health insurance budget for a large population, then you may want to aim for a success rate of 99%, or you'll be in trouble. Install as many additional safety systems are necessary, without putting too much strain on the application.

The security criteria are usually the most difficult to test and prove - it's fair to assume that, no matter how tight your security system is, somebody, given enough time and the appropriate knowledge, will find a way to cheat it. Again, defined your requirements realistically and make sure they are testable. Alternatively, provide additional upgrades whenever somebody reports a security breach - many developers do that.

Organize tests as often as possible, for the entire development duration - if a problem occurs, you want to identify it as soon as possible. Keep your original use cases readily available - they can be easily turned into test-case diagrams whenever necessary, at any phase.