第9章ソフトウェア工学

By the end of this section, you will be able to:

• Describe the phases of a software development process and their purposes

• Study the popular traditional prescriptive and Agile software process models

• Suggest an effective software process

Imagine a recipe for building software. There are different ways to cook the same dish, but most recipes follow a basic structure with steps like gathering ingredients, preparing them, cooking, and serving. Software engineering processes are similar. They provide a structured approach to creating software applications. Various software engineering process models are typically used to support the software development life cycle (SDLC). After years of research and refinements, software engineering researchers and practitioners have converged on defining a generic software engineering process model, or process framework, that can be used as a template. That process framework includes a set of process elements (e.g., framework activities, software engineering actions, task sets, work products, quality assurance, and change control mechanisms) that may differ for each process model and for each project.

One common category of process models is known as the traditional process model. This process framework, as you learned earlier in the chapter, encompasses four framework (i.e., generic) activities that are also known as phases: inception, elaboration, construction, and deployment:

• Inception covers planning activities where you define the project goals and identify the overall scope.

• Elaboration involves analyzing requirements and designing a detailed architecture model for the software.

• Construction is where the coding happens! The software is built based on the design created earlier.

• Deployment is the activity that focuses on releasing the software in a usable form and making it accessible to end users.

These (generic) framework activities or phases are applicable regardless of the specific software engineering process model chosen for a project and may be elaborated differently depending on the organization and the problem area and project being developed. There are also umbrella activities that are important but tangential to framework activities. Returning to the recipe analogy, if generic framework activities represent cooking, then you can think of these activities as the things you would do alongside your cooking, like making sure you have the right pots and pans or keeping your kitchen clean. As you’ll learn later in the chapter, in software development, such activities are known as umbrella activities, and they include:

• training and communication (e.g., work product preparation and production)

• risk management and planning (e.g., software project tracking and control)

• configuration management

• quality management (e.g., technical reviews, estimations, metrics/measurements, testing)

• architecture management (e.g., reusability management)

• security management

Various software engineering actions are typically performed as part of the generic framework and umbrella activities. For example, the inception phase may call for requirements engineering actions such as requirements definition and requirements management; the elaboration phase may involve high-level and detail design actions. Each type of software engineering action corresponds to a process that may be represented as a workflow or a task set, and each task results in work products that are subject to specific quality assurance and change control mechanisms. Basically, a task set (or workflow) encompasses all the tasks that are required to accomplish a specific software engineering action within a framework activity. Task sets vary depending on the characteristics of a project, and activities within a given process model usually overlap instead of being performed independently.

Software process models that adhere to the generic framework mentioned precedingly are sometimes referred to as SDLC methodologies. In general, software engineering process models are structured in this fashion to facilitate efficient development of quality software, reduce risk of failure, increase predictability, and capture best practices in software development. The software framework provides a template that allows software engineers to tailor their process model based on the specific project(s) on which they are working. The (generic) framework activities mentioned precedingly are applicable to all projects and all application domains, and they are a template for every process model. Actual process models action/methods may, however, use various approaches. Furthermore, software engineering tools may be used to (semi-)automate the various methods that perform activities.

The activities involved in developing software might vary depending on the organization and the type of software being developed. There is no single right way to create a software solution, but experience typically tells us what works well and what works poorly in a given context. Therefore, process frameworks are elaborated differently depending on the four Ps—problem, project, people, and product—they tackle.

In the past, this led to the use of various traditional prescriptive process models such as the waterfall, prototyping, spiral, and rational unified processes. A prescriptive process model advocates an orderly approach to software engineering that involves following a prescribed set of activities in a continuous manner. These traditional process models provide a structured approach to software development and may help with the following objectives:

• Improve efficiency: By following a clear plan, teams can work more efficiently and avoid rework.

• Reduce risk: Identifying and addressing potential issues early on can help to prevent project failures.

• Increase predictability: A structured process can help to estimate timelines and costs more accurately.

• Capture best practices: Traditional models often incorporate tried-and-true methods for software development.

These days, however, traditional prescriptive process models are perceived by some as “old-school” (i.e., ponderous, bureaucratic document-producing machines). Note that prescriptive simply means that the process model identifies a set of process elements (e.g., framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms) for each project. Traditional models are generally criticized for being too rigid and inflexible. They may not be suitable for all projects, especially those with rapidly changing requirements.

In general, the various process models may have features in common with each other, and there may be some overlap among the activities conducted within each given process. In the next section, we’ll explore an alternative approach called Agile software development.