Tometa Software MetaXpert

What do you want to do...?

Call Us:
1 (208) 265-4700
Download Software Download Software
Purchase Software Purchase Software
Products Products
Services Services
Get Support Get Support
Software by Tometa is
Designed for Windows The "Designed for Windows" logo helps customers identify products that deliver a high-quality computing experience with the Microsoft® Windows® XP operating system.
Certified for Windows Vista "Certified for Windows Vista" logo identifies software that is independently tested for compatibility, functionality and reliability on Windows Vista-based PC's.

Tometa Software is a
Microsoft Gold Certified Partner
Microsoft Gold Certified Partners are the elite Microsoft Business Partners who earn the highest customer endorsement. They have the knowledge, skills, and commitment to help implement technology solutions that match your exact business needs.

Microsoft Gold Certified Partners have passed the highest level of requirements from Microsoft and have demonstrated the most robust, efficient and scalable implementations of Microsoft technologies in demonstrated enterprise customer deployments or an on-site Microsoft assessment.

Make Your Software Idea a Reality


Tometa creates custom software for you

Tometa Software designs and develops robust software solutions for virtually all industries including in-house (vertical market) and retail software, some of which is on the shelves at your local software store. We focus our unique combination of creative, technical, and problem-solving skills on meeting our client’s objectives. Because of our clarity of purpose, commitment to process, and broad professional skill sets, we are able to provide our clients with world-class solutions that are functionally superior and fully aligned with our client’s strategic focus.

Balancing development speed, quality and cost is what we are all about. Tometa combines agile development practices with fixed pricing, so you know what the cost, end product, and delivery time table look like?up front. If we underestimate the effort, we complete the overrun on our dime. Simple as that. That?s why large enterprise firms like Alcoa and NASDAQ choose Tometa.

Tometa?s agile development expertise and low-overhead US location keep our prices comparable to offshore vendors ? without offshore challenges. Using a fixed pricing model, we provide upfront visibility into a project?s ultimate costs, end product and delivery schedule. Our clients like knowing that we have ?skin in the game? ? a fixed price that aligns our goals with yours, incenting us to get the job done right and fast.

Lastly, as a Microsoft Certified Gold Partner, Tometa Software, can customize its products or create custom web, client/server, and traditional applications. With programming experience in C#, C++, Visual Basic, CGI, HTML, RPG, Delphi, Java and many others; Tometa Software is uniquely positioned to meet your needs as a development firm.

Check us out today



v   Introduction – Your Software Idea

v   A System, a Method, a Plan

v   Getting Started – the Needs Analysis

v   The Requirements Definition Stage

v   Scope

v   Design

v   Specifications

v   Development

v   Testing

v   Roll out.

Introduction – Your Software Idea.

When I was a youth, my dad always told me that I got a lot of &quotmillion dollar ideas&quot.  Well, we all get great ideas, sometimes for new products or software applications but the real challenge is the process of making those ideas turn into a tangible software product that can be sold or implemented profitably.  But then every software package we use from Excel to the game of Myst to the Internet itself was an idea at some point that changed into a reality. 

The good news is the process of defining and building software is a project management method that is quite well defined.  There are a lot of things to think about when making software come to life.  It is worthwhile to do some research on whether the idea has been developed already and if not how to protect your idea once it gets into development, especially since if no patents exist, many times you can use ideas and features from competitors.  This white paper will primarily focus on the technical process of taking a software idea from concept to distribution, i.e. making it a reality.   By using many of the methods described in this paper, the process of software creation will be much smoother, more economical and be less prone to costly pitfalls.

We will discuss what you will need to be successful at building your software project.  This paper assumes that the project is being developed within an already existing corporate structure like Tometa&acutes custom software development offices.  The process of software creation by nature must occur within a setting where there are development resources, programming computers and compilers, management tools and test beds and of course, programmers.  These resources can be hired, trained and purchased; but a viable option to get production underway quickly and efficiently is to outsource the work through a quality contract development provider with impeccable references such as Tometa Software, Inc. 

A System, a Method, a Plan

The processes and steps described below can be used in any software development effort whether it be a windows game, a new web site or an application to be used in the corporate world.  It is a development methodology that goes back several decades known as the Systems Development Life Cycle or SDLC for short.  Now over the years tools and resources have been created to streamline the process.  One such tool is Microsoft Project which has excellent resources for coordinating the process of software development.  However, the process used here can be done with nothing more than a word processor and a spreadsheet.  The key is to proceed in a structured fashion from step to step to assure that the project is built in such a way as not to waste resources and cut down on the risks of development.

