Blog entry by AMELIA SAHIRA RAHMA 5116201024
The software process is represented schematically in Figure 1. Referring to the figure, each framework activity is populated by a set of software engineering actions. Each software engineering action is defined by a task set that identifies the work tasks that are to be completed, the work products that will be produced, the quality assurance points that will be required, and the milestones that will be used to indicate progress.
A generic process framework for software engineering defines five framework activities communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities-project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others-are applied throughout the process. You should note that one important aspect of the software process has not yet been discussed. This aspect-called process flow-describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time and is illustrated in Figure 2.
A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment (Figure 2 a). An iterative process flow repeats one or more of the activities before proceeding to the next (Figure 2 b). An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software (Figure 2 c). A parallel process flow (Figure 2 d) executes one or more activities in parallel with other activities (modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software).
Defining a Framework Activity
Although I have described five framework activities and provided a basic definition of each software team would need significantly more information before it could properly execute any one of these activities as part of the software process. Therefore, you are faced with a key question : What actions are appropriate for a framework activity, given the nature of the problem to be solved, the characteristics of the people doing the work, and the stakeholders who are sponsoring the project?
For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call with the appropriate stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that this action encompasses are :
- Make contact with stakeholder via telephone.
- Discuss requirements and take notes.
- Organize notes into a brief written statement of requirements.
- E-mail to stakeholder for review and approval.
If the project was considerably more complex with many stakeholders, each with a different set of sometime conflicting) requirements, the communication activity might have six distinct actions (described in Chapter 5): inception, elicitation, elaboration, negotiation, pecification, and validation. Each of these software engineering actions would have many work tasks and a number of distinct work products.
Identifying a Task Set
Referring again to Figure 1, each software engineering action (elicitation, an action associated with the communication activity) can be represented by a number of different task sets-each a collection of software engineering work tasks, related work products, quality assurance points, and project milestones. You should choose a task set that best accommodates the needs of the project and the characteristics of your team. This implies that a software engineering action can be adapted to the specific needs of the software project and the characteristics of the project team.