Software Engineering
Our team has been developing software since 1999 with Igence, and for many years before that for a variety of companies. Collectively, we have experienced many approaches to software design and development. We know what works and what doesn't work. We now have a proven process that, so far, has always delivered impressive results.
The Process
The Igence Framework
Using an application framework is an obvious way to develop software, since most projects can share many design features. However, an effective multi-project application framework is not easy to develop. To make matters worse, if it is badly designed it can hinder development rather than help it. There are many third party application frameworks available that work well, but usually have limited scope.
We have developed an application framework to under-pin our applications. It's been difficult and time consuming, but we've persisted because we couldn't ignore the obvious and overwhelming benefits. We have made our framework a central part of our software development process: It's used, supported and maintained by all our developers.
We believe it now gives us several important advantages:
- A large proportion of any application is already written, saving valuable time.
- Many fundamental software architectural problems are already solved.
- The design has been tested and optimized for much longer than the lifecycle of a single project, so gives significant efficiency and robustness to an application.
- Many cross-platform issues are solved: the framework supports Windows, Mac and Unix platforms and is designed to make porting to other platforms easy.
Here is a brief overview of the Igence Framework:
- Cross platform Graphical User Interface components, including controls supported by each platform, but also custom drawn controls for windowless environments, e.g. embedded or bespoke hardware.
- Integrated OpenGL support.
- Encourages a Model/View/Controller design pattern for applications.
- Model objects with support for value range checking, formatting and persistent storage (e.g. via XML).
- Communications objects for defining arbitrarily encoded messages, Sockets, Database interfaces, e.g. ODBC, XML support.
- Scripting objects that allow asynchronous application control flows to be more directly implemented.
- Integrated support for automated and remote testing.
- Highly configurable logging.
- Various utilities for common mathematical functions, string manipulation, etc.
The framework is written in ANSI compliant C++, using the C++ Standard Library and STL. Though written in C++, it is perhaps the design of the framework that is most important: We have successfully developed partial versions in other languages as required, e.g. Ada 95.
Our software development process is designed to deliver the software our customer's want. That means it has to allow customers to change their minds. It has to allow us to rework our code freely to improve and optimize our designs. It has to keep customers involved and the software visible at all times. It has to help us be adaptable.
A brief overview of our process is described below. That said, being adaptable sometimes means changing the process itself. After all, two projects are rarely the same.
Establish Requirements
System complexity often makes complete and accurate specification difficult. We try to solve this problem in several ways:
- Our process allows changes to specifications to be made during development without impacting costs or timescales.
- We regularly demonstrate progress, so required changes are spotted early with less impact.
- We purposely organize development to produce a bare-bones application first geared towards the functionality that can demonstrate our understanding of the requirements and expose problems, misunderstandings and inconsistencies. This may take the form of a dedicated demonstrator application that will be replaced once specification is agreed.
Quote a Fixed Price
If possible, the specification phase should be a relatively short and separately costed activity. That way, we should be able to more accurately estimate the effort required to complete the job. Without a separate phase, it is likely we will quote a higher price (sometimes significantly higher) to allow for unforeseen problems and requirements.
Plan Deliveries
We will plan multiple deliveries, containing partial functionality throughout the development time. The content of each delivery will be discussed and agreed so that, as far as possible, the customer gets the functionality in their preferred order. We will also try to implement higher risk components first.
Develop the Software
Each delivery will have been tested, even though it only constitutes a partial system. This is because we develop our tests as we develop our code. As far as possible, these tests are designed to be automatic, so that retesting, following changes, is at the touch of a button.
Integrate and submit for Customer Acceptance
Once complete, the application is submitted for acceptance by the customer. This often involves the customer performing their own test and integration tasks. We'll help diagnose integration issues and make appropriate code updates to get the system working.
Formally Release and Document
Once integrated, the software is formally released. At this point, we would develop any documentation that is required. Our preferred documents are a Maintainer's Guide and a User's Guide, because these are useful to maintainers and users of the software. Often, there are many lengthy documents produced that add no value, apart from a tick in a Quality Assurance box.
We prefer not to develop design documents during the development process, as the document maintenance overhead reduces our ability to adapt to changing requirements quickly or cost effectively.
Our main priority is that our customers get the software that they want, and that will require us to offer maximum flexibility during development.
Initial Support
The software enters a free support period where we will agree to fix problems found when the software is in service. To some extent, this is included in the original price, unless exceptional response and bug-fix turnaround times are required.
Maintenance
A separately negotiated maintenance contract can include longer term support, or perhaps provision for changes and extensions to the software to be accommodated.