There are risks in building a new software application.  The process can be quite costly and lengthy.  A typical software development cycle can take anywhere from three months to three years to complete.  If the design of the software is not thorough before the first line of computer code is generated, it can cost huge sums to correct in the testing phase or cost even more if the software goes to market or into production flawed.  The higher level of expertise and experience that can be put against the preparation process, the more that risk can be mitigated.  Utilizing a trusted business I.T. firm such as Tometa, can assure that the greatest skill can be placed against the areas of the plan that are most at risk without incurring overhead for the entire project development process.

The 3 &quotP&quots of software development are Prepare, Prepare, Prepare.

Getting Started – The Needs Analysis

The preparation for software development consists of several dependent steps each of which must be successful for the next to occur.  The first step is The Needs Analysis Document.  Needs analysis asks the blunt question: &quotWhat need does this software solve?&quot 

The needs analysis phase feeds the design process by defining the true nature of the need.  The outcome of the process is a problem statement which defines to the designers, the users and the developers just what this software is supposed to do.  If we are able to realize a thorough understanding of the problem then the needs analyses document will contribute tremendously to the rest of the development effort.

It is not always easy to gain a realistic problem statement.  One of the most common errors that consultants encounter is users asking for a solution that does not solve the problem they have.  It pays to dig a little deeper, ask some relevant questions about exactly what the problem is. 

Now if your software idea is being developed to be sold commercially, there may not be a &quotneed&quot for the software but there may be a potential market.  In that case a market analysis serves the same purpose to address the question &quotis there a market for my software?&quot  In some cases, an outside firm might be needed to conduct the market analysis. If that is expected, a line item in the project budget should be introduced early in the project life to fund the study. 

The last step in this process is the User Sign Off.  The document is reviewed by the customer and if the step has been successful, both developers, managers of the development process and the users sign a document stating that the step was complete.  By signing off each step of the way, the team agreement is documented which streamlines development and focus as the product begins to take shape.  A common unfortunate interference to sign off can be internal corporate politics.  A skilled project plan accounts for that danger.  In some cases the use of an outside objective project team member such as the skilled project leadership team leaders at Tometa can provide a way to reduce the impact of politics on the crucial sign off phase.

The Requirements Definition Stage

The Requirements Definition Stage defines &quotWhat does this software do? &quot   The requirements are stated as Functional Business Requirements of the software.  Even if the software is not being prepared for the &quotbusiness community&quot the requirements should be stated in non technical terms, in terms that can be understood by the user. 

The requirements definition will be in greater depth than the needs statement.  For example, for a web page, we might have a Business Requirements Design, or BRD, addressing security, another addressing adding a shopping cart, another about the search engine optimization issues of the site and still another about the data infrastructure supporting the site which will not be visible to the user at all.  This list of requirements will feed the generation of a specifications document which gives the developers what they need to build the software.

The key word is &quotrequirements&quot.  This document will define what the software must do to achieve its stated objectives.  There may be additional functions and features that the software &quotcould do&quot but those should be listed as an addendum. 


The Scope Document then is the outcome of all of the hard work that has gone on to date. The Scope will spell out in detail just what is &quotin scope&quot and what is &quotout of scope&quot for this project.  The Scope document expresses in a clear narrative:

  1. The software approach
  2. What the resulting product will look like?
  3. What market or business need it will satisfy?
  4. What components will be needed to make that design a success?

Along with core design concepts, the scope will also deal with interfaces, infrastructure issues such as date base specifications that must be observed, communications protocols, language preferences and the like.

As before, in the final step of the scope document is for all project participants, key team leaders and the clients and sponsors of the project will &quotsign off&quot on the scope signifying that all is clear to develop the project exactly as it is described in the document.

Much of this documentation and signing off may seem somewhat unnecessary.  A developer will often think &quotlet&acutes just program the thing&quot and get moving.  However, when dealing with a software project of significant investment and time in development, these steps are absolutely critical to the success of the final product.  Long experience has proven that the developers will be very glad these documents have been prepared when the rigors of development get underway.  Above all, a thorough completion of these steps satisfies our challenge which is to satisfy the three P&acutes – prepare, prepare, prepare.


The Design Document is not the final step before the project goes to the programmers but it is an important linking step.  The Scope Document defines the project in lay terms understandable by business leaders and management.  The Design Document is the first bridge to the actual technical infrastructure of how the job will be done.

In the Design Document, a flowchart showing how the software logic flows from step to step, or web page to web page if appropriate is included along with the narrative discussing that flow chart.  If there are web pages or Graphical User Interface screens, mock ups of those will be included in the design document.  Further details concerning the technical infrastructure requirements are presented including Data Base Management System, or DBMS, system requirements, table schemas, communications expectations and hardware or component specifications that have become a requirement of the design.  In preparing the design document, take full advantage of technical expertise.  In addition:

Take advantage of modular and object oriented design concepts.   By designing the product in a modular fashion, common functions can be reused throughout the life of the project.  By implementing object oriented design concepts at this early stage, appropriate hooks and interfaces that are even internal to the project can be placed into the design which will keep the development team from loosing time later on due to redesign of the product to accommodate a modular approach.

