- The Software Component Revolution
- 2 Component Space
- 3 Process, Method & Notation Assumptions
- 4 Terminology and Acronyms
- 5 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.3 Process, Method & Notation Assumptions
While commercial software components pose unique challenges to software engineering, they do not require that we revisit each and every precept of theory and practice. To be sure, certain software engineering practices need to be adjusted, and some outdated notions of software process need to be substantially revised. Some of these adjustments and revisions will not be easy to undertake given how strongly entrenched these precepts have become. Given this challenge, it certainly makes sense to minimize difficulties by starting from a reasonably well-established foundation. Accordingly, we will make some assumptions about software development processes as context for the material discussed in this book.
Our first assumption is that all projects use some form of spiral development. Spiral development is characterized by iterative development, with risk analysis at the inception of each iteration [10][11]. It is important to understand that spiral development is not just best practice, but essential practice for building systems from commercial components. Of course, what Boehm (the inventor of spiral development) actually described was a metaprocess—characteristics that any particular software development process must possess for it to be a spiral process. Therefore, it is not sufficient for us to say only that we assume the spiral model—we need to be more specific.
We assume as a starting point the use of the Rational Unified Software Process (RUP), and we use the terminology and idioms of RUP throughout this book. We are well aware of the shortcomings of RUP, and are reminded of a story about U.S. President Abraham Lincoln. When an angry congressman insisted that any general would be better than the one Lincoln had appointed, Lincoln responded by saying that he could not appoint any general, he had to appoint some general. Although RUP is biased toward an object-oriented conception of the world (which is fine if you are doing object-oriented development, of course), and although it is a strategically vague in a number of areas, it has several things going for it:
It is defined.
It is extensible.
It supports spiral, iterative, and incremental development.
It defines a variety of developer roles and their related tasks.
It does not inhibit the use of components (though it does not address it).
For these reasons RUP provides a good place to start. Of course, this does not require that you use RUP. It only means that we find it useful to appropriate RUP terminology and process models as a means to illustrate ideas.
We have also chosen the Object Management Group's Unified Modeling Language (UML) as our notation. Although UML lacks certain features that would make it more effective as an architectural modeling language, we have selected it because it is widely used and should be familiar to most readers.