Software Engineering: A Multifaceted Field
One way to convey the multifaceted nature of software engineering is to review how it is conceived of at different times since the term was coined in 1968 (see Chapter 8, The History of Software Engineering ). Here we conduct this review by presenting several definitions of software engineering taken from three different stages of its history. The idea is to describe the shift in the focus of the discipline. More specifically , while the early definitions of software engineering from the 1970s focused on its technical aspect, later writings refer to the nature of the field as an engineering profession.
In this spirit, von Mayrhauser presents definitions for software engineering from the 1970s [vonMayrhauser90]. Among those, Zelkowitz s definition states that software engineering studies principles and methodologies for developing and maintaining software systems [Zelkowitz78] [vonMayrhauser90, p. 4]. The second definition that von Mayrhauser presents declares that software engineering is the practical application of scientific knowledge to the construction of computer programs and their documentation [Boehm76] [vonMayrhauser90, p. 5].
Zelkowitz s definition emphasizes the methodological aspects of the field; Boehm s definition adds and refers to the documentation of software. These definitions use terms such as principles , methodologies , scientific knowledge , construction , and maintaining . Human aspects of software engineering do not appear to be addressed explicitly in these definitions.
One of the first signs of the awareness of human aspects of software engineering appeared in Brooks book The Mythical Man-Month , first published in 1975 and revised in 1995 [Brooks75]. In this book, the social complexity involved in software development and the uniqueness of this process is acknowledged . One phenomenon described in the book is that most software projects are never released on time as planned. In the preface to the 20th Anniversary Edition , Brooks expressed surprise and delight that The Mythical Man-Month continued to be popular two decades after first being published. This fact emphasizes how difficult it is to apply lessons that had been learned with respect to software development. It is suggested that this difficulty may be partially explained by the multifaceted nature of the discipline and the uniqueness of the human aspect of software development processes.
As is illustrated in what follows , in present writings, the emphasis on the engineering aspect of software engineering is decreased. This shift in emphasis may be partially explained by the failure to formulate one engineering-oriented process that answers all the typical problems of software projects (see Brooks famous article No Silver Bullet, which discusses this observation [Brooks87]).
Hamlet and Maybee wonder in their introduction whether software engineering will even attain the status accorded to civil engineering [Hamlet and Maybee01]. Then, Chapter 3 of Hamlet and Maybee s book discusses the question, Is it really engineering? They declare that much of the human activity of dealing with objects in the world can be categorized as art, craft, science, and engineering, and wonder where software lies in these categories.
Their analysis of the field of software engineering is based on the examination of the following question: In what ways is software different from other products? Among other arguments, they declare that software is perhaps the most complex human artifact, so there is a broad range for error. A similar message is conveyed by [Sommerville90], who states that a wide range of tools and methods are needed in software engineering because there are no simple solutions to software engineering problems. Indeed, how to select the best solution for a software engineering problem is one of the core questions of the discipline. In fact, a more basic question is, what are the attributes of a good software development process and software product? Some examination of these questions is presented in Chapters 2 and 4 in this book.
The preceding opinions about software engineering suggest that recent approaches toward software engineering do conceive of it as a multifaceted discipline. More specifically, it seems that software engineering can be examined from three main perspectives: engineering, scientific, and human. The fact that the human aspect currently gets more attention can be explained by the difficulties involved in managing software projects. The continuation of this chapter presents two frameworks that refer to the human aspect of the field by specifically addressing organizational issues connected to software projects.
| Task | The definitions for software engineering in the previous section illustrate changes in the way the discipline has been conceived of since its establishment in 1968. Chapter 8 presents the history of software engineering, emphasizing the evolution of software development methods. Based on these resources, examine connections between the evolutionary process of software development methods and the changes in the perspectives of software engineering. |
The Product versus Process Perspectives of Software Engineering
This section is based on [Floyd87], which contrasts two approaches toward software engineering: the process approach and the product approach. Floyd declares explicitly that she criticizes the product-oriented perspective since it cannot answer questions that are raised from the interaction of software with the human world. This opinion explains clearly why we find it relevant to present in this book the dual perspective suggested by Floyd.
We start by presenting the main characteristics of each approach. According to the product-oriented view, programs are formal mathematical objects, derived by formalized procedures starting from abstract specifications. Accordingly, their correctness is established by mathematical proofs. As can be observed , computer programs are at the center of this approach. In contrast, the process-oriented approach connects the existence of computer programs to people. Specifically, according to the process-oriented perspective, programs are tools or working environments for people. They are designed through learning and communication processes to fit human needs. Their adequacy is achieved in processes of controlled use and subsequent revisions.
| Note | The title of Chapter 4 of this book is Software as a Product. Our intention in titling Chapter 4 in this way is to emphasize the analysis of software systems from the customer s perspective, as a product that should meet customer s needs. The nature of the product-oriented view presented in this section is different. In fact, the nature of the process-oriented view discussed in this section is more similar to the messages delivered in Chapter 4. |
| Task | Based on the brief introduction of the process-oriented and the product-oriented approaches:
|
The two approaches can be compared on different dimensions. Table 7.1 compares the two perspectives by illustrating their attitude toward three software engineering topics [Floyd87].
| Dimension | Product-Oriented View | Process-Oriented View |
|---|---|---|
| Quality | Quality is associated with features of the product. | Quality is associated with processes of using the product. |
| Software development | Software development aims at producing one software system | Software development aims at producing a sequence of related versions of the software system. |
| Programs understanding and the role of documents | Programs should be understandable only from documents. | Personal discussions and trial uses are indispensable for programs understanding; documents must facilitate these activities. |
The following tasks guide readers in a further examination of the two approaches.
| Tasks |
|
The Agility Paradigm versus the Heavyweight Approach Toward Software Development
Agile software development methods were mentioned in Chapter 2. Special emphasis is placed in Chapter 2 on eXtreme Programming (XP), one of the agile software development methods. In general, the agile approach toward software development has emerged in the last decade as an answer to the unique and typical problems of software development processes.
Agile software development methods emphasize customers needs, short releases, and heavy testing all along the development process. Fowler explains the differences between agile methods and heavyweight methods [Fowler02]:
Agile methods claim to be adaptive rather than predictive. Heavy methods tend to try to plan a large part of the software process in great detail for a long span of time. This method works well until things change. Therefore, the nature of such methods is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves .
Agile methods are people oriented rather than process oriented. The agile methods advocate working with human nature, not against it.
The agile software development methods are based on the following four principles, called the Manifesto for Agile Software Development ( http://agilemanifesto.org ):
-
Individuals and interactions over processes and tools
-
Working software over comprehensive documentation
-
Customer collaboration over contract negotiation
-
Responding to change over following a plan
This manifesto was created by 17 software practitioners gathered at Snowbird, Utah, in February 2001. They all agreed to use the term agile and call themselves agilists. The manifesto s principles are based on several agile software methods that have been developed by these professionals in order to cope with the typical problems of software development. Although items to the right of the sentences are not ignored, they are not considered as important as items on the left, or the beginning of the sentences. It is interesting to note that although this approach was instituted only three years ago, it has momentum, and many software houses adopt its orientation in general or a specific agile software development method in particular.
Here are several examples of agile software development methods: XP (described in Chapter 2), SCRUM, Adaptive Software Process, DSDM (Dynamic Systems Development Method), and Feature Driven Development. To illustrate the essence of these methods, here are four out of the nine underlying principles of DSDM: focus is on frequent delivery of products, iterative and incremental development is necessary, testing is integrated throughout the life cycle, and collaboration and cooperation between all stakeholders are essential.
| Tasks |
|
One idea connects the heavyweight methods with the agile software development methods: the paradigm of software engineering (see Chapter 8), consisting of the activities of specifying, designing, coding, and testing. One of the main differences between the heavyweight and agile methods is the frequency in which these activities are implemented in each approach. Generally speaking, the agile methods tend to intertwine these activities more frequently. This frequent implementation of the paradigm of software development throughout the development process enables the agile methods to be more open to changes.
Additional Approaches
We now briefly describe two additional approaches toward software engineering: analogies to other professions and failure and success of software projects.
Analogies to Other Professions
Software engineering can also be examined by its comparison to other professions. One of the more accepted analogies to software engineering is architecture. This analogy is discussed in Chapter 10 when the reflective practitioner perspective, originally developed by Sch n for architects [Sch n83], is discussed.
Another source that illustrates the analogy between software engineering and architecture is the Worldwide Institute of Software Architects ( www. wwisa .org/wwisamain/index.htm ). Among other ways it illustrates this analogy, the institute presents eight phases that define the role of the architect/developer in the process of software construction. These phases conceptually follow the phases of building construction and architectural services. It is emphasized that these phases are independent of any particular software development method and apply to all software construction projects. The institute declares that many software professionals are already drawing on the analogy with building construction to describe their processes, since it is a true metaphor and it is understandable to clients .
Needless to say, and as mentioned previously in different places in the book, software engineering has its own unique characteristics. Still, we believe that such analogies may help in understanding subtle aspects of the discipline of software engineering.
| Task | Suggest other professions that may be analogous to software engineering. In what sense are software engineering and these professions analogous? In what sense are these professions different from software engineering? |
Failure and Success of Software Projects
Chapter 1, The Nature of Software Engineering, mentions successes and failures of software projects. Specifically, we cite Kent Beck, the creator of eXtreme Programming, who refers to the conceptual change toward software project success and failure that both developers and customers should adopt when they decide to use XP as the project development method [Beck02]. Indeed, the question of what a successful software project is invites debate. One agreement has been reached, though, among the community of software practitioners: they mostly agree that software projects should meet customers needs.
To illustrate this point, consider the two software projects described in Table 7.2. For each, decide whether it is a success or a failure.
| Project A | Project B |
|---|---|
| Software for airlines management: | Software for a medical equipment: |
|
|
|
|
|
|
|
|
Discussion
-
Define a successful software project.
-
Define a failed software project.
-
How can the success of a software project be measured?
EAN: 2147483647
Pages: 242