Why do software projects fail so often?

Why Do Software Projects Fail?

“What are the chances that this project will succeed…?”

For most companies and entrepreneurs starting on a new software project, this is one of the first questions that are considered. Unfortunately, the question is a very relevant one. Studies conducted by major research groups show that 50% of software projects fail today.

Why do software projects fail? Are there preventive measures to avoid software project failure?

A recent research project at 'The Standish Group' has identified reasons for software project failure. Lets have a look at the results of the research project.

For purposes of the study, projects were classified into three resolution types – Resolution Type 1 or project success, Resolution Type 2 or project challenged and Resolution Type 3 or project impaired.

Resolution Type 1 or project success:

The software project is completed on-time and on-budget, with all features and functions as initially specified.

Among the Project Success Factors, it was noted that ' Clear Statement of Requirements' was ranked third in importance for the success of a project, after User Involvement and Executive management Support.

Resolution Type 2 or project challenged:

The software project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.

'Incomplete Requirements and Specifications' was cited as the second main reason for exceeding the budget and time

Resolution Type 3 or project impaired:

The software project is canceled at some point during the development cycle. Here again, Incomplete Requirements was the main reason cited for the failure of the software project.

Overall, the success rate was only 16.2%. Challenged projects accounted for 52.7%, and impaired (canceled) for 31.1%.

The table below lists the criteria for software project success in order of importance.

SUCCESS CRITERIA	POINTS
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

The chart clearly shows that 3 major factors greatly influence the success of a project - User Involvement, Executive Management Support and Clear Statement of Requirements.
Out of these, “Clear Statement of Requirements” scores 15 points and is one among the top 3 reasons for the success or failure of a Software Project. It is clear therefore that Requirement Definition is a crucial step in Software Development. Read about our Requirement Analysis process here.

Requirements Evolution

Requirements & Analysis is one of the most important and often most neglected activities of the software development life cycle. A good requirements model fosters communication between the business and IT by enabling them to share a common vision of the system’s solution prior to implementation. This will ensure that the system meets the business needs, can be delivered on time, and have the level of quality and flexibility to easily accommodate future business needs.

Requirement Capture and Analysis - The Difference

Requirements

Analysis

To determine what needs to be built
To understand users and their potential usage of the system.
To determine what users want to have built.

To describe what the customer requires
To understand what will be built
To understand why it should be built
To determine how much it is likely to cost. (estimation)
To determine the order in which should be built (prioritization)
To understand the system itself and explore the details of the problem domain
To understand how it will be built
To identify and translate business goals and needs into system features, and use them to derive both functional and nonfunctional (technical) system requirements
To ensure that it represents the middle ground between requirements and design
To define a set of requirements that can be validated
To establish a basis for the creation of a software design

How can we ensure that we have specified a system that properly meets the customer’s needs and satisfies the customer’s expectations?

There is no foolproof answer to this difficult question, but a solid requirements engineering process is the best solution we currently have.

Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing needs, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification and managing requirements as they are transformed into an operational system. The requirements engineering process can be described in five distinct steps-

Requirements Elicitation
Requirements Analysis and negotiation
Requirements Specification
System modeling
Requirements Validation
Requirements Management

What is test-driven development?

Test-Driven Development (TDD) is a computer programming technique that involves writing test cases first and then implementing the code necessary to pass the tests. The goal of test-driven development is to achieve rapid feedback and implements the "illustrate the main line" approach to constructing a program. This technique is heavily emphasized in Extreme Programming.

Practitioners emphasize that test-driven development is primarily a method of designing software, not just a method of testing. The method is also used for removal of software defects.

Requirements

For test-driven development to work, the system must be flexible enough to allow for automated testing of code, using test cases that return a simple true or false evaluation of correctness. These properties allow for rapid feedback of correctness and design. Unit testing frameworks such as JUnit, NUnit or CPPUnit provide a mechanism for managing and running sets of automated test cases.

[edit]

Test-Driven Development Cycle

[edit]

1. Write the test

It begins with writing a test. In order to write a test, the developer must understand the specification and the requirements clearly. This is accomplished through use cases and user stories. The design document covers all the test scenarios and exception conditions.

[edit]

2. Write the code

The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through its interfaces. This is the design driven part of test-driven development. As part of test calibration, your code should fail the test meaningfully the first time around.

[edit]

3. Run the automated tests

The next step is to run the automated test cases and observe if they pass or fail. If they pass, the programmer can be more confident that the code meets the test cases as written. If there are failures, the code did not meet the test cases..

[edit]

4. Refactor

The final step is the refactoring step and any code clean-up necessary will occur here. The test cases are then re-run and observed.

[edit]

5. Repeat

The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.

[edit]

Differing styles

