Tugas - Summary

1.3 Summar

– The problem domain for software engineering is industrial-strength software. This software is meant to solve some problem of some set of users, and is expected to be of high quality.

– In this problem domain, cost, schedule, and quality are basic driving forces.

– Productivity is measured as amount of output per unit of input resource

– Software quality has many attributes which include functionality, reliabil- ity, usability, efficiency, maintainability, and portability

– The problems in this domain often tend to be very large and where the needs of the customers change fast

Self-Assessment Exercises

1.What are the main differences between a student software and industrial-strength software?

2. Where do you think this extra effort cost is spent?

3. What measurements will you take in a project to measure the productivity?

4. What are the different attributes of software quality?

 5. What are some of the project management tasks that you will do differently for a large project as compared to a small project?

 6. Suppose changes are to be made to a software system that is in operation.

2. Software Prosses

Software engineering is defined as the systematic approach to the development, operation, maintenance, and retirement of software. eration, maintenance, and retirement of software [52]. We have seen that besides delivering software, high quality, low cost, and low cycle time are also goals which software engineering must achieve. As it is people who ultimately develop and deliver (and productivity is measured with respect to people’s effort as the basic input), the main job of processes is to help people achieve higher Q&P by specifying what tasks to do and how to do them.

As processes form the heart of software engineering, with tools and tech- nology providing support to efficiently execute the processes, this book focuses primarily on processes. In this chapter we will discuss:

– Role of a process and a process model in a project.

– Various component processes in the software process and the key role of the development process and the project management process.

– Various models for the development process—waterfall, prototyping, itera- tive, RUP, timeboxing, and XP.

– The overall structure of the project management process and its key phases.

2.1 Process and Project

A software project is one instance of this problem, and the development process is what is used to achieve this purpose. The role of process increases due to these additional goals, and though many processes can achieve the basic.

Figure 2.1 Basic problem

A process model specifies a general process, which is “optimum” for a class of projects. That is, in the situations for which the model is applicable, using the process model as the project’s process will lead to the goal of developing software with high Q&P.

2.2 Component Software Processes

As defined above, a process is the sequence of steps executed to achieve a goal. Since many different goals may have to be satisfied while developing soft- ware, multiple processes are needed.

The processes that deal with the technical and management issues of soft- ware development are collectively called the software process. During the project many products are produced which are typically com- posed of many items (for example, the final source code may be composed of many source files). The objective of this component process is to primarily deal with managing change, so that the integrity of the products is not violated despite changes.

These three constituent processes focus on the projects and the products and can be considered as comprising the product engineering processes, as their main objective is to produce the desired product. The basic objective of the process management process is to improve the software process. By improvement, we mean that the capability of the process to produce quality goods at low cost is improved. The relationship between these major component processes is shown in Fig- ure 2.2. These component processes are distinct not only in the type of activities performed in them, but typically also in the people who perform the activities specified by the process.

Figure 2.2 Software Prosses

For the rest of the book, we will use the term software process to mean product engineering processes, unless specified otherwise.

2.3 Software Development Process Models

A project’s development process defines the tasks the project should per- form, and the order in which they should be done. A process limits the degrees of freedom for a project by specifying what types of activities must be under- taken and in what order, such that the “shortest” (or the most efficient) path is obtained from the user needs to the software satisfying these needs.

As discussed earlier, a process model specifies a general process, usually as a set of stages in which a project should be divided, the order in which the stages should be executed, and any other constraints and conditions on the execution of stages.

2.3.1 Waterfall Model

The basic idea behind the phases is separation of concerns—each phase deals with a distinct and separate set of concerns. By doing this, the large and complex task of building the software is broken into smaller tasks (which, by themselves, are still quite complex) of specifying requirements, doing design, etc. Separating the concerns and focusing on a select few in a phase gives a better handle to the engineers and managers in dealing with the complexity of the problem.

Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and the beginning of the next, some cer- tification mechanism has to be employed at the end of each phase.

