| Home | Services | Software Approach | Who We Are |
| Resources | Testimonials | Contact Us | Products |
Every Software Project Can Be Successful
While every project is unique and may require special consideration, it has been my experience that successful projects apply a methodology similar to the one I use. The failed projects that I have observed are the result of not using a methodology or using it incorrectly. The methodology I use consists of the following phases: Analysis, Design, Scheduling, Coding & Unit Testing, Integration Testing, User Testing, Documentation, Implementation, and Post-Implementation. I will cover one phase in each issue.
The first phase is Analysis. The purpose of this phase is information gathering. The development team will interview the users about the project. Some questions include the following: What problem are you trying to solve? What results do you want to achieve when the system is completed? Does this project make sense for this organization at this time?
It is important in this phase to get the right people involved: the decision makers, the people who will actually use the system when it is completed and anyone whose opinion is important for the project to be successful.
I cannot emphasize enough the important of getting the right people involved from the beginning. I have seen more projects fail for this reason than any other. The application works perfectly as specified but it did not solve the business problem it was meant to address.
The facts learned in the analysis phase will be used to produce a detailed business design. This specification will show, in as much detail as needed, what the system will look like upon completion. The details of screen layouts, reports and formulae are parts of this phase. This is the phase where the user team and development team agree on exactly what the application will do and how it will look upon completion.
Allow two or more meetings where the user team can review the design presented by the development team. Each review meeting will result in changes to the design. Eliminating or short circuiting this phase will mean more problems during testing. It is a lot more expensive to fix the problems during testing. In general, the earlier in the lifecycle a problem or change is noticed, the less expensive it is to fix.
This phase also includes a technical design which contains the choice of language, database and technical tools. The functionality of the individual modules and how they relate to one are defined. Part of the technical design is creating a database schema. The schema includes defining the fields that are part of each table. The definition of fields includes the field size and data type. How the tables relate to one another is also covered.
The Coding & Unit Testing is usually the longest and most technical of the project phases. Every application needs to be divided into modules. A module is a specific portion of the program logic. It may have input, output or both. A module may call other modules.
Coding
Coding is the process of using a programming language to turn a specification into a working logic.
The Project Manager or the IS Director should establish programming standard. This is especially important in a large project. Standards that are non-existent or too lenient are problematic. The modules can be hard to understand and difficult to change. Standards that are too strict can mean that the developers will not have the flexibility to use the language to best solve the problem. The details of the standards will depend on the language, but they all should result in modules that are easy to understand and enhance.
Unit Testing
Unit testing is the process of testing the code to make sure it is working according to specification.
For a module to be unit tested correctly, every logic path should be exercised at least once. That means every possible condition that can occur should be tested but not necessarily every combination of conditions.
Integration
As interrelated modules are completed they should be tested together. This is called integration. The success of this phase will depend on how well the modules are tested before they are integrated.
Management
There is no substitution for the right technical talent in this phase. You can minimize any problems by using the more proven developers to check the work of the less proven developers. Set up a system of technical leads. They will be responsible to make sure that modules are well tested before they are released for integration. This way if there are problems with certain team members, they can be dealt with early. This can be done by additional training or by moving the more talented developers to the more critical modules.
This is the fifth in a series of articles on software project management. The first four articles of the series can be read on-line at www. metaprosystems.com/ Newsletter.htm. This article will review System Testing and User Testing. These two phases of project management have different purposes. System testing, which is controlled by the development team, tests every possible interaction between the users and data and the application. User testing, which is controlled by the user team, simulates the live use of the system to the extent possible before full implementation.
System Testing
System testing, which is sometimes called integration testing, should not begin until all modules are coded, unit tested and fully integrated. The purpose of this phase is to exercise all possible conditions that affect the system as a whole. Developers fix any defects as they are discovered. Then the modules are reintegrated into the system. Testing continues until all significant defects are fixed. User training is done concurrently with this phase.System testing is most successful when independent testers (also known as quality assurance (QA) engineers) are brought in to test the application. These independent engineers specialize in testing and like to do it. They are more qualified and can be more objective than the programmers who created the system. They will also test more conditions. If you cannot utilize QA engineers then developers should cross-test, i.e., test a component written by another developer. For example, the developer who wrote the validation module should test the reports and vice versa.It is important to have a test plan with enough scenarios, so that every possible condition occurs at least once. There should also be some "free" testing, which provides the tester time to see what happens when random data is entered and various keys are pressed in different situations. A good system should never crash; it should always give a meaning error and exit gracefully, if necessary.
User Testing
User testing should not begin until all system testing scenarios have been completed and all major defects are fixed. In real life, there is usually some overlap of user testing and system testing debugging.The most effective user teams are comprised of a representative sample of the user community. By the time testing begins they have been trained to use the system and they have written their own scenarios with help from the development team. It is important to devote sufficient time to this project to assure its success. This may mean that testers are temporarily relieved of their regular duties.The scenarios for this phase should to as realistic as possible. Use real accounts and real customers. Convert old databases to the format required in the new system. Otherwise user testing duplicates the work done in the system testing phase.
Conclusion
If system and user testing is planned, managed and provided sufficient resources, a smooth and worry-free system implementation is assured.
Documentation
Well written functional documentation can be the basis for the user guide, therefore it is very important that the project team supply comprehensive, functional specifications.
The user guide should answer any questions the users might have about how to use the application:
A good user guide reduces the need to call the developers with follow-up questions. This will save the client time and money as they develop training for the users. User guides can be printed, on-line help or both.
Complete technical documentation enables the developers to support and enhance the application efficiently and effectively. The best technical documentation is embedded within the programs themselves. Separate documentation is also needed to show how the software components fit together, how the application was implemented and how it should be maintained.
Implementation
Finally, all the hard work pays off and the application “goes live.” Depending on the project, you may need to reconvert the database. When the techniques outlined in the prior articles in this series are followed there should only be minor bugs, however, running live is not as simple as running in test mode. Successful project managers are prepared for the worst. Here are some suggestions: · Run the old and new systems in parallel, if possible · Convert or go live with only part of the system, for example one major function or one division · Have the developers on-site and/or easily reachable · Be ready to back off and return to using the old system. In the likely scenario that there are only minor problems, the developers will fix these quickly. After one cycle is completed successfully (usually a day) this marks the end of the implementation phase.
Post-Implementation
The original project team, or a subset thereof, may manage the post-implementation phase. Whoever is going to support the application after it is implemented should have also been involved with the development of the system. If this is not possible, then a portion of the original team should stay on until the new team is brought up to speed and is ready to take over. In the weeks and months following the system implementation, additional defects will come to light as users exercise various portions of the application. More complex conditions and an increasingly large database are two of the reasons for this. As the users think of more ways the application can make their work lives easier they will request minor enhancements. There may also be requests for major new functionality. This may be because some functions that were originally slated as required were left out due to time or budgetary constraints, or the use of the application has uncovered the need for additional functions. All but minor changes should be considered a new project and should follow all of the software implementation procedures outlined in this six part series.