Skip to content

Software Development lifecycle understand the problems, myths and challanges

September 2, 2008
tags:

Challenges and Problems:

  • A problem cannot be definitively stated. Whenever we attempt to bound a project using something like a specification, the requirements change, often in unpredictable ways.
  • There is no rule or guideline to determine when a problem is solved. In the physical world, we usually have a reasonable stopping point for generating solutions. For example, a mechanical engineering problem associated with determining the flexure (to the nearest tenth of an inch) at the midpoint of a bridge under stated dynamic or static conditions can be computed. That answer can be independently verified, and the problem is solved. But in software development, there is no stopping point other than to run out of money or time.
  • problems have only good or bad solutions, not right or wrong ones. Getting back to our mechanical engineering example, there is a range of answers that are correct, and anything outside that range is wrong. As compared with software, that range of correct answers is very narrow. But in software, there can be many solutions that meet the specification that by that standard are good. Presumably, those that do not meet the specification are bad.
  • A problem cannot be definitively tested. This seems reasonable. If there are no right or wrong answers in the problem space, there shouldn’t be any way to accept or reject the solution in an analytic or a scientific way. One exception in software is whether the solution meets the specification. However, even specification issues tend to be arguable and not clearly right or wrong.
  • Solutions to problems are too significant to be experimented with. Although the defense establishment occasionally has aircraft companies create prototypes for a “fly off” competition before a contract is awarded, building multiple software systems and selecting the best from among them is usually prohibitively expensive in both monetary and temporal terms.
  • Neither the number of possible solutions nor the means of distinguishing among them is limited. Software development is at least this wide open.
  • Each problem is unique. If you don’t think so, try to determine how many order entry and inventory control systems have been built worldwide.
  • problems are often symptoms of higher-level problems. If, in an embedded real-time system, we are having serious timing issues (that is, the system is too slow), it might mean that we are using too slow a processor. The processor might have been picked to keep the cost down. Hence, the timing problem could actually have been a symptom of a lack of funding for the effort.

Myths

Myth #1: Software is easier to change than hardware.
Myth #2: We’re in maintenance mode, and it’s rare that we write something new, so we don’t need to measure what we’re doing, gather statistics, or define processes.
Myth #3: We don’t need to document the code by including comments, because any proficient programmer can tell what the code does by looking at it.
Myth #4: Quality can be tested into the system—what we should do is get it coded as rapidly as possible and then test it as thoroughly as possible.
Myth #5: Why bother performing analysis and design? After all, the code, not these preliminary documents, results in a marketable product.
Myth #6: We don’t need a quality assurance group—we hire smart people, and they don’t make mistakes.
Myth #7: Increasing their compensation gets software professionals to perform at a higher level.
Myth #8: The way to encourage people to get into management is to give them special perquisites.
Myth #9: Software processes are great, but when the project is behind schedule, we don’t have time for such things.
Myth #10: The marketplace requires that we get to market as quickly as possible. Using some sort of prescribed method or process is just going to slow things down.
Myth #11: There is so much software out there that either is included with various development environments or can be licensed inexpensively—we can employ it and write very little new code.
Myth #12: If we institute processes into this organization, people will either leave the company or become unproductive.

Observations

  • Much of what we learn from the physical world and our everyday lives does not apply to managing software projects.

  • Quality affects more than just the product; it also affects the performance of the people producing the product.

  • If we aren’t careful, small slides in the schedule can build to tsunami proportions that cannot be overcome, with or without death march mode.

I’ll extend the preceding list in the remainder of this book to incorporate additional guidelines worth remembering, including these:

  • People are the most valuable resource a project has.

  • Trust and mutual respect between the project manager and those directly involved in developing the product improve team morale and our odds of success.

  • Within reason, running more tasks in parallel is far more effective in shortening development flow time than adding people or cutting features.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: