As Thomas Pender states in his book, UML Weekend Crash Course, software development is not a formal discipline. What this means is that application programming, unlike, for example, bridge building, does not have formal standardized processes.
Consider this comparison: Bridge builders (as well as other engineering and construction professions) are renowned for designing and building highly reliable structures on time and on budget. Software developers are notorious for building highly unreliable systems which are delivered late, if ever, and over budget.
When was the last time you drove over a bridge which collapsed? How about the last time you had a problem with software?
So the question then becomes why do so many software projects fail? Well, there are many facets to this question. However, I personally believe that most of the time the failures result from a failure to manage and control common problems in software development. These problems include, but are not limited to:
Problems which are managerial in nature:
- Project Requirements are Poorly Defined
- Lack of User Feedback
Problems which are not necessarily managerial in nature:
From the perspective of a software developer this list of problems can seem quite daunting, to say the least. But take heart! Bridge building was not always a science; it has matured over 3000 years. Bridges have not always been built on time or on budget. Sometimes they fell down! I interpret this to mean that software development will continue to trend towards more reliable systems developed increasingly on time and on budget.
For many years now people (who are much smarter than me) have been working to formalize the software development field. The results of their work are concepts such as UML, various Development Methodologies, Design Patterns and much more. As developers, we are beginning to be responsible for not only keeping current with the most recent technologies, but also the most recent techniques. These techniques can help manage the problems listed above and help us to deliver reliable software on time and on budget.
Development methodologies are a means and technique applied to the entire process of software development, from inception, though requirements gathering, programming, project completion and everything in between. Development methodologies do not necessarily directly impact the code created. They do, however, define the process, vocabulary, rules and guidelines for creating software.
In a nutshell, development methodologies are a science of the process of creating software applications. There are literally hundreds of formal development methodologies. This might be because not all methodologies are well suited for types of software or all development teams.
A methodology which is iterative or incremental in nature will help in defining project requirements and obtaining user feedback. It will also help integrate change into the development process and foster realistic expectations.
Object Oriented Programming
A greatly simplified definition of Object Oriented Programming (OOP) is a programming technique in which code is grouped into objects which make up a software application. Objects abstract and provide ways of manipulating data. I will not get into the details of Object Oriented Programming. There are many fantastic resources on the web dedicated to Object Oriented Programming.
Object Oriented Programming helps you to create more manageable software applications by helping you to control the interrelated problems of complexity and change. Because program logic is encapsulated into logical objects, Object Oriented Programming helps control the complexity of software code by helping to prevent redundant and spaghetti code. By controlling the complexity of software changes to the software become easier. Object Oriented Programming also helps to reduce the cost of maintenance and helps in the creation of reusable code.
Uniform Modeling Language
Unified Modeling Language (UML) is a standard way of modeling and describing object oriented software systems. UML provides a visual vocabulary made up of icons used to describe object oriented software systems. UML does not define how the diagrams are to be used and allows architects to apply their own styles.
Because UML visually describes complex systems, it is a terrific tool to use so that all stake holders in an application can understand it before any code is written. UML helps expose potential problems, limitations, misunderstandings, and more in a complex system before the system exists.
UML is compromised of a number of diagrams, each with their specific purposes. Notable among these is the Use Case diagram which visually describes interactions between the system and users. This diagram illustrates to both clients and developers how a system will be used. This information is useful for validating requirements, helping clients provide feedback, and facilitates change when it’s most easily integrated.
UML provides a comprehensive way to understand complex systems. Because such an understanding is available before the system is created, it makes it easier to comprehend what will be required to build the system. Therefore, UML helps to foster realistic expectations of delivery timeline, system features and more.
Design Patterns can be defined as time tested solutions to recurring software design problems. The concept of Design Patterns comes from the construction and engineering fields. Engineers came to the realization that for a particular class of problem there was frequently an eloquent solution could be applied time and time again. The same principal holds true for software development. By applying Design Patterns to software development problems you can help improve understanding and comprehension of a complex system across the development team. Design Patterns also help to create more reusable and flexible code.
As you can see, there are many techniques which can be applied to the software development process to help insure project success. Over the next few weeks and months I hope to touch on more of these issues. In particular, I plan on a high level review of Development Methodologies, requirements gathering, and lots of details on the various UML diagrams. If there is anything in particular you would like to see covered please leave a comment.