The software development process.

Hi All,

Could you please advice how you provide the software development process ?

I need some example to reference.

In my understanding is:

  1. Specification list and discussion.
  2. Solution and schedule proposed. 2.1 Critical task analysis 2.2 Other task list. 2.3 Schedule estimation.
  3. Development and Test. 3.1 Finish critical task. 3.2 Development and test function block as unit.

  1. System level / prodcut test

  2. Mass production.

Best regards, Boki.

Reply to
Loading thread data ...

Reply to
MikeStanley =E5=AF=AB=E9=81=93=EF=BC=9A


Best regards, Boki.

Reply to

Depends on what the *real* objective is, most often this will be discovered some way into the project!

That can be money, meeting a deadline, making it look like action is being taken e.t.c.

It is, for example, my experience that projects that rant a lot about "six sigma" and "quality" will realise 2/3's along the way that the true objective is actually shipping some working code at a specific date in the future - but by that time so much effort has been wasted on "quality" that the project ends up shipping garbage and another six months is added to clean up the mess. If one had gone for ship date from day one, the scope would have been set lower and the code would have recieved more work thus increasing quality without the pomp & circumstance.

Whatever you do, choose a process with rapid prototyping and testing that also allow room for the specification to be changed because the majority of the bugs will be in the specification.

It follows that the cheapest, stupidest implementation will routinely beat the clever, high-performance, "re-usable" architecture because it's cycle-time is shorter, there is more time to rework when the specification is changed and more time to refine when performance tests shows what needs refining (and if nothing changes there is more time at the beach).

I like "Agile Development" myself.

Reply to
Frithiof Andreas Jensen

Here's my list of how software really gets produced:

  1. Product promiced to a customer
1.1 Saying how wonderful it is 1.2 Making the company future depend on the sale

  1. Management realizing that there will be software involved

2.1 Management realizing that someone has to write software 2.2 Marketing arguing about what color software is 2.3 Some programmer writes some software as "example"

  1. Creation of an outline of a specification

3.1 Listing the features sales promiced the customer 3.2 Adding features marketing thinks are *neat*

  1. Writing detailed software specification

4.1 Describe software written at 2.3 4.2 Add the features promiced 4.3 Explain those added at 4.2 are imposible to do 4.4 Argue over the issues 4.5 Fight over the issues 4.6 Argue and fight over turf
  1. Budget and schedule
5.1 Estimate the time to implement each feature 5.2 Decide on man power 5.3 Do mythical man month estimations eg: Making a baby in one month by getting 9 women pregnant 5.4 Ask for budget 5.5 Get refused

  1. Attempt to kill project

6.1 List other things we'd be better off doing 6.2 Cut brake lines on salesman's car etc

  1. Manual

7.1 Fight over who will write the manual 7.2 Argue about whether anyone will really read the manual 7.3 Write the "quick start" section 7.4 Cut and paste together enough nonsense to make something thick enough to look like a manual

  1. Packaging

8.1 Copy the code written at 2.3 onto CDs 8.2 Print manuals 8.3 Order boxes and inserts 8.4 Attempt to assemble packages 8.5 Reorder inserts 8.6 Assemble packages

  1. Delivery and sales

9.1 Ship a copy to the one costumer who started the process 9.2 Look for other suckers 9.3 Promice upgrades that can't be done 9.4 Start next development cycle
--   forging knowledge
Reply to
Ken Smith

Sound advice. I'll print this out and frame it.


Reply to


Reply to
Tom Lucas

Boki, First you have to decide if you're going to play the game, or tell the truth.

The game says there is a "process" that takes "inputs", generates "subtasks", and "schedules", which go to "motivated programmers" that "follow the clear directions", and use "leading-edge tools" to generate "Quality code" that can be "integrated" and "tested" and "shipped".

As you might have guessed, a lot of us that have been in this biz for a few decades use a lot of "quotes" around "concepts" that are mroe akin to Fairy Dust than to anything tangible and usable.

In the real world, you have a customer, who almost always, cannot be troubled to write down what they want, or has already written a 400 page spec, having nothing to do with reality or practicality.

Then you have managers, who are usually failed programmers, who make wild-ass guesses as to who can do what in what time.

Then you have programmers, who sometimes are skilled, but often have faked their knowledge, taken credit for what others have done, or are sincere, but extremely slow or buggy or idisyncratic programmers. or they're drug-addled, or have family problems, or gotr burnt-out and/or screwed by the last project, or have a grudge against management.

Then you have "tools", which range from the totally unusable way up to the barely adequate.


So decide, if you play the game, you'll have to lie, lie, lie, lie, to yourself and others.

Or you could try to be truthful and say "hell, nobody can plan your typical software disaster". Point to famous failed software systems: DBase III, TSS/360, The IBM FAA mess (12 yrs, $8 Billion, IIRC). SAGE (many billions, 15 yrs?), the FBI mess (years and several 100 million $), etc... etc.... etc.....

Reply to

Do you think so? Most of the bugs I see are in the coding. Is there a spec that requires Word to corrupt files?

