Summary
What specifically are the phases of software development? I was taught there were about 4 or 5, but I believe I have identified a few more.
Advertisement
I was taught (back in '94 by my software engineering professor) that the stages of software development were something like (my memory is hazy, so I am not probably giving her full justice):
gather requirements
design
implementation
debugging
testing
I believe that it is important to consider a more fine-grained and less linear view of the stages of software development. I consider the following to be important interleaved phases for the development of most non-trivial commercial software:
scheduling - Self explanatory.
research - Learning more about the problems the software attempts to solve, and what the competing software does.
technology selection - Choosing what tools, languages, and technologies to use to build and devleop the software.
reuse - Identifying code libraries and tools internally and externally that can be leveraged
prototyping - An important step which is often overlooked (often-times the first version is really a prototype).
code documentation
product documentation
refactoring - Change in the code to changes in implementation design.
extending - This refers to when more features are added during development, after prototyping, or after a release
revising - Related to refactoring, this refers to when the product requirement are significantly changed in some-way
internationalization - It is is usually the case the software will be released in different locales with different langauges and cultural conventions.
optimizing - It is rare that software doesn't have some areas where better performance could significantly improve the product.
static analysis - Static analysis tools are an important part of detecting defects
reviewing code - Code reviews are an important supplement to testing
releasing - Getting the internal versions to various teams, and external versions to customers in a smooth and timely manner
recycling code - The code in a successful project will almost invariable be reused in some other project.
porting - Porting software to new operating systems and platforms is almost always inevitable in a successful product
support - Customer support is easily overlooked, but when taken into consideration will affect design decisions, and profitability.
By being aware of, and giving proper consideration to, these stages of software development I believe software projects increase their chances of success.
So what do you think, are any of these superflous or am I missing some?
I would say “educate the decision makers and the development teams about the nature of software development”. That is the first and only step needed!
This is the shortest possible tutorial I could come up with to distribute to anyone who never “participated” in software development contributing to the effort, if it helps! And if they are decision makers – it is more important to test and grade them after!
I also recommend some simple reading if it is not asking too much!
Why Big Software Projects Fail: The 12 key questions by Watts S. Humphrey, The software engineering institute , Carnegie Mellon University (published in Quality Assurance Institute, October 2005). The nature of software development and many interesting inferences are discussed in the form of questions and answers in this paper.
Software industry professionals (anyone who has anything to do with the business of software) need to be aware of the System Development Life cycle methodologies adopted by Software Engineering divisions in organizations. The goal of a Software Engineering division is to ensure the needed processes at least at a high level for delivering quality products / applications to stake holders.
At a high level, there are really 4 main stages of software system development. This is the way we were taught in higher education by people who were not experienced with large scale software development.
I repeat those stages as learnt in schools. They are planning, analysis, development, implementation. The answers to WHY (planning - why is the software system built?) WHO will use the system, WHAT will the system do? And WHERE and WHEN it will be used ? (analysis constitutes these) HOW the system operates is decided in the design phase. Implementation can be seen how the software system is acquired (built or purchased).
There are several development approaches taken to ensure the best suitable approaches for developing the software according to the context. And the initial step should be to ensure that the best suitable approaches are followed for the project under consideration. Decision makers need to be aware of this fundamental point.
It is a recognized fact among the “experienced software professionals” that any considerable software development effort is “evolutionary” and complex. Such an effort cannot afford to “freeze ” / “stop thinking ” about several aspects of development. - at any of the 5 main stages.
However, during an “iteration”, “adding requirements” can be avoided. This will allow software development proceed until the next iteration. This will let the development teams maintain their sanity and ensure stable environments to a certain extent.
What could be the end of the software evolution? The end could be due to the following reasons. Software entered “maintenance” stage (no longer actively developed) OR it is decided that there be no development OR the code is in a “decay” stage – it is not feasible to develop with that code anymore.
The life cycle ends with these phasing out stages. So the initial development which we call Software Development phase among the 4 main phases is really part of an “iteration” of the software evolution. It takes time and effort for “software” to mature.
The knowledge that one can look for is popularly called SWEBOK (Software Engineering Body of knowledge). This knowledge is compiled through the efforts of experienced Software professionals and educators for about 25 years.
The question is – is the knowledge being applied in the industry with care and attention to the issues of software evolution? Do people responsible for complex projects care to understand the nature of software evolution and development?
Far too often people launch off on gathering requirements prior to defining the problem that they are trying to solve. Somebody important enough just says "I think we should have an application that does X" and people run off to build or buy something that does an elaborated version of X (that elaboration is what passes for requirements development) without ever considering whether having an application that does X serves any useful purpose.
> - big trouble; > - searching guilties; > - punishment of innocents;
that's blame assignment. The blame goes downwards, always :(
Actually a good postmortem is always worthwhile. Not only does it achieve some kind of closure, but organisations do need to learn from their past mistakes. If everyone gets blamed or management pretends nothing went wrong, you are doomed to repeat the same disaster.
In any large project, I would say that if you aren't debugging, testing, and refactoring code from the earliest stages of implementation, you're crazy. I truly believe it impossible to do software engineering in distinct phases as described, unless you are talking about very small chunks of software (e.g. one or two functions). Maybe you agree with this, since you suggest starting with a prototype, and refactoring and revising it.
Also, I notice that the more experienced programmers become, the less value static analysis tools have. Through experience you learn to fear the same constructs as the static analyzer.
> I truly believe it > impossible to do software engineering in distinct > phases as described, unless you are talking about very > small chunks of software (e.g. one or two functions).
Yes I completely agree. I should not have said distinct. I edited the line to now read:
"I consider the following to be important interleaved phases for the development of most non-trivial commercial software:"
The only disagreement I have, and it's a small one (mostly a matter of vocabulary), is localizing as a distinct step.
I would consider internationalization as the step needed instead of localization. Using an architecture that is internationalized you can choose to implement specific locales as those features are prioritized.
> The only disagreement I have, and it's a small one (mostly > a matter of vocabulary), is localizing as a distinct > step. > > I would consider internationalization as the step needed > instead of localization. Using an architecture that is > internationalized you can choose to implement specific > locales as those features are prioritized.
I am solely responsible for an important little data management application used in academia. So for single person work - a lot of coordination noise just goes away. My process is:
1) Empathize with your user. Understand his problem. 2) Prototype a solution. 3) If prototype capability < useful, go to 1. 4) Deploy solution 5) Support the solution - be responsive. 6) Deploy fixes. 7) As time permits - expand scope - goto 1.
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?
I'm talking about business rules so complicated, that even when a document is available, a person needs a little mental warm up to get into the proper frame of mind to discuss them.
Is such complexity a necessity of modern life, or are we just punishing ourselves masochistically for no good reason?
Is change something that only people at the bottom of the organizational hierarchy do? Should the top of the organization be required to change with the times and conditions, is this solely the job of the so-called "worker bee"?
Flat View: This topic has 23 replies
on 2 pages
[
12
|
»
]
Previous Topic