Don&acutet forget about interfaces.  In addition to internal interfaces between objects or modules, if the product must interface to external software products, place the design of those interfaces in this document and begin to identify where in the program flow for these will occur.  If there are needs for technical interface information from an external vendor, the design team should gather that information so that when the final specifications are handed to the developers, much of what they need is already complete so speeding up the development.

Plan Ahead for Testing.  The design document will serve two roles in the project life.  It will lay down the product design at a greater technical level to begin to facilitate the developers but it will also lay down the hardware and environmental needs of the project for the rest of the cycle.  As such, testing must be planned for.  If the testing is to occur as the product is being developed, a schedule of development should be defined so modules are turned over to testers in a logical and streamlined fashion.  A section of the design document should address testing categories and hardware needs which will eventually be used to design the testing regime when that part of the project gets underway.


The detailed documentation that brought us into the development stage should make generation of specifications much smoother.  The specifications document is what the programmers, data base subject matter experts and other technical team members will use to create the actual software product.  It is written in technical language tailored for each developer.  The logic programmers will have a set of specifications as will the web developers, the DBA team, the hardware and communication staff, etc.  The document should be prepared in sections to address each technical team&acutes orientation and include all the detail they need to begin work on the software production as quickly as possible. 


Once the development is underway, time must be allowed for the technical team leaders to do their work.  There will be clarifications on the intent of the specifications and that is where the design, the scope and even the needs analysis will be helpful. 

Concurrent with the systematic program execution, the project leaders will have placed a schedule into the planning documents that will detail the development time table.

The traditional development plan will include begin and ending date for the development and testing phases.  This is a linear approach that defines development as a dedicated time during which design is done but testing has not begun.  In that way, it is clear to the team and if done well results in a good solid product.

A second approach that might be of value is an interactive development cycle.    Using this approach the design, development and testing phases occur concurrently.  This is a much more dynamic approach in which &quotversions&quot of the software might be in design, in development and then on to testing while other parts or revisions are in other phases as well.  The iterative approach is a good method to quickly get the developers to work and to develop rapidly and to give the design process a longer time for their efforts as well.  However, it places a greater demand on the managers and coordinators and should be approached with fore thought to assure the success of development.


There are four phases of testing each of which has a particular focus and satisfies a specific need.  They are:

Unit Testing

This is the testing the developers do as the programs are written and made functional in the &quotprogramming labs&quot.  Unit testing is ongoing until the developers are done.  Even if subsequent tests send programming modules back to be fixed, the unit testing discipline is completed and documented.

Strategic Testing

Once the developers have tested their work, the project team tests the product in line with the design document and what the software is &quotto do&quot.    While the developers will focus on technical function, the strategic tests look more closely at user functions but still run though all logical paths of the software to find, document and find fixes for any program problems or &quotbugs&quot

User Acceptance Testing

The final phase in which a body of future users of the product give it one more run through before it goes into full production or to the market.  These tests should not produce &quotbugs&quot but rather surface any functional flaws that must be corrected for the software to be viable.

Roll Out

Early in the design process, a roll out approach and plan will have been developed by the team leadership.  If the product is going to a marketplace, that plan will involve mass production and distribution.  However if it is going to a large number of corporate users and particularly if it is upgrading an existing software, plans must be carefully thought out for a seamless release of the product.  There may be cause to consider a limited roll out strategy.

Another popular method of extending the testing cycle into roll out is to release the software in the form of Alpha and Beta releases which are actually testing releases.  In this way the software gets into the hands of the users but there is still opportunity afforded for refinements and improvements.  This is the method that Tometa prefers.

A methodology of this nature will always be most beneficial to the development process if done under the leadership of team leads or consultant talent that has back ground in the craft.  If such talent is on staff, utilizing them in this way will greatly benefit the organization.  If not, consider using outside help by contract.  Tometa&acutes trained and experienced project team members can provide any missing skill sets needed to make the SDLC method serve your project well.  Whether it be to help with just a part of the process, the research and preparation of the needs analysis or requirements definition, or if it is the application of skills with tools such as Microsoft Project, Tometa can tailor the assistance to work with all or part of the process and assure that your development plan is executed efficiently and successfully.

Still have some questions? Ask us in our software development forum!

Ready to get a quote on your next project? Get Started.


This document is for informational purposes only. Tometa Software, Inc. MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Copyright © 2004 Tometa Software, Inc. All Rights Reserved.

[Back To Top]

Sunday, December 08, 2013 (208) 265-4700 Copyright © 2010 Tometa Software, A MetaXpert Company. All Rights Reserved SITE MAP
Custom Software Development | Bespoke Software Development | Software Resources