There are various ways one can go about using test-driven development and the most common one is based on the principles of "Keep It Simple, Stupid" (KISS) and "You Ain't Gonna Need It" (YAGNI). This style focuses on writing only the code necessary to pass the tests. Design and property principles are cast aside in the name of simplicity and speed. Therefore, any rule can be violated as long as the tests will pass. This can be unsettling for many at first but it will allow the programmer to focus only on what is important. However, the programmer must pay a bigger fee in the refactoring step of the cycle since the code must be cleaned up to a reasonable level at this point before the cycle can restart.

Another variation of test-driven development requires the programmer to first fail the test cases. The idea is to ensure that the testcase really works and can catch an error. Once this is shown, the normal cycle will commence. This is one of the more popular variations and has been coined the "Test-Driven Development Mantra", known as red/green/refactor where red means fail and green is pass.

A third variation combines the first and second steps listed above. In this manner, the code is written inline and debugged as a part of the test. At this stage, the test will be very large, but will complete correctly and the test logic will contain the eventual program code. Then the actual program code is moved to the code tree using a "extract method" refactoring with a destination in the actual code tree. In this step, the test becomes substantially smaller, and the pre-tested method is created in the code tree. If this style is used with a code coverage tool, the final step is to ensure that the tests sufficiently exercise the code to achieve the code coverage desired by engineering management.

[edit]

Benefits

Despite the initial requirements, test-driven development can provide great value to building software better and faster. It offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality will be used by clients (in this case, the test cases). Therefore, the programmer is only concerned with the interface and not the implementation. This benefit is complementary to Design by Contract as approaches it through test cases rather than mathematical assertions.

The power test-driven development offers is the ability to take small steps when required. It allows a programmer to focus on the task at hand and often the first goal is to make the test pass. Exceptional cases and error handling are not considered initially. These extraneous circumstances are implemented after the main functionality has been achieved. Another advantage is that test-driven development, when used properly, ensures that all written code is covered by a test. This can give the programmer a greater level of trust in the code.

[edit]

Limitations

Test-driven development cannot work in an environment where automated testing is not feasible. The technique is immature and faces a variety of problems in the following areas:

Graphical user interfaces (GUIs)—although there are proposed partial solutions
Distributed objects (although mock objects can help)
Database schema
Compilers and Interpreters from BNF to production quality implementation
Some artificial intelligence and pattern recognition algorithms
Some genetic algorithms

It is also important to note that test-driven development only proves correctness of design and functionality according to the test cases written. An incorrect testcase that does not meet the specifications will produce incorrect code. Therefore, the emphasis on correctness and design has shifted to writing test cases since they are the drivers. As a result, test-driven development is only as good as the tests are.

Source : http://en.wikipedia.org/wiki/Test-driven_development

Stuff that lets agile software developers show off what they believe in

Those are from wikipedia

You Ain't Gonna Need It

From Wikipedia, the free encyclopedia

(Redirected from YAGNI)

Jump to: navigation, search

In software engineering, YAGNI, short for 'You Ain't Gonna Need It', is a reminder for programmers that one should never add functionality until it is necessary. The temptation to write code that is not necessary at the moment, but is perceived to be necessary in the future, has some overlooked disadvantages:

Delays what the programmer was originally working on.
There is a chance that the requirements for the software will change and the functionality will become either different or unneeded. By applying the YAGNI principle, the programmer has not wasted time in adding the redundant functionality and no longer has to waste additional time debugging the code. The code is also less cluttered as a result.

Refactoring

From Wikipedia, the free encyclopedia

Jump to: navigation, search

For refactoring Wikipedia content, please see Refactoring other text (below)

Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly keeping its meaning or behavior.

Refactoring code

In software engineering, the term refactoring means modifying source code without changing its external behavior, and is sometimes informally referred to as "cleaning it up". In extreme programming and other agile methodologies refactoring is an integral part of the software development cycle: developers alternate between adding new tests and functionality and refactoring the code to improve its internal consistency and clarity. Automated unit testing ensures that refactoring does not make the code stop working.

Refactoring does not fix bugs or add new functionality. Rather it is designed to improve the understandability of the code or change its structure and design, and remove dead code, to make it easier for human maintenance in the future. In particular, adding new behavior to a program might be difficult with the program's given structure, so a developer might refactor it first to make it easy, and then add the new behavior.

An example of a trivial refactoring is to change a variable name into something more meaningful, such as from a single letter 'i' to 'interestRate'. A more complex refactoring is to turn the code within an if block into a subroutine. An even more complex refactoring is to replace an if conditional with polymorphism. While "cleaning up" code has happened for decades, the key insight in refactoring is to intentionally "clean up" code separately from adding new functionality, using a known catalogue of common useful refactoring methods, and then separately testing the code (knowing that any behavioral changes indicate a bug). The new aspect is explicitly wanting to improve an existing design without altering its intent or behavior.

