Software Development Methodology
Quality Assurance




Problems may be referred to us by contacting the support line by fax at +1 (514) 344-6046 or telephone at +1 (514) 344-6040 or  Emergency 24 hr support: +1 (514) 402-3812 or email at

By mail at:
3598 Blvd Poirier 
Montreal, Quebec H4R 2J5


Acom Computer Systems and affiliates (Open Universal Software) have acquired a well-earned reputation for software development. At Acom, we track our development productivity to established industry norms and are proud to state that we greatly exceed them. Our development organization is based on the concepts of "rapid iterative prototyping" and the "super programmer team".

Rapid iterative prototyping (RIP) is a methodology that seeks to get a working product as quickly as possible. Its goals are to prove the correctness of a design; to get user feedback on development as quickly as possible; and to add features that fit the ultimate needs of the user. The methodology is characterized by quickly having something that works, and by the easy comparison of the actual development progress to the projected schedules.

More than most organizations, Acom Computer Systems depends on "super" programmers and on senior programmers because we believe in the advantages of a team approach. Each project is divided into separate components and a team addresses each component. A team consists of a senior programmer, several intermediate programmers and at least one quality assurance engineer. The senior programmer is responsible for completing the critical path of the project. Auxiliary work is assigned to intermediate programmers as needed. Studies have shown that this type of organization tends to produce software that performs well under stressful situations. Thus, being more reliable and easier to maintain and enhance.

Portability between hardware and operating systems was a part of the Application design from the start. The development department had experience in over 40 different platforms. To ensure that Applications could be ported to different UNIX systems with ease, programming standards were established and maintained from the beginning of the project.

Several IBM development labs have told Acom Computer Systems that Open/36 has set a new standard for migration in the midrange industry, a standard that they must now compare themselves to. Our quality assurance engineers are responsible, in large part, for this praise. At Acom Computer Systems, quality assurance is a part of our corporate mindset. When Senior Technical Editors from the prestigious News 3X/400 Magazine reviewed our development efforts, they were moved to comment that Open/36 was `the most tested product in the IBM midrange, at least outside of IBM'.

Our quality assurance engineers are highly qualified (generally with over 10 years of programming experience) on the UNIX and IBM platforms. They write a series of regression tests that test every aspect of the system component. Furthermore, the suite is self-testing - it performs a test, and then tests the result automatically. If the suite involves interactive responses, a PC is used to record the keystrokes that are required for the test and the terminal images that result.

When the regression tests are completed they become the baseline documents for each programming team. The programming team must then write code that executes the same regression suite without modifications - producing identical results.

The regression tests are critical in maintaining system integrity. As with any UNIX project written in the C language, we must regularly recompile all our code to establish a new integrated baseline. At that time, unexpected problems can be introduced. We can, however, easily detect such problems by rerunning our regression tests. They track down any problems and guarantee that Open/36 works correctly. The regression tests are also critical in certifying Open/36 on various platforms.

Any changes, corrections, and enhancements once tested in-house are then moved to a pilot site where additional testing takes place. Products are only released when the components are fully tested at all levels. No code will leave our development with known problems “bugs”.