Development Cycle...

[jdog1]

I have an exam in the coming days, and we have been given a question in advance to dwell on.

There are 7 steps to the development cycle, which I have listed below. We must decide which we think is the least important step, and justify why we would leave it out. There is no wrong answer, the main criteria for your answer is how you justify it.

My opinion is Documentation. My reason for this is that if a program is designed to convention and standards, it should be usable without any written manual. Obviously I'm going to expand on this, but I'd like to hear what others more experienced than me have to say. Thanks.

Software Development Cycle

Problem Definition

Before any problem can be solved and a solution constructed, the problem solver must fully understand the nature of the problem to be solved.

Solution Specification

The programmer will decide what the program will do. Screen designs are created. Data store is designed (data dictionary). Menu tree of forms is designed. This stage will effectively outline how the final product will look and behave. This stage is extremely important, as it is much easier to change the design at this stage than later on in the process.

Algorithm Design

Here the solution specification is described in algorithmic language. Top down design can be used to refine the process adding more and more detail. What algorithmic approach is used the solution is always expressed in terms of sequence selection iteration and models.

Coding (Implementation)

This involves the translation of the algorithm into an available computer language. If the algorithm has been well designed it can be a one to one translation.

Documentation

Documentation is in two parts – internal and external. External documentation occurs throughout the design process. External documentation includes user manuals and documentation involved with the software development cycle itself. Internal documentation makes it easier for other to follow the code.

Testing

This stage is to make sure that the program is free from logic and syntax errors.

Evaluation

Questions which would need to be asked, would be, did it work? How could the program be improved?

[AutisticCuckoo]

Funny … I consider the documentation to be one of the most important parts of delivery.

For any non-trivial application, reading the source code to understand what it is doing is simply not doable. Especially if we're talking about a distributed Java/J2EE system where different parts of the app execute on different servers, perhaps even on different continents.

Class diagrams, object relationship diagrams and sequence diagrams are invaluable when you're trying to maintain existing code. It applies to code you've written yourself, but even more so to code written by someone else.

I'm currently trying to make sense of an e-payment application written by an external contractor. There is zero external documentation and very few comments in the code. I had to go through all the code and draw up sequence diagrams in order to even begin to understand what was happening. And even after that I'm still feeling homicidal at the mere thought of this application.

[Shyflower]

I would say problem definition. That's the foundation of any project and if you don't have a good foundation, sooner or later everything else will tumble down.

[jdog1]

Originally Posted by Shyflower

I would say problem definition. That's the foundation of any project and if you don't have a good foundation, sooner or later everything else will tumble down.

Actually, supposed to be the least important that we're defining and justifying.

[jdog1]

I can see that my answer was narrow minded, I didn't think of all the aspects of it.

So what do you think is the least important any why?

[AutisticCuckoo]

Out of the stages you listed, I'd say that the Evaluation step is what I would forgo if I had to skip one. Not that it's unimportant, but all the other steps are even more important (in my opinion).

(I've worked with professional software development for 17 years, if you wonder about how much experience I have to back this up.
I've had to maintain my own code as well as code I've 'inherited' from others.)

[DaveMaxwell]

Originally Posted by AutisticCuckoo

Out of the stages you listed, I'd say that the Evaluation step is what I would forgo if I had to skip one. Not that it's unimportant, but all the other steps are even more important (in my opinion).

(I've worked with professional software development for 17 years, if you wonder about how much experience I have to back this up.
I've had to maintain my own code as well as code I've 'inherited' from others.)

Edit:

OK, I've just re-read the initial post, and I'm confused. There's a big difference between which step is least important in a process, and which step can be left out of the process. If it's which is least important, then my post stands. If it's asking which step can be left out, then my answer would be "none" because all the steps listed are critical to any successful project implementation

I'd agree with the first of Tommy's comments, and I'm working on my 11th year as a "professional" (i.e. not counting my school years) software developer, from mainframe to client/server to web. I'll respectively disagree with his answer, though.

To expand on his first answer - documentation is critical. The concept of self-documenting code is all well and good, but in reality, it's not truly possible. Yes, you can code it cleanly, but invariably, you're going to have to code something really oddly and at some point, you're going to have to revisit code and be able to determine why something is done the way it is. The other thing to consider is that you may not be the next person to work on a project. While a coding convention may make sense to you, another person off the street needs to be able to understand that. Also, the other point to documentation is to allow someone coming in to get the "big picture" of how a whole system works, and how each piece of the puzzle fits in to the big picture.

I'm currently working on a project which followed the "code should be self-documenting" philosophy. The team I'm on inherited the code from the other team, and we've been struggling for 2-3 years with understanding how different pieces interact with each other, not to mention how things work by themselves.

OK, here's my take on the answer to your question. The least important step in your workflow would be....coding (implementation).

Here's my reasoning behind it.

