Software Engineering and Ptolemy

1. What is software engineering?
2. Coding is a small part
3. What is good software?
4. Past Problems
5. What we do now
6. What we should do
7. What a user can do
8. References

What is software engineering?

Software Engineering is an engineering discipline concerned with the practical problem of developing large software systems. It is not just programming nor is it computer science. Software engineers must be professional who use theory from other disciplines and apply this cost-effectively to solve difficult problems.

Coding is a small part

Different approaches

1. The waterfall approach - Discussed below
2. Exploratory programming - Used for Artificial Intelligence (LISP)
3. Prototyping - tcl/tk, 4th generation languages
4. Formal transformation - Hard to do, little used
5. System assembly from reusable components - Object Oriented, itcl

The Waterfall

What is good software?

1. Maintainable: good documentation, clear programming conventions.
2. Reliable: Unit testing, system testing, regressive test suites.
3. Efficient: 90% of the time used in 10% of the code
4. Easy to use: Good user interface, good documentation
5. Delivered on time: planned releases

Past problems

Other problems

What we do now

1. Clean up most gcc and Solaris CC warnings. The nightly builds help here.
2. Run Purify. It would be nice if we could do this automatically.
3. Compile on multiple platforms. This helps with portability. Building under HPPA CC helps with C++ portability issues.
4. Provide three different binaries: ptiny/ptrim/pigi. Usually most of ptiny will work, even if some of the pigi won't.
5. The new makefile system helps build domain specific binaries. Making sure that the common parts are not dependent on individual domains helps here (i.e. pigilib should not depend on dmm)
6. We have a bug tracking system, which helps alot when trying to figure out what to fix next. Bug free software is a nice idea but not a reality. Tracking and prioritizing bugs helps predict software reliability
7. We have a developer's manual, which includes a style guide and hints on how to avoid creating memory leaks. In some ways it would be nice to have much of this documentation in the programmer's manual, but it is harder to update framemaker files continually.
8. Ptolemy is object oriented. Data hiding in the kernel has helped us immeasurably.

What we should do

1. We really need a regressive test suite, so we can easily check for bugs that result in incorrect output. Tycho would make this a little easier. Graphical test suites are notoriously expensive and difficult to manage.
2. Code review would be great. However, who has the time? Code review costs $$. It seems like Joe Buck used to read every line that someone checked in.

   Having people demo their work once a month might help. At group lunch, we could have 10 minute demos twice a month? Informal positive group feed back can help.

3. Having people write a software spec and then a design doc, like I did (mostly) for the tycho doc system would help increase quality. Often, by the time the coding has started, it is too late.
4. Getting people to read some of the references below would help.
5. Getting people to check code in sooner rather than later would help greatly.
6. Incremental linking of domains would allow us to read in new domains at run time, which would make us much less dependent on poorly written software.
7. We could try keeping recent snapshots of ptdesign around. This is would help in tracking down bugs, and would also provide a somewhat more stable installation to run demos from. I use the nightly builds to track down fresh bugs, but it would be nice to be able to go back farther.
8. More constructive criticism on the ptdesign email list. Polite email with solutions helps everyone avoid making the same mistake.
9. Have people include more internal checks in their code, such as assertions and consistency checks (why wait until you dump core?).

What a user can do

References