Control software development practices
Sep 27, 1999 10:11 am, by Ken Crater
Subject : Engineering
from the Developers' dept.
Text :
Would you be willing to share your own practices and opinions? I could use:  policies/procedures  standards you follow  anecdotal information (including “war stories”) Also, how effective do you feel the results have been. Could existing practices be improved, and how? Do you feel you have adequate time and resources to meet project requirements? Please feel free to reply to the list, but if you’d like to contribute “unattributed” information, you can also reply to me directly at ken@control.com . I’ll provide a pointer to the article when it’s published. Regards, Ken Crater, President Control Technology Corporation http://www.control.com

Reply

• Re: Control software development practices
  Sep 28, 1999 1:46 pm, by Tim Archer
  I have found the secret to control project management is balance. Most projects lack proper management, but many projects are managed to death. I have seen so much time spent on trying to manage the project that the management itself makes the project over budget and late. The most important part of a project is requirements gathering. It will seem awkward and useless sometimes, but I have always gone over and over the project requirements and questioned my customers until they are sometimes sick of answering questions. The only project I have ever had problems with was an incident when the plant lost their only process engineer and didn’t replace him until one week before startup. I didn’t have anyone to get appropriate answers to my questions, and so my requirements were not sufficient. Once requirements are established, I write a complete and detailed specification and present this to the customer. I prefer to present it in person and go over every section to ensure that they customer understands everything I am going to do. For projects that require drawings, I schedule time to review these with customer in detail as well. After getting confirmation of the requirements, I break them down into the smallest tasks possible and schedule each of these tasks using Microsoft Project. I base the time required for each task on the input of multiple people’s opinions, not just my own. The important thing to remember here is that the schedule is a working document. On some projects, I change this schedule constantly to reflect changes. When we look at everything we have to do, and then consider that we have four months, six months, or a year to do it. It usually seems easy, but the Gantt chart does not usually lie. If it is scheduled to take a year, it will probably take pretty close to that. Most projects are not on time because changes occur during the course of the project and the Gantt chart is not updated. Project managers think that because something will only take four hours or one day that they can squeeze it in without affecting the schedule. The problem is that after 20 to 30 of these changes are made, it has made you late and you didn’t even know it. Keeping the Gantt chart accurate at all times allows you to make informed decisions about adding new requirements during the project. If the schedule is pushed back a week because of a new requirement, you can present this information to the customer. He may decide that the new requirement is not needed, but if he still wants it, he has bought into the new delivery date. From the Gantt chart, I create weekly things to do lists. Microsft Project generates these automatically. From the weekly things to do list, I create a daily things to do list. My goal is always to accomplish the items on the weekly things to do list at all costs. That means I accomplish them in 39 hours or 60 hours. If these are accomplished every week, there is no way the project can be late unless you did not gather proper requirements, or you weren’t honest with the numbers and backloaded the project schedule. Projects are often backloaded because managers think, “There is no reason to do that task so early.” But it is important to do every task as soon as possible in the project schedule. This system is not only for outside contractor relationships. The customer can be an internal customer as well as an external customer. The customer may just be your direct supervisor. This same system works for all types of projects that I have managed. Everywhere I have worked, there have been policies, procedures, and standards. Standard scheduling with common sense will take all of these into account, but the system is has been successful whereever I’ve worked.
  Reply
  
  
• Re: Control software development practices
  Sep 28, 1999 1:50 pm, by R A Peterson
  <> AMEN! The company I work has even gone to the extent of charging customers to determine exactly what it is that they need to have done. Many times they have only a vague idea of what is required. I like examples so heres one from a project I worked on last year. One of the requirements was that the PLC had to interface with a cell controller. At the start of the project it was stated to us by our customer that this was a serial (RS232) interface that consisted of 2 characters for part pickup and a different two for dropoff, but little was actually known about the protocal. We quoted 10 hours to do this in a BASIC module, as it seemed very simple. Way into the project, I finally got a copy of the protocal for the information interchange. It was a word file that when printed out was over 75 pages long. The transmission strings were far more complex then stated and included a checksum, duplicate transmission detection, and part tracking in both directions. The ten hour project ended up taking more like 50-60 hours.
  Reply
  
  
• Re: Control software development practices
  Sep 28, 1999 1:44 pm, by Bill Hullsiek
  Hi Ken, Would be interested if you are looking at using the Capability Maturity Model (CMM) from Carnegie Mellon Software engineering institute ? This might be a good survey question to the list, i.e., how many people are familar with the model. I doubt if the advances made in Aerospace and Avionics are being used effectively in the Control Systems world. (Even though firmware and microprocessors share a common heritage).
  Reply