But the programmers won't have enough fun, and they won't be able to use the latest paradigms to pad their resumes with. I'm just an engineer, so I do use old, dumb, flat programming techniques, so my stuff just gets done in plenty of time and works, and that's no fun. I could never hire a "programmer" who would be willing to work like that for me.

My engineers all write their own code, with the reward being that as soon as they can get it done right, they can stop programming.


Reply to
John Larkin




There is - otherwise nobody would buy Word N+1 after having spent money on Word N!

Seriously - people may write requirements in abundance but they do not write what they need the system to do and which functionality they prefer over the vast list "essential" features! That part is discovered as part of the development process. If your process is cheap, you can work your way out of it - if it is "formal" you will die under a mountain of papers, inspection records, progress meetings and what not (the frequency of the aforementioned increasing the later the project gets)





Reply to
Frithiof Andreas Jensen

The question itself is quite vague. Software development process is very broad topic. While major steps you listed are more or less correct, in reality there are many nasty details and deviations from that list. There is profession called "Industrial Engineering and Management". People learn it in universities. Software development is just one of the cases of generic engineering and production.

Your list describes classic "waterfall" model of development. According to that model each steps follows after another and requirements are mostly closed in the initials stages of a project. However, this model is under attack during recent years due to its rigidity and lesser ability to adapt to ongoing changes. There is constant search for new, more efficient and less expensive development models in software industry, as well as in any other engineering field. One of the last trends is "agile develpment", which should cure lack of flexebility in "waterfall" model and diminish redundant formalism. However, "agile develpment" still required to prove itself in real life production before industry will start to adopt it on significant scale.

As a good example of practical software development I'd suggest following books. They are written by bright software managers themselves and free of excessive academism. It's a fascinating reading.

"Under Pressure and On Time" by Ed Sullivan

formatting link

"Mythical Man-Month, The: Essays on Software Engineering" by Fred Brooks

formatting link

HTH Alex

Reply to
Alex Blekhman

Hello Frithiof Andreas,

At the risk that customers become miffed and decide not to buy N+1. Ask the top brass of some auto manufacturers how that works. Some of them had to "retire" so they'll have plenty of time for an interview I guess.

I worked under very formal processes since 1986 (medical electronics). Has to be that way. It can be done but you will quickly learn that engraving the functional requirement spec in stone is a necessary part of that process.

Regards, Joerg
Reply to

I'm glad this list is within your understanding. If true, you are the first person I have met who can say this.

Software is more typically grown than constructed. Talk to the guy that wants something developed, take notes. Put these keywords into a search engine to find app notes. These app notes are your seeds. The keywords are there to indicate what kind of flower or fruit may bloom from the seed. Plant the seed on an eval board, and water liberally with more code. You may need to build a trellis of external hardware on which the plant can grow.

Most organically grown software is like the corpse flower, that attracts curious hordes by means of its noisome stench.

Reply to

Program bottom-up until it works. Then go top-down and clean it up. Most people just skip that last step.


Reply to
John Larkin

Jack Ganssle has a lot to say about this and other topics

formatting link


Reply to

Ken Smith =E5=AF=AB=E9=81=93=EF=BC=9A

Very valuable, thanks a lot!

Best regards, Boki.

Reply to


These are the folks who came up with the Capability Maturity Model, right?

Back when someone tried imposing CMM on our software group, I asked if the Carnegie Mellon folks would be available to provide consulting services for our project. The answer was, "They don't actually do any software development".

Paul Hovnanian
 Click to see the full signature
Reply to
Paul Hovnanian P.E.

This is kind of in line with a theory I had. I put up a number of open source games/projects on my website. But no real group of developers popped up to add cool features and take the code any further.

The theory I developed was that the code I released was too "complete", meaning it was good enough for whoever wanted to use it.

Now, if it had been somewhat useful but extremely irritating in one area or another, someone would have fixed it and sent a patch back, but that person would have been "hooked" and might have kept on adding stuff...

So to form a successful open source project you've got to have code that is good enough otherwise people won't bother at all, but not too good otherwise no one will add on to it...

You need a lot more too of course. :)


David Ashley      
Embedded linux, device drivers, system architecture
Reply to
David Ashley

Depends on the size and type of the project. Many projects simply involve:

  1. Write code
  2. Test code
  3. Release

Some people skip step 2 Advanced projects might have an extra first step that constitutes drawing a flow chart or psudeo code on the back of a napkin while eating your McDonalds breakfast.

Seriously though, some project timeframes simply allow no time for anything but coding and getting the first release out ASAP. I've had software project timeframes that range from "get it done by the end of the day or we're screwed" to 12 months were you have the luxury of using (or are forced to use, depending on your viewpoint) formal processes.

Dave :)

Reply to
David L. Jones

But better is to...

  1. Write code
  2. Read code
  3. Test code
  4. Release

but most people skip 2, sometimes 3, and even 4, in the sense that they don't formally release it, they just sort of set it free in the wild.

But the fastest way to get it working is to slow down and do it right.


Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.