Software Engineering process

Now I see your point. I need to read more closely :)

I agree too. That's what I meant by SW QA guys testing only to justify their jobs.

JJS

Perhaps you should say that it _can easily be_ a BS generator. It's up to the SQA group and management to keep a lid on that.

In a way that's what I was alluding to in my comment about the bureaucrats coming out of the woodwork -- you don't _want_ it to happen, but it will if you don't actively prevent it.

But a formal process doesn't have to be big, or prohibitive. It _should_ just be an agreed-upon way to do what everyone thinks is right. If you don't believe that you need to have a second pair of eyes rest on your code before you ship, then having a code review will be "useless process" to you. If you don't believe (or understand why) code should be checked in to version control before you ship, then having builds be done strictly from checked-in code will be "useless process".

Of course, if you _don't_ believe in all that stuff, you probably also feel that if you wrote it and it compiles, then it _must_ be bug free.

When I look at a process (and a set of attitudes in the engineering group that goes with it), the two questions that I want answered are "How can we make sure that what we ship now we can rebuild later?" and "How can we make sure that we've reasonably minimized the bugs in what we ship?". Everything else is fluff. It may be nice fluff to make your job easier, it may be useless fluff, but if it's not aiding your ability to ship a quality product that you can still work on after it's out the door, then it's fluff.

Op Fri, 12 Jun 2009 05:37:37 +0200 schreef Leo Havmøller :

Nice. First the writer defines Software Engineering as something requiring human judgement during all stages, then he starts wondering why it can't be more like mathematics.

=A0

The difference between computer scientists and engineers is that computer scientists write endless whiny articles like the one quoted, and engineers fold these articles into a shim to hold up their oscilloscope or to prevent a PCB from shorting out on a conductive surface.

LOL !!! That's exactly what I just did with the ESP magazine. The paper can have the other uses, too.

VLV

PCB shorting? I believe that purpose, and to provide bedding for my guinea pigs and rats, are the ONLY use I have ever found for a magazine except where my photo was on the cover or I had an article inside :)

Eeek, not a glossy magazine like ESP.

Yes, very rarely there is anything interesting in the magazines. However, as a padding, I prefer vendor line cards and advertizing materials. They look nice and professional and they are printed on the solid paper.

Fie... I meant put a cup of coffee on it.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

PCB shorting? I believe that purpose, and to provide bedding for my guinea pigs and rats, are the ONLY use I have ever found for a magazine except where my photo was on the cover or I had an article inside :)

Oh really? Since CMMI L3 is obscurely defined, and anointment possible by SEI et. al. (and the whims of the SEI "consultant"), it's impossible for anyone to say what is minimally required to reach *any* CMMI level. Furthermore, the CMMI certificate has a time limit, and paying SEI to come back is a requirement and there is no guarantee that whatever "processes" achieved a certificate will, once again, achieve the same certificate without any change. Much of what I've done to comply with the CMMI L3 "process" is pure paperwork, and of little value to the end product. If a company, large or small, is looking for a substitute for engineering discipline, don't expect any so called standard process to fit the bill. Without engineering discipline, no process will yield a successful product. If you don't have it to start with, you won't get it with CMMI (Six Sigma, etc.). I've seen code reviews that comply with a CMMI L3 process yield flawed code. Why? Because the tax on development that a CMMI ladened process imposes on engineers is almost never considered in schedule and cost. Engineers do the "process" because they are beaten to do it. Engineers do engineering because they love the intellectual challenge of building things that work. I would be very concerned if a small company, whose engineers I would assume had enough discipline to achieve the initial level of success to keep said small company in business, decided to pile on "process" to fix what isn't broken. If a small group of engineers don't have the discipline to produce a working, reliable product, they might has well fold up the tent.

by

You're preaching to the choir here. The OP was simply talking about throwing expensive and complex software at an ill-defined problem, and I was at least pointing out that it's not necessary to buy PDM software to have "a process", specifically where "a process" includes a particular, somewhat popular buzzword.

Rather than latch onto one of the branches in this thread, I decided to go back to the start.

IME, small embedded systems groups often follow the "hero" model of software development. (or maybe cowboy coding)

Rather than push for any particular process, try to focus on the things that can provide clear benefits.

Examples already mentioned - source code control and design documention

For justification: These things should parallel what the hardware (mechanical and electrical) engineers do. The electrical engineer is not done because he completed a wire wrap prototype. Design for the hardware requires blueprint documents so the product can be manufactured.

Software is not manufactured in the same way. The design document is not so much for making the software (though it is very useful for that), but for communicating to the software engineer that will pick up the maintenance what the software does, how it does it, and most importantly why it does it (ties back to original requirements).

Even if you are the one to maintain your own software, you may want to write your design down.

This is the key step in about any software development process: communicating the design. If that step fails, it doesn't matter whether you use AGILE or WATERFALL or FLAVORoftheMONTH process. And you cannot communicate the design in the code because self documenting code isn't. The code can only at best tell you what it does. It can never tell you WHY. IOW, code cannot express the detailed requirements.