The term is by analogy with the factorization of numbers and polynomials. For example, x² − 1 can be factored as (x + 1)(x − 1), revealing an internal structure that was previously not visible (such as the two roots at −1 and +1). Similarly, in software refactoring, the change in visible structure can often reveal the "hidden" internal structure of the original code.

Refactoring is done as a separate step, to simplify testing. At the end of the refactoring, any change in behavior is clearly a bug and can be fixed separately from the problem of debugging the new behavior.

Martin Fowler's book Refactoring is the classic reference. Although refactoring code has been done informally for years, William Opdyke's 1993 PhD dissertation [1] is the first known paper to specifically examine refactoring. All of these resources provide a catalog of common methods for refactoring; a refactoring method has a description of how to apply the method and indicators for when you should (or should not) apply the method.

Refactoring is thought by many to be an important concept. It has been named as one of the most important software innovations by author and commentator David A. Wheeler.

Software quality: What makes a program code good?

1. Readability - If the program codes are easy to read / understand
2. Appropriate comment should be included in the program code
3. Documentation - Stated how those object models are transformed into the program code

Software Design Paterns: How much do you understand?

I think the design patterns that I really understand are:
adapter, observer

Other design patterns are too far away from me until I really need to develop a software system which could be benefited from applying the patterns.

From my understanding, design patterns are some sort of template , or a methodologies, that software developer can follow in order to make the software development easier.

Software Engineering Cert. Programs

From the CSDP program we can see that there are three areas which are not covered in our textbook.

1. Professionalism and Engineering Economics
2. Software Maintenance
3. Software Quality

Hope that I can find out more about this topic later when I have time.

UML Tools

I have try Poseidon for UML Community Edition, Omondo EclipseUML Free Edition in our MT365 Lab session and Visual Paradigm for UML Community Edition at home. Among these three UML tools I will choose VP as my first choice and I will share my findings below.

I evaluate those three UML tools in two aspects.
First, ease of installation.
Poseidon is the most easiest to install. No activation key is needed. VP is a little bit complicated since the Community Edition needs an activation key. EclipseUML is the most complicated one to install within these three UML tools since it need to install a plug-in separately.
Second, ease of use.

I evaluate the ease of use of these three UML tools by doing the lab exercise. VP is my favorite in this aspect since the tools provided in the application is very straight forward. Several linkage nodes on each item are very well organized. I can complete the lab exercise very quick by using VP. Followed by Poseidon, the user interface is also very easy to understand but it is a little bit trouble to model the aggregation and multiplicity. It provide detailed setting when doing making the diagrams. EclipseUML is the most difficult to use UML tools for the first-time-user like me since I spent almost double of time to find out how to draw a simple use case diagram.
Finally, I will choose Visual Paradigm as my favorite UML tools among these three choices since it is easy to use and can create a quite good looking diagram.

The Java Tutorial

Good UML book

UML Distilled 3rd. ed.

My opinions on Software Engineering Skills

After two weeks of study on Software Engineering, the following is my understanding on what basic skills do software engineer need.

We need to know what activities involved in the software engineering development process before we point out what basic skills do software engineers need.

By starting a project, requirement elicitation is the first stage that a software engineer has to face. In order get the job well done, this person needs:

1. Good communication/presentation skill – He need to know the problem of the current system of the client. After analysis, he needs to present a series of use case, use case diagrams and system model to illustrate his findings and application domain to the client. Also, he needs to present his idea to his colleagues.

2. Open mind and efficient learner – The project may involve knowledge that the software engineer had never learn before so that he may need to get the idea of the client’s routine job.

After requirement elicitation, the person in charge of the project needs to analyse the information that he acquired in order to produce a system model. In order to do so, this person needs:

3. Good analytical skill – He need to transform the information acquired into a easy-to-read model in order to present to the client.

When the system model is accepted by the client, it is necessary to define the design goals of the project and the solution domain as well. In this stage he needs:

4. Familiar with software development tools – When allocating resources to the project, he needs to estimate how much recourses are required. This requires certain level of skill on software development tools involved.

During the implementation stage of software engineering, the project leader needs:

5. Certain knowledge of programming language – Since this would help him to communicate better with those programmer and able to set a reasonable milestone for them.

Overall, the software engineer need:
6. Background knowledge of legal document – Since environment is changing, the project leader need to compose legal document, like contract or agreements, in order to protect any parties in the project.

7. Good at time management – Every project has a deadline to meet. The ultimate goal of a software engineer is to submit a high quality system in limited time and resource.

I am looking forward to acquiring knowledge as much as possible from Steven but it is more realistic to set handling UML and Patterns as the first step.

what is web 2.0

Web2.0

Study blog

Monday, April 17, 2006