Figure 2.3 The waterfall Model

. Though the set of documents that should be produced in a project is dependent on how the process is implemented, the following documents generally form a reasonable set that should be produced in each project:

– Requirements document

– Project plan

– Design documents (architecture, system, detailed)

– Test plan and test reports

– Final code

– Software manuals (e.g., user, installation, etc.)

2.3.2 Prototyping

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determine the requirements. In such situations, letting the client “play” with the prototype provides invaluable and intangible inputs that help determine the requirements for the system. It is also an effective method of demonstrating the feasibility of a certain approach.

A development process using throwaway prototyping typically proceeds as follows.The development of the prototype typically starts when the prelim- inary version of the requirements specification document has been developed. At this stage, there is a reasonable understanding of the system and its needs and which needs are unclear or likely to change.

Figure 2.4  The Prototyping Model

For prototyping for the purposes of requirement analysis to be feasible, its cost must be kept low. Consequently, only those features are included in the prototype that will have a valuable return from the user experience. Excep- tion handling, recovery, and conformance to some standards and formats are typically not included in prototypes. In prototyping, as the prototype is to be discarded, there is no point in implementing those parts of the requirements that are already well understood. Hence, the focus of the development is to include those features that are not properly understood.

2.3.3 Iterative Development

The iterative enhancement model [4] is an example of this approach. In the first step of this model, a simple initial implementation is done for a subset of the overall problem. This subset is one that contains some of the key aspects of the problem that are easy to understand and implement and which form a useful and usable system.

Each step consists of removing the next task from the list, designing the implementation for the selected task, coding and testing the implementation, performing an analysis of the partial system obtained after this step, and updat- ing the list as a result of the analysis.

Figure 2.5 The Interative enchanment model.

The project control list guides the iteration steps and keeps track of all tasks that must be done.

Though there are clear benefits of iterative development, particularly in allowing changing requirements, not having the all-or-nothing risk, etc., there are some costs associated with iterative development also.

Another common approach for iterative development is to do the require- ments and the architecture design in a standard waterfall or prototyping ap- proach, but deliver the software iteratively.

Figure 2.6  Interative Delivery approach.

The iterative approach is becoming extremely popular, despite some diffi- culties in using it in this context. There are a few key reasons for its increasing popularity. First and foremost, in today’s world clients do not want to invest too much without seeing returns. In the current business scenario, it is preferable to see returns continuously of the investment made.

2.3.4 Rational Unified Process

RUP proposes that development of software be divided into cycles, each cycle delivering a fully working system. Generally, each cycle is executed as a separate project whose goal is to deliver some additional capability to an exist- ing system (built by the previous cycle).

– Inception phase

– Elaboration phase

– Construction phase

– Transition phase

Each phase has a distinct purpose, and completion of each phase is a well- defined milestone in the project with some clearly defined outputs. The purpose of the inception phase is to establish the goals and scope of the project, and completion of this phase is the lifecycle objectives milestone.

In the elaboration phase, the architecture of the system is designed, based on the detailed requirements analysis. The completion of this phase is the life- cycle architecture milestone. At the end of this phase, it is expected that most of the requirements have been identified and specified, and the architecture of the system has been designed (and specified) in a manner that it addresses the technical risks identified in the earlier phase.

The purpose of the transition phase is to move the software from the devel- opment environment to the client’s environment, where it is to be hosted. This is a complex task which can require additional testing, conversion of old data for this software to work, training of personnel, etc.

Figure 2.7 The RUP Model.

RUP has carefully chosen the phase names so as not to confuse them with the engineering tasks that are to be done in the project, as in RUP the en- gineering tasks and phases are separate.

One key difference of RUP from other models is that it has separated the phases from the tasks and allows multiple of these subprocesses to function within a phase. In waterfall (or waterfall-based iterative model), a phase within a process was linked to a particular task performed by some process like re- quirements, design, etc. In RUP these tasks are separated from the stages, and it allows, for example, during construction, execution of the requirements process.

Though a subprocess may be active in many phases, as can be expected, the volume of work or the effort being spent on the subprocess will vary with phases. For example, it is expected that a lot more effort will be spent in the requirement subprocess during elaboration, and less will be spent in construc- tion, and still less, if any, will be spent in transition.

Table 2.1  Activity Level of subprocesses in different phase of RUP

2.3.5 Timeboxing Model

In the timeboxing model, the basic unit of development is a time box, which is of fixed duration. Since the duration is fixed, a key factor in selecting the requirements or features to be built in a time box is what can be fit into the time box. This is in contrast to regular iterative approaches where the functionality is selected and then the time to deliver is determined. Timeboxing changes the perspective of development and makes the schedule a nonnegotiable and a high-priority commitment.

Having time-boxed iterations with stages of equal duration and having ded- icated teams renders itself to pipelining of different iterations. (Pipelining is a concept from hardware in which different instructions are executed in paral- lel, with the execution of a new instruction starting once the first stage of the previous instruction is finished.)

With a time box of three stages, the project proceeds as follows. When the requirements team has finished requirements for timebox-1, the requirements are given to the build team for building the software. The requirements team then goes on and starts preparing the requirements for timebox-2.

Figure 2.8 Executing the timeboxing process model.

Contrast this with a linear execution of iterations, in which the first delivery will be made after 9 weeks, the second after 18 weeks, the third after 27 weeks, and so on.

Figure 2.9  Task of different teams.

Hence, the timeboxing provides an approach for utilizing additional man- power to reduce the delivery time. It is well known that with standard methods of executing projects, we cannot compress the cycle time of a project substan- tially by adding more manpower.

Timeboxing is well suited for projects that require a large number of fea- tures to be developed in a short time around a stable architecture using stable technologies. These features should be such that there is some flexibility in grouping them for building a meaningful system in an iteration that provides value to the users.

Agile development approaches evolved in the 1990s as a reaction to documen- tation and bureaucracy-based processes, particularly the waterfall approach. Agile approaches are based on some common principles, some of which are [www.extremeprogramming.org]:

– Working software is the key measure of progress in a project.

– For progress in a project, therefore, software should be developed and deliv- ered rapidly in small increments.

– Even late changes in the requirements should be entertained (small-increment model of development helps in accommodating them).

– Face-to-face communication is preferred over documentation.

– Continuous feedback and involvement of customer is necessary for developing good-quality software.

– Simple design which evolves and improves with time is a better approach than doing an elaborate design up front for handling all possible scenarios.

– The delivery dates are decided by empowered teams of talented individuals (and are not dictated).

Figure 2.10 Overal process in XP.

The development approach used in an iteration has some unique practices. First, it envisages that development is done by pairs of programmers (called pair programming and which we will discuss further in Chapter 7), instead of individual programmers. Second, it suggests that for building a code unit, automated unit tests be written first before the actual code is written, and then the code should be written to pass the tests

Figure 2.11 An Interation in XP.

XP, and other agile methods, are suitable for situations where the volume and pace of requirements change is high, and where requirement risks are con- siderable. Because of its reliance on strong communication between all the team members, it is effective when teams are collocated and of modest size, of up to about 20 members.

2.3.7 Using Process Models in a Project

Suppose a small team of developers has been entrusted with the task of building a small auction site for a local university. The university administration is willing to spend some time at the start to help develop the requirements, but it is expected that their availability will be limited later.

With these constraints, it is clear that a waterfall model is not suitable for this project, as the “all or nothing” risk that it entails is unacceptable due to the inflexible deadline. The iterative enhancement model where each iteration does a complete waterfall is also not right as it requires requirements analysis for each iteration, and the users and clients are not available later.

Consider another example where the customers are in a highly competitive environment where requirements depend on what the competition is doing, and delivering functionality regularly is highly desirable.

For this project, clearly waterfall is not suitable as requirements are not even known at the start. Iterative enhancement also may not work as it may not be able to deliver rapidly.