The software development process.

[Boki]

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.

4. System level / prodcut test

5. Mass production.

Best regards,
Boki.

 

[[email protected]]

Boki,
You might start with
http://en.wikipedia.org/wiki/Software_development_process. This will
give you a quick, high level, view. Some years ago, when I was
developing CAD systems, the text we used on the subject was "The
Practical Guide to Structured Systems Design" by Meilir Page-Jones.
You probably also want to look at the Carnegie Mellon Software
Engineering Institute (http://www.sei.cmu.edu/).
Regards,
Mike Stanley
http://www.eehomepage.com

 

[Boki]

[email protected] 寫é?“：

Boki,
You might start with
http://en.wikipedia.org/wiki/Software_development_process. This will
give you a quick, high level, view. Some years ago, when I was
developing CAD systems, the text we used on the subject was "The
Practical Guide to Structured Systems Design" by Meilir Page-Jones.
You probably also want to look at the Carnegie Mellon Software
Engineering Institute (http://www.sei.cmu.edu/).
Regards,
Mike Stanley
http://www.eehomepage.com

Appreciated!

Best regards,
Boki.

 

[Sven Wilhelmsson]

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.

4. System level / prodcut test

5. Mass production.

Best regards,
Boki.

IMHO, in this area there is a great market for fraud!
The mere word "software", is an indication of this.
If you are seeking to uncover these frauds, go on, otherwise beware!

 

[Frithiof Andreas Jensen]

Hi All,

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

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.

 

[Paul Burke]

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.

The real trick is to get oodles of money without having to actually
deliver anything:

http://news.bbc.co.uk/1/hi/uk_politics/5315280.stm

It's a pity they didn't ask me. I could have done them a system like
that for a quarter of the price.

Paul Burke

 

[Frithiof Andreas Jensen]

The real trick is to get oodles of money without having to actually
deliver anything:

That's one of the key principles in politics, religion and the
wellfare state ;-)

 

[Ken Smith]

Hi All,

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

I need some example to reference.

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

2. 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"

3. Creation of an outline of a specification
3.1 Listing the features sales promiced the customer
3.2 Adding features marketing thinks are *neat*

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

 

[Tom Lucas]

<snip humour>

LOL!

 

[Ancient_Hacker]

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.....

 

[John Larkin]

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.

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

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).

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.

John

 

[Frithiof Andreas Jensen]

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

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)

 

[Alex Blekhman]

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.

4. System level / prodcut test

5. Mass production.

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
http://www.microsoft.com/MSPress/books/4797.asp

"Mythical Man-Month, The: Essays on Software Engineering" by
Fred Brooks
http://www.awprofessional.com/bookstore/product.asp?isbn=0201835959&rl=1

HTH
Alex

 

[Joerg]

Hello Frithiof Andreas,

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

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.

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)

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.

 

[larwe]

In my understanding is:

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.

 

[John Larkin]

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.

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

John

 

[Boki]

Ken Smith 寫�：

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

2. 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"

3. Creation of an outline of a specification
3.1 Listing the features sales promiced the customer
3.2 Adding features marketing thinks are *neat*

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

Very valuable, thanks a lot!

Best regards,
Boki.

 

[Paul Hovnanian P.E.]

[snip]

You probably also want to look at the Carnegie Mellon Software
Engineering Institute (http://www.sei.cmu.edu/).

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 P.E.]

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.

All of the above terms are the jargon of the MBA crowd. These people
figure that they will have at least one generation in which upper
management can be conned into financing shadow organizations whose
stated purpose is to do project planning and control. In reality, they
are just trying to figure out a way to get their hooks into department
funds. This will continue until management figures out that they are
just delivering boilerplate documents (MS Word has a pretty decent merge
function) and throws them out. If management survives the carnage they
cause, that is.

 

[David Ashley]

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

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.

-Dave