A sustainable software application that can accommodate change and evolve is constructed when the principles of software engineering are used in the development of the application.

With the inevitable evolutionary process of technology and business demands, software will undoubtedly require change. Change may come in the form of newly discovered errors that must be corrected, results that need to be refined, or software that demands tailoring to fit the needs of a new information system or because the client requests functional changes or enhancements. No matter the size of the application, change is inevitable.

Change doesn’t occur only after the software application has been delivered to the client. Change starts as early as the Analysis Phase of the engineering life cycle, when software specifications are refined, and continues through the Design and Implementation stages. Change also occurs during testing, as errors are discovered and corrections made not only to the software design but to the application’s programming code as well.

Our software engineering methodology takes into account that change is an inevitable part of software. The engineering principles of the Systems Development Life Cycle help ensure that the software will be friendly to such change.

In order to engineer a software application that accommodates change as the client’s business needs evolve or grow, it is important to engage the client at the beginning of the project.

We like to get our clients involved early in the development process. When software specifications and requirements are being defined, which encourages them to take an active role in the development process and increases their understanding of how business requirements will be satisfied by the software paradigms we establish. This direct involvement allows changes to be more easily administered.

Time with each client is invested in regular consultation beginning with the Analysis Phase of the Systems Development Life Cycle, when the statement of scope is identified. The client actively participates in the critical review of the Software Specifications, where he or she can ask questions and pose suggestions, which may result in further refinement of the document. It is more efficient and easier to incorporate changes at this stage rather than late in the game and helps reduce costs and keep development on schedule.

We employ a set of software engineering standards that further accommodates changes to software, which includes the following:

1. Clear and well-defined statement of scope
   A statement of scope clearly describes the functionality of the software.
2. A design that fosters functional and modular independence
   Functional and modular independence accommodates change because changes made to one module will not adversely impact any other module.
3. A program structure with top-down design
   Most requested software changes apply to low-level modules. Top-down design allows changes to low-level modules with little or no impact on the overall system.
4. A design that represents simple and stable data structures and databases
   Our designs promote simplicity and stability, which help eliminate database anomalies.
5. A design document that is current
   Keeping a design document that is consistent with the evolving software application allows prospective changes to be reviewed for functionality and impact before being applied to the actual application.

When modifications are required, we then apply the following software engineering standards:

1. Software engineering principles are used for major changes
   When major changes to a software application are required, the systematic software engineering principles of Systems Engineering, Analysis, Design and Testing are applied once again to ensure that the system is stable, reliable and secure.
2. Regression tests examine and confirm every modification
   Regression tests ensure that new errors or unexpected results have not been introduced after modifications have been made to a software application.
3. Effects of modifications are evaluated prior to implementation
   Effects of changes are analyzed before they are implemented to make sure that they do not produce widespread problems.
4. A Formal Technical Review ensures quality
   A Formal Technical Review (FTR) is used to expose, isolate and correct errors, and assures that the software modifications match the customer’s requirements.

Software is an ever-changing, evolving entity. Technologies advance. Consumer needs change. Businesses grow. Change is a fundamental and an inevitable part of software. When careful time is taken during the original development cycle in Analysis, Design, Implementation and Testing, and when Maintenance is always a matter of important consideration, a sustainable software application will be engineered. The result is an application that is more easily maintained and costs less for the customer over time.