1. Problem definition - most important step of all. Without knowing the problem, how can you determine a solution.
2. Solution specification/algorithm design - these two steps go hand in hand, and must be developed with the other in mind. Each one must try to anticipate problems and plan solutions. In terms of your list, third most important, but in reality, it goes very close to step 1.
3. Coding (implementation)If steps 1 & 2 are done thoroughly, then coding should be easy. Just follow the specifications.
4. Testing - second most important step. Testing must be thorough, both with a plan for testing how it should work, as well as testing all the possibly goofy ways that a user could attempt to fit the square peg through the round hole.
5. Documentation - see my reasons above for why this is so important.
6. Evaluation - very important because you need to know if the problem is solved, and.or if any additional problems have arisen because of the solution. Sometimes a solution tests out OK, but once it goes live, problems related to the solution creep up and need to be identified.

Hope this helps...

[jdog1]

Ok thanks. Do you happen to have a good justification for this off the top of your head? Because I'm pretty sure that's where we get the marks. By the way, I was actually hoping you'd answer so I'm pretty happy with that!

[jdog1]

That is unbelievable mate, I can't thank you enough.

I know this must be right, because when my teacher said he'd choosing coding we all said 'what the hell'.

I see now that all these steps create the code, the code doesn't create any of them.

I think I'm getting full marks for this question!

[DaveMaxwell]

OK, so the question wasn't which could be eliminated, but which was least important in the lifecycle as defined. Like I said, it makes a big difference...

Glad I could be of assistance

[Shyflower]

I misread the question as well. (Which means I would have totally flunked! My hat's off to all of you who learn programming!) Like Dave, I believe that problem definition is the MOST important step of any project. Now I understand why you questioned my other post.

Through the process of elimination, I also agree that coding is the least important. However, I also think they are so intermingled that you really can't just omit any of them.

[wwb_99]

First, I think that there are some flaws with building software in that strict a cycle. Real men do it iteratively.

Second, I do agree with the general sentiment that the most important bit is figuring out what to solve. I should also note that a valid answer to that question is "Existing systems are adequate and/or cannot feasibly be replaced given current constraints."

[DaveMaxwell]

Originally Posted by wwb_99

First, I think that there are some flaws with building software in that strict a cycle. Real men do it iteratively.

See, that's one of the biggest flaws I see in todays methodologies - the basic concept pushes people to think they have to start developing before it's time.

The concept is the same - you define the problems first, then define the specs and algorithms (if appropriate) accordingly. At that point, iteration comes into play. Now you develop a portion of the code, test it. When that is complete, you return to develop the next piece of code, then test that additional piece of functionality. The rinse and repeat.

You do not define one portion of the problem, fix it, test, then return to problem definition.

[wwb_99]

Originally Posted by DaveMaxwell

See, that's one of the biggest flaws I see in todays methodologies - the basic concept pushes people to think they have to start developing before it's time.

The concept is the same - you define the problems first, then define the specs and algorithms (if appropriate) accordingly. At that point, iteration comes into play. Now you develop a portion of the code, test it. When that is complete, you return to develop the next piece of code, then test that additional piece of functionality. The rinse and repeat.

You do not define one portion of the problem, fix it, test, then return to problem definition.

Valid points, but "problem definition" is really so tricky an issue that I find chunking a project and releasing pieces iteratively lets one refine the problem definition and tweak the further iterations to best fit things. Funnily enough, adding new software sometimes leads to new problems.

[kyberfabrikken]

Depending on the context, I would say that the implementation could well be the least important one. Presuming everything else is done right, it's a trivial task. In many situations, were you need to prioritise like that, you do it because you have a deadline. It may be better to meet the deadline with a proof-of-concept (prototype) than an actual working application.

[AutisticCuckoo]

Originally Posted by kyberfabrikken

Depending on the context, I would say that the implementation could well be the least important one.

If you mean as in 'the step you shouldn't have to spend too much time on', I agree. But the question was:

Originally Posted by jdog1

We must decide which we think is the least important step, and justify why we would leave it out.

(Emphasis mine.)
Leaving out implementation makes the other steps rather pointless, wouldn't you say? Testing and evaluation would be rather difficult.

My response above was based on the assumption that the question was which step to leave out if you had to drop one. Defining the problem (requirements), analysis and design, implementation, testing and documentation are all steps that must be done. Evaluation is something you definitely should do, but it's the step I'd skip if I had to cut one step from the list.

[DaveMaxwell]

Originally Posted by AutisticCuckoo

My response above was based on the assumption that the question was which step to leave out if you had to drop one. Defining the problem (requirements), analysis and design, implementation, testing and documentation are all steps that must be done. Evaluation is something you definitely should do, but it's the step I'd skip if I had to cut one step from the list.

Yup, that's why I questioned the basic premise - it seems incomplete. Personally, I can't justify a reason for leaving out any one of those steps. They're all critical to a successful project.

[kyberfabrikken]

Originally Posted by AutisticCuckoo

(Emphasis mine.)
Leaving out implementation makes the other steps rather pointless, wouldn't you say? Testing and evaluation would be rather difficult.

That would depend on how to interpret the question. If leaving the implementation out means that you can't write even some pseudo code or simple prototypes, then you're probably right. My assumption was that "leaving the implementation out" would still mean that you could write a prototype -- only you couldn't write production quality code.