The Java Project Dilemma
This chapter is from the book
This chapter is from the book
This chapter is from the book
In This Chapter
I have run across more projects after the fact that missed their initial goals than met them. One reason is that most of the project teams had no clue about what a development process was or how to customize one for a project's unique characteristics. In addition, most of the projects had little in the way of analysis and design artifacts to show how they got where they were. The whole endeavor lacked the ability to be tracked; that is, it lacked traceability.
This chapter lays the groundwork for the need of a software process. I will present two processes in this book: one that is commercially available from Rational Software called the Unified Process, the other based on my own experiences, which I call the Synergy Process. For reasons to be covered later, the Synergy Process will be presented in Appendix B. The primary process that will guide this book's efforts is the Unified Process, which is presented in greater depth in Appendix A.
This process, along with the Unified Modeling Language (UML), can ensure that your next Java projects have all of the muscle they need to succeed. More importantly, these projects will stand the test of time. They will be able to flex and bend with shifts in both the underlying businesses they support and the technology framework upon which they were built. They won't be declared legacy applications before they reach production status.
GOALS
To review the dilemma that projects face.
To explore the nature of an iterative, incremental, risk-based software development process.
To become acquainted with the software process model used in this book, called the Unified Process.
To examine how the project team can market the use of a process to project sponsors.
To review the Unified Modeling Language and its artifacts, and how it serves as the primary modeling tool for a project's process.
The Sad Truth
The premise of my first book, Developing Applications with Visual Basic and UML, was that most software projects undertaken today don't come close to meeting their original goals or their estimated completion dates. My reasoning was that most project teams have a somewhat cavalier attitude toward project planning and software process. In addition, most projects have little in the way of analysis and design artifacts to show how they got where they are. That is, projects traditionally lack traceability. This holds true for applications built in any language—Java included.
My professional career with computers began after college in 1979, when I began working on large IBM mainframe applications using technologies such as IMS and later DB2, what many people today would call legacy applications. However, I prefer the terms heritage or senior to legacy.
Not only did I get to work with some really great tools and super sharp people, but I also learned the value of planning a project and establishing a clear architecture and design of the target application. I saw this approach pay back in a big way by establishing a clear line of communication for the project team. But more importantly, it set in place the stepping-stones for completing a successful project.
In 1990 I worked on a first-generation client/server application using SmallTalk on the OS/2 platform. This was the start of a new career path for me, and I was shocked by the "process" used to build "production" applications in the client/server environment. The planning was sketchy, as was the delivery of analysis and design artifacts (something that showed why we built what we built).
This pattern of "shooting from the hip" software development continued with my use of PowerBuilder, Visual Basic, and later Java. The applications delivered with these products worked, but they were fragile. Today many applications wear the client/server or distributed moniker when they are just as much a legacy as their mainframe counterparts, if not more so. Even worse, many of these become legacy applications a month or two after they go into production. The fault isn't with the tool or the language, but with the lack of a sound process model and methodology to ensure that what is built is what the users actually want and that what is designed doesn't fall apart the first time it is changed.
Most organizations today ship their staff off to a one-week Java class and expect miracles on the first application. Take this message to heart: The fact that you know Java doesn't mean you will necessarily build sound object-oriented applications. If you don't have a sound process in place and a very firm footing in sound object-oriented design concepts, your application will become a Neanderthal waiting in line for extinction.
Slowly I began to apply my own opinions about process and methodology to the applications built in these environments. This worked quite well. The applications were more resilient and accepted change more easily, and the users typically had smiles on their faces.
This book combines all of my experience building distributed applications with UML, which I feel is the best artifact repository for documenting the analysis and design of an application today. I would also like to think that my approach to this topic is exciting because I use a real example throughout the book utilizing various Java technologies and tools to demonstrate how you might approach solving some of your own problems.