Abstract
Software projects can be implemented with many various architectures and methodologies. In this document, we will focus on two of the main design approaches, the traditional software project life-cycle, and several common methods for project management throughout the implementation phase.
Table of Contents
- Introduction
- Software Projects, Modeling Analysis
- Software Projects, Traditional Software Implementation Review
- Software Projects, Weighing Delivery Factors
Introduction
In the beginning phase of the software life-cycle, some general design options, presented here, are objects versus services. We will briefly discuss these options and evaluate their relevance according to the final product. The overall project life-cycle, and its management, will be reviewed in terms of the traditional model and its relevance in today’s software projects. Finally, we will review factors that determine whether a project is successful and review those that may have the greatest impact on this determination. I have had personal many career experiences with each topic that I will present in this document.
Software Projects, Modeling Analysis
In order to meet the business demands of software, an initial question of design modeling must be considered. There are many different modeling tools available, and each with variations of underlying objects. This also suggests some decisions regarding the business model, in terms of its applicable objects.
Some business software products are better applied as groups of services. Even within these services, business objects must be correctly abstracted for their best fit and adaptability into the business processes. [1] With this, I am suggesting that service oriented architecture and business object modeling coexist within the same project, and the resulting design framework should be a combination of the both services (or processes) and objects; each to the degree that the objects are correctly applied to the business model.
Software Projects, Traditional Software Implementation Review
To elaborate on the traditional software implementation, the life-cycle can be summed into several phases. For our purposes here, we will include analysis, development, and implementation. The foundation of the traditional model is one successfully-completed-step building upon another. This of course, is a very appropriate model under certain controlled circumstances. However, when the business model is changing at a faster pace than the software can be created, project teams must work on several future iterations in unison, and complete iterations on time, without any design flaws. In a "perfectly controlled" environment, this might be optimal, but realistically, design flaws would either have to be incorporated into the re-design planning, or accepted as inevitable loss, since the business model is changing faster than a perfectly adaptable model can be created.
Recently, a majority of professionals view the "shorter iteration" and "smaller scope" projects to be a manageable way to minimize the cost-to-loss factor of software creation. [2] Unfortunately, not all executives are on the front lines to see this happening on a daily basis. Most executives in this situation have been completely unaware of, and therefore initially reject, the first announcements of the compounding waste that is accruing, due to "scope creep" and “over-weight” software projects.
I suggest here, that if the “forward-looking” analysis was utilized more, the loss factor could be severely reduced. Secondly, if the correct “rapid-development” tools are pre-approved and utilized to their full effectiveness, the time-to-delivery would also be significantly reduced. The balance of the game here, is that the release-candidate software product may not be the "exact" implementation that was originally described during the analysis phase, but as it turns out, this is nearly always the case anyhow.
To remedy this scenario, a second iteration and adjustment update project, could be put into immediate action –with the same personnel, the same or upgraded development tools, and finely tuned environments. In other words, adapt and improvise. With each subsequent release, the business model is more accurately defined, until the end result is software that drives the business model itself. One critical key to success, for this example, is that all of the moving parts (individual software services) must be easily replaceable. This is one of the most fundamental ideologies of object oriented design(OO) in service oriented architecture (SOA), and yet this concept eludes most executives and business analysts during the design phase.
The purpose of this section is to elaborate on how the traditional model of lengthy and bulky software projects actually guarantee increased costs / losses into the final product - and this last point is the defining reason. If the tools cannot produce, and personnel do not understand, the concept of a well-defined "segmented replaceable design", and the software's object dependencies are too strict, then all future iterative releases are subsequently fated to be excessive in time and cost.
Software Projects, Weighing Delivery Factors
From the seemingly infinite number of possible combinations, we can not anticipate how a given configuration will behave within a particular organizational context. As a result, organizations implementing advanced software packages need an effective model that guides the process of discovering and implementing an effective initial software configuration. With this, I include an excerpt from F.P. Brooks, since he states so eloquently and somewhat humorously:
- One "wrong ", consistent design is almost always better than a compromise between two excellent designs where the final product does not hang together.
- With no design, each group will go off with its own design and you will produce a balkanized product.
- In either case, without a consistent design, performance improvements and new functionality cannot be easily made, except by being late, over budget, and taking several revisions.
- Many years ago I participated in a programming project that ignored this principal. Design did not follow any single conceptual plan; rather it followed the corporate structure. The application groups designed the applications, the graphics groups designed the graphics, the database group the database, and the user interface groups the user interface. Nobody really addressed putting the pieces together. The program never worked well, it was difficult to debug, bug fixes and performance improvements were difficult to make. Today with the growth of middle-ware components and multi-tier architectures this issue has become very critical. [3]
Conclusion
In this document, we have considered a range of ideals that contribute to the creation of business software. We touched on the concept of business object modeling and the important role it plays on the underlying product. We discussed the traditional software implementation model and it’s limiting factors to investment returns. We also reviewed several factors which contribute to the success or failure of software projects. Maybe if these categorical research details are posted, printed, and effectively communicated, then executives, managers, and analysts will become more aware and accepting of concepts presented by seasoned architects and consultants.
References
[2] Robert G. Fichman & Scott A. Moses, “An Incremental Process for Software Implementation", 1998
[3] Frederick P. Brooks, “The Mythical Man-Month", 1995
No comments:
Post a Comment