So the first step is getting some documentation in place. Keep it simple, but also keep it under as much control as the hardware documentation. One place I worked did exactly that: all design documents were cataloged in the same system.

Then you will be able to show the benefits of design reviews. You should be able to pass the design document off to a junior programmer to implement. The key here is a review rule we used at another company: the design should be intelligible to the novice.

I'd better stop here, before I start working up the process improvement ladder.

But one last point: try to follow a personal development process. Lead by example.

Ed

This is simply because the customer A) doesn't know what they really want, and B) is unable to describe it to you if they did.

Garbage in, Garbage out. Works with hardware, software, society, and life.

-pete

And the customer C) changes her mind during the work.

And D) doesn't give you schedule relief, nor additional money to do the job.

We're making fun of this, but in actuality, this *really is* the problem.

Could you imagine if San Fransisco's Golden Gate Bridge was halfway done when the City decided it didn't like the "look and feel" of it and wanted major structural changes?

This is the 800 lb gorilla in the room when it comes to software engineering.

If people see large steel beams, cranes, trucks, lots of workers, and a huge hole in the ground, they are much less apt to change things because they would immediately see the ramifications of what they are about to do and how much it would cost.

But for some people sitting around computers, their minders don't see the ramfications of such actions--the drinking, the bitterness, the all around desire to leave your profession and become a sheep herder in Ireland where the problems have a demarcated domain, "The grass is eaten here, move the sheep over there". They'll just change what the hackers have to do and it'll be fine! No harm done!

It isn't fine.

-pete

Could you imagine if, in 1936 (when construction of that bridge was nearly finished), the "standard" automobile was replaced nationwide by a 37 foot wide, 200,000 pound vehicle incompatible with the bridge? Or by a flying car? (Much crazier things happen in California every day). The primary purpose of the bridge would have been obsolete and its new primary purpose would have been a trickle of foot traffic.

That exact sort of thing happens all the time in software projects because the actual functional needs of the bits of the real world that need to touch the software are themselves changing rapidly. The ability of software to be changed without digging holes or cutting steel has created a demand for changeability, and the ability to respond to this demand is a good predictor of longevity in a net producer of software.

So then why do we keep using (and sadly, designing) tools and languages which don't respond well to the needs of the environment?

The real reason why software is hard to alter once written is because the unwritten assumptions in the codebase are just that. New code often stomps on something the old code implicitly assumed and usually only when it is at the customer's site--no matter how much testing you did.

Obfuscate that problem with poor code craft, and you have a nightmare.

Programing is an operational, not formal affair. At least an engineer can tell you, "You put X tons on this bridge it will fail". Software isn't like that, people push it far beyond reasonable bounds because there is no reasonable definition for "this is too far". Only in hindsight after a system completely fails does one see that either A) an emergent behaviour of the system caused it to fail, or B) the developers kept telling people it is going to fail, and were ignored.

Much of the problem comes down to humanity having no really good idea on how to describe/solve problems where the majority of the solution involves a human's ability to perceive or understand the solution. :)

-pete

Oh, I misunderstood you. I took your message as a complaint that requirements are constantly changing, not a complaint that it is difficult to modify extant code.

This is not always true, especially not to people in this NG. Case in point, a project I've just about finished at my day job is expected to control a radio transceiver, decode and encode baseband data, and communicate over a slow asynchronous link to a master processor. My software is a "black box" that insulates the master processor from all the realtime details of the radio link.

I have specified in the documentation precisely how far my code stretches in terms of behavior over voltage and temperature, acceptable timing span and jitter windows for incoming data, and guaranteed maximum timing variations in output data. I've specified how the device will behave (in terms of data flow) in normal, saturated and over-saturated data flow conditions. I've also specified in the doxymentation where there are potential race conditions, where special processor-specific features will be required, and where there will be portability constraints (e.g. software timers sized so that they can be incremented atomically). The test plans for the software included verification of all these parameters in simulation and/or on real hardware.

The code in question is running on a specific micro and is OSless but was specifically designed (a) to be easily portable to other micros, (b) to be portable into an RTOS environment if at some future time it is decided to squeeze it into the master processor, and (c) to be able to support future, not-quite-designed-yet protocols that have much tighter timing requirements (e.g. FHSS systems).

In order to achieve goals b and c in particular, it was necessary to profile the code and document the limitations on how the various tasks fit together and identify again any timing and resource sharing issues between them. We even pre-implemented some special internal semaphores that will be required in the future RTOS version, though they aren't strictly necessary in the bare-metal version. I never want to write this piece of code again, I want to keep it as essentially a black box and move it from platform to platform.

And I would say all this explicit specification stuff is *not* uncommon for people who live in c.a.e. Not all software is written by fifteen hundred guys in Bangalore working to a deadline with an assumption of infinite resources on the target system and an unlimited supply of design by committee.

As Douglas Adams wrote: To summarize the summary of the summary, people are a problem.