By Rich Keith
You know it when you see a great software application. Youre using an application and at some point you have a moment when you say, Now thats cool! The software flows well from screen to screen, the results are as you intended and the application did all this without crashing, stopping or asking you to complete steps manually.
Software systems with this level of quality dont come along by chance. They are engineered with this quality in mind. Applications such as these were first designed, and then engineered, using a software development model, later reviewed by other programmers and then tested thoroughly.
Your goal as a provider of control systems for residences includes supplying a robust control program that drives the electronic activities in the home. How do you get to the level of reliability that you need to both succeed with your clients expectations and keep your margins high throughout the process?
There is an old saw in the software world that states that there are only three things to trade off in software development: schedule, features and quality. You can beat your schedule, but at the cost of fewer features and reduced quality (usually because testing will suffer). The way out is to adopt a structured software development environment, use it and improve it on every job. Here are some tools which successful programming shops use to
turn out repeatable and reliable results:
Software Requirements Specification. An SRS is a useful tool that I have written about previously. In the IT world, it is unacceptable to start any software project without a clear and concise description of its goals and objectives. Unfortunately, its all too common for control systems projects to be started without a design document in place. The SRS is a functional description of the control system. Some of the things that it covers are what items are on each page, how the page-flips and new pages are generated, the span of control from each touch panel, the number of favorites and presets, the starting volume in each audio zone and much more.
What do you do with an SRS? You build the SRS document using a template that you define. You know how you like to describe your control system, so start there. Charge for your time to develop this document. Get clarification from your client on the things that are unclear. This spec becomes your programmers plan of action. Get your client to sign off on the SRS before you develop any code. If you do this, you will have the benefit of documenting your design, and you will be able to charge for change orders later because your client signed off on every touch panel page.
Software Design Specification. The SDS flows directly from the SRS. Note that the SRS is an English-language, client-consumable document, while the SDS is a pseudo-code version of the actual code to be written. The SDS is intended to give your programmer the exact plan of action for building the code. It will capture the flow of the program and identify and name key symbols that will be used in the code. It will anticipate actual working conditions such as timing delays to make certain gear work. Once you have an SDS, writing the actual code is almost a non-event.
Software Development Models. Also called software life cycle models, these describe the interrelationships between software development phases. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews and deliverables. Examples of these include the spiral model, the waterfall model, the throwaway prototyping model and the evolutionary prototyping model. The spiral model is the most general. Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities. Its not so important that you pick one over the other. Its far more important to pick one and stick with it.
The spiral uses a risk management approach to software development. Some advantages of the well-regarded spiral model are:
It can be used for hardware/software system development
It defers the elaboration of low-risk software elements
It incorporates prototyping as a risk-reduction strategy
It gives an early focus to reusable software
It incorporates software quality objectives into the product
It focus on early error detection and design flaws
It accommodates life-cycle evolution, growth and requirement changes
It sets completion criteria for each project activity to answer the question: How much is enough?
It uses identical approaches for development and maintenance
Coding Standards. It is important to develop internal standards for in-line documentation and naming conventions for symbols and other variables. Major problems can be avoided with these two things alone. Often the person who wrote the code is not the one who will maintain it later, making this even more important. You may consider the rule, If its not documented it will not be installed.
Control systems programming may appear to be routine once youve done a few systems, but the payoff is in the details. That payoff is better positioning for your firm in the marketplace, improved top-line revenue and healthy margins due to fewer fixes and go-backs. Your customers can have that, Hey, thats cool! reaction and refer you gladly to others.
