The Artima Developer Community
Sponsored Link

Weblogs Forum
Stages of Software Development

23 replies on 2 pages. Most recent reply: Feb 10, 2007 5:46 AM by Fermin Ordaz

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]
disney

Posts: 35
Nickname: juggler
Registered: Jan, 2003

Re: Stages of Software Development Posted: Feb 6, 2007 2:13 AM
Reply to this message Reply
Advertisement
I try to minimise the phases of software development, for simplicity and ease of understanding. I cannot get down to less than this: requirements gathering; design; implementation. Of course, my broader titles incorporate all the finer-grained stages discussed here. E.g. 'implementation' includes testing (TFD/TDD), coding, refactoring and so forth.

Thanks for a thought-provoking and interesting list.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Stages of Software Development Posted: Feb 6, 2007 2:53 AM
Reply to this message Reply
> What specifically are the distinct phases of software development? I was taught there were about 4 or 5, but I believe I have identified a few more.

Before anyone else can answer that question for you, you need to define what you mean by "distinct phases". I think it means something that applies to the whole project and encompasses work that must be completed before the next phase can begin (aka 'the waterfall model'). However, you start with five phases and immediately increase it to nineteen, so I'm sure you must really mean something different.

In addition, I think that a number of the "distinct phases" you added are not that distinct. Refactoring, for instance, is a coding technique and not a separate process. The same goes for code documentation. I don't believe that it is possible to add meaningful code documentation to completed code, therefore it most definitely shouldn't be treated as a "distinct phase".

On the other hand code documentation and product documentation are entirely different beasts but you appear to have rolled them into a single phase.

Equally, I'm not sure what you mean by "extending" and "revising". They both appear to be different ways of describing the process of adding new features to the code.

There are already many, many articles and books out there that cover this ground and I would (humbly) suggest a bit of background research on the subject would be more productive that compiling an ad-hoc list of software development tasks or 'distinct phases' or whatever.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Stages of Software Development Posted: Feb 6, 2007 6:00 AM
Reply to this message Reply
>This is where you throw the book back at your client,
>once in a while, and tell them that if it's really that
>complex to implement, perhaps the problem is with their
>business model?

I agree completely, but as an internal person who occasionally manages outside contractors/consultants, I can say it's also a good way to end up being told that your services are no longer needed. I personally wouldn't find it offensive, but why would I spend money to implement a defective business process?

Raji Gogulapati

Posts: 5
Nickname: rajig
Registered: Nov, 2005

Re: Stages of Software Development Posted: Feb 6, 2007 9:08 AM
Reply to this message Reply
> Interesting topic. I'd like to tentatively add to that
> list
>
> * Complexity management
>
> This is where you throw the book back at your client, once
> in a while, and tell them that if it's really that complex
> to implement, perhaps the problem is with their business
> model?
>
> Should software cater to every whim? I think software is
> a service industry, but it's strange, because if a
> software engineer is too client-oriented, there is a good
> chance to bury the quality of service alive under the
> rubble of complexity.
>
> Maybe trying to please the client too hard leads to
> ultimate a complete and total failure for both client and
> developer?
>
> Software world has it's own rules. Software is very
> flexible, but it's not as flexible as air or as
> accommodating as space.
>
> I think sometimes engineers are too conservative with what
> they tell their clients they can do. And then at other
> times they are too liberal. How to know which situation
> is which?
>
> And even if we do know the situation today, can we please
> be allowed to change our minds tomorrow, or should we be
> hanged by the noose of out own yesterday's insight?
>
> When the business rules in a project go insanely out of
> whack, such that no person even knows them all, and there
> is no document that covers all of them, and often the code
> is the only document you have, what phase of development
> is that?

Complexity management is treated as Scoping in my opinion. Presenting the scope of the issue at any stage would bring out what can be done at what stage. This helps every step of the way.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Stages of Software Development Posted: Feb 6, 2007 10:11 AM
Reply to this message Reply
> > What specifically are the distinct phases of software
> development? I was taught there were about 4 or 5, but I
> believe I have identified a few more.
>
> Before anyone else can answer that question for you,

My intent is not to for people to answer the question *for* me, simply to share their impressions and thoughts.

> you
> need to define what you mean by "distinct phases". I
> think it means something that applies to the whole project
> and encompasses work that must be completed before the
> next phase can begin (aka 'the waterfall model').
> However, you start with five phases and immediately
> y increase it to nineteen, so I'm sure you must really
> mean something different.

Nothing about the word "distinct" implies such a linear dependance, they are in fact interleaved. However it is clear that the word distinct is prejudicial so I have removed it.

What is distinct about these stages is that they can be clearly identified as tasks with a clear set of tasks and responsibilities.

> In addition, I think that a number of the "distinct
> phases" you added are not that distinct. Refactoring, for
> instance, is a coding technique and not a separate
> process. The same goes for code documentation.

By refactoring I mean when the code design is changed (e.g. the architect chooses to use one design patter instead of another midstream), but which does not affect the behaviour of the product in anyway.

> I don't
> believe that it is possible to add meaningful code
> documentation to completed code, therefore it most
> definitely shouldn't be treated as a "distinct phase".

Have you ever had to debug poorly documented legacy code? The first step should be to add comments as you start to decode the spaghetti mess. Not doing so is irresponsible, and will leave the next person in your shoes with the same problem.


> On the other hand code documentation and product
> documentation are entirely different beasts but you appear
> to have rolled them into a single phase.

Good point. I updated the list.

> Equally, I'm not sure what you mean by "extending" and
> "revising". They both appear to be different ways of
> describing the process of adding new features to the
> code.

By revising I mean changing the behaviour of existing features.

> There are already many, many articles and books out there
> that cover this ground and I would (humbly) suggest a bit
> of background research on the subject would be more
> productive that compiling an ad-hoc list of software
> development tasks or 'distinct phases' or whatever.

I disagree. The point of posting this list on the blog, was to provoke discussion and share knowledge back and forth with people. My experiences and impressions after over a decade of professional software development experience still has some value which people clearly appreciate.

I also think you probably put a bit too much faith in books, and undervalue the importance of discussion. In my work experience (including Microsoft) it is painfully clear that very few people have given much thought to the importance of these different phases and how they are interconnected. At the very least I can hope to provoke some thought and discussion.

Bernard Farrell

Posts: 6
Nickname: bernfarr
Registered: Feb, 2003

Re: Stages of Software Development Posted: Feb 6, 2007 11:52 AM
Reply to this message Reply
Call me sarcastic, but I think you're missing the Cut n' Paste stage.

I think this happens when panic sets in and any of the normal rules have been abolished.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Stages of Software Development Posted: Feb 6, 2007 12:16 PM
Reply to this message Reply
Christopher Diggins wrote The point of posting this list...

afaict you haven't identified the purpose of the list itself - we might provide one list of broad-brush strokes as an overview for student novices, and a very different list as a process definition on a particular project.


Christopher Diggins wrote I also think you probably put a bit too much faith in books, and undervalue the importance of discussion.

It didn't seem to me that Vincent O'Sullivan was expressing faith in books - just that this topic has been discussed many times, so it might be helpful to understand in what way existing stage characterisations may be inadequate.


Christopher Diggins wrote In my work experience (including Microsoft) it is painfully clear that very few people have given much thought to the importance of these different phases and how they are interconnected.

Maybe they didn't read the books :-)
Maybe it hasn't actually been important to their work?

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: Stages of Software Development Posted: Feb 7, 2007 4:38 PM
Reply to this message Reply
> > Interesting topic. I'd like to tentatively add to that
> > list
> >
> > * Complexity management
> > [snip]
>
> Complexity management is treated as Scoping in my opinion.
> Presenting the scope of the issue at any stage would bring
> out what can be done at what stage. This helps every step
> of the way.

I understand scoping as, simply put, "this is what we will implement, and this is what we will not implement". However, that's not the same thing as complexity management because it doesn't provide any feedback to the client about the complexity of requirements. Saying that you won't implement something is not the same thing as saying that something should never be implemented by any team, no matter how good, on principle, because it's a defective process in the first place.

I define processes defective when they are frustrating and painful by original intent. If the pain is intended, perhaps unconsciously and tacitly through consent, then I don't think we should always go along with it.

Yes, sometimes it means we may have to say "no" to some money or, heck, even our lives perhaps.

But if we always say "yes", "yes", "yes", "yes", "yes" to everything...what stops the client from becoming fundamentally insane?

I think programmers (and employees in general, and all people in service industries) are like women. We aim to please. But just like a woman, who always says "yes", "yes", "yes" no matter what, can end up in an abusive relationship, so can programmers. (I say this as a red-blooded man). It's one thing to say we won't do some chore (scope), but it's another thing to live with someone who cuts off a finger for dinner every day (fundamentally insane, complexity management).

Returning closer to the main topic, I agree with the topic originator. Basically the simplistic breakup of project phases is just that -- simplistic. In reality projects are fluid and are not strictly categorizable into phases.

Fermin Ordaz

Posts: 2
Nickname: fordaz
Registered: Jun, 2005

Re: Stages of Software Development Posted: Feb 10, 2007 5:46 AM
Reply to this message Reply
I found the post very useful as a "down to earth" mental exercise. I assume many of us have read books about the topic, but still I consider valuable this kind of distilled thoughts, coming from "actually doing things" than just reading.

I've found also important a phase of training new hired consultants about the problem domain, internal libraries, frameworks, existing legacy code and internal dev guidelines.

Of course this is not always the case, but if you are planning to hire part of your team, this “ramp up” phase plays a key role in the project.

Flat View: This topic has 23 replies on 2 pages [ « | 1  2 ]
Topic: Stages of Software Development Previous Topic   Next Topic Topic: Testing Genes, Test-Infection, and the Future of Developer Testing

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use