Connect with us

The software development process.

Discussion in 'Electronic Design' started by Boki, Sep 8, 2006.

Scroll to continue with content
  1. Boki

    Boki Guest

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

  3. Boki

    Boki Guest

    寫�:
    Appreciated!

    Best regards,
    Boki.
     

  4. 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!
     
  5. 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.
     
  6. Paul Burke

    Paul Burke Guest


    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
     
  7. That's one of the key principles in politics, religion and the
    wellfare state ;-)
     
  8. Ken Smith

    Ken Smith Guest

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

    Tom Lucas Guest

    <snip humour>

    LOL!
     
  10. 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.....
     
  11. John  Larkin

    John Larkin Guest

    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.

    John
     
  12. 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)
     
  13. 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
     
  14. Joerg

    Joerg Guest

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

    larwe Guest

    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.
     
  16. John Larkin

    John Larkin Guest

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

    John
     
  17. Boki

    Boki Guest

    Ken Smith 寫�:
    Very valuable, thanks a lot!

    Best regards,
    Boki.
     
  18. 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".
     

  19. 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.
     
  20. David Ashley

    David Ashley Guest

    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
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-