Free download ebook software engineering by pankaj jalote

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.

Similarly, the model has the development process active in elaboration, which allows a project to build a prototype during the elaboration phase to help its requirements activity, if needed.

However, most of the implementation does happen in the construction phase. The effort spent in a subprocess in different phases will, of course, de- pend on the project. However, a general pattern is indicated in Table 2. Table 2. Medium Medium Medium Medium Config. And in phases, it allows the different tasks to be done as per the needs of the project.

That is, a new iteration commences before the system produced by the current iteration is released, and hence development of a new release happens in parallel with the development of the current release.

By starting an iteration before the previous iteration has completed, it is possible to reduce the average delivery time for iterations. However, to support parallel execution, each iteration has to be structured properly and teams have to be organized suitably. The timeboxing model proposes an approach for these [60, 59]. 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.

Each time box is divided into a sequence of stages, like in the waterfall model. Each stage performs some clearly defined task for the iteration and produces a clearly defined output. The model also requires that the duration of each stage, that is, the time it takes to complete the task of that stage, is approximately the same.

Furthermore, the model requires that there be a dedicated team for each stage. That is, the team for a stage performs only tasks of that stage—tasks for other stages are performed by their respective teams. This is quite different from other iterative models where the implicit assumption is that the same team performs all the different tasks of the project or the iteration.

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.

To illustrate the use of this model, consider a time box consisting of three stages: requirement specification, build, and deployment. Software Processes of requirements to be built in this iteration along with a high-level design. The build team develops the code for implementing the requirements, and performs the testing.

The tested code is then handed over to the deployment team, which performs predeployment tests, and then installs the system for production use. These three stages are such that they can be done in approximately equal time in an iteration.

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 When the build for timebox-1 is completed, the code is handed over to the deployment team, and the build team moves on to build code for requirements for timebox- 2, and the requirements team moves on to doing requirements for timebox This pipelined execution of the timeboxing process is shown in Figure 2.

With a three-stage time box, at most three iterations can be concurrently in progress. If the time box is of size T days, then the first software delivery will occur after T days. For example, if the time box duration T is 9 weeks and each stage duration is 3 weeks , the first delivery is made 9 weeks after the start of the project. The second delivery is made after 12 weeks, the third after 15 weeks, and so on.

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. There are three teams working on the project—the requirements team, the build team, and the deployment team.

The teamwise activity for the 3-stage pipeline discussed above is shown in Figure 2. It should be clear that the duration of each iteration has not been reduced. The total work done in a time box and the effort spent in it also remains the same—the same amount of software is delivered at the end of each iteration as the time box undergoes the same stages. If the effort and time spent in each iteration also remains the same, then what is the cost of reducing the delivery time?

The real cost of this reduced time is in the resources used in this model. With timeboxing, there are dedicated teams for different stages and the total team size for the project is the sum of teams of different stages. This is the main difference from the situation where there is a single team which performs all the stages and the entire team works on the same iteration. 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. However, through the timeboxing model, we can use more manpower in a manner such that by parallel execution of different stages we are able to deliver software quicker. In other words, it provides a way of shortening delivery times through the use of additional 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. The main cost of this model is the increased complexity of project management and managing the products being developed as multiple developments are concurrently active. Also, the impact of unusual situations in an iteration can be quite disruptive.

Further details about the model, as well as a detailed example of applying the model on a real commercial project, are given in [60, 59]. Software Processes 2. Agile approaches are based on some common principles, some of which are [www.

Many detailed agile methodologies have been proposed, some of which are widely used now. Extreme programming XP is one of the most popular and well-known approaches in the family of agile methods. Like all agile approaches, it believes that changes are inevitable and rather than treating changes as un- desirable, development should embrace change. And to accommodate change, the development process has to be lightweight and quick to respond.

For this, it develops software iteratively, and avoids reliance on detailed and multiple documents which are hard to maintain. Instead it relies on face-to-face com- munication, simplicity, and feedback to ensure that the desired changes are quickly and correctly reflected in the programs. Here we briefly discuss the development process of XP, as a representative of an agile process. An extreme programming project starts with user stories which are short a few sentences descriptions of what scenarios the customers and users would like the system to support.

They are different from traditional requirements specification primarily in details—user stories do not contain detailed require- ments which are to be uncovered only when the story is to be implemented, therefore allowing the details to be decided as late as possible.

Each story is written on a separate card, so they can be flexibly grouped. The empowered development team estimates how long it will take to imple- ment a user story. The estimates are rough, generally stated in weeks. Frequent and small releases are encouraged, and for a release, iterations are employed. Acceptance tests are also built from the stories, which are used to test the software before the release.

Bugs found during the acceptance testing for an iteration can form work items for the next iteration. This overall process is shown in Figure 2. Development is done in iterations, each iteration lasting no more than a few weeks. An iteration starts with iteration planning in which the stories to be implemented in this iteration are selected—high-value and high-risk stories are considered as higher priority and implemented in early iterations.

Failed acceptance tests in previous iteration also have to be handled. Details of the stories are obtained in the iteration for doing the development.

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. This approach is referred to as test-driven development, in contrast to regular code-first development in which programmers first write code and then think of how to test it.

We will discuss test-driven development further in Chapter 7. As functionality of the unit increases, the unit tests are enhanced first, and then the code is enhanced to pass the new set of unit tests.

Third, as it encourages simple solutions as well as change, it is expected that the design of the solution devised earlier may at some point become unsuitable for further development. To handle this situation, it suggests that refactoring be done to improve the design, and then use the refactored code for further development.

During refactoring, no new functionality is added, only the design of the existing programs is improved. Refactoring will be discussed further in Chapter 7. Fourth, it encourages frequent integration of different units. To avoid too many changes in the base code happening together, only one pair at a time can release their changes and integrate into the common code base.

Software Processes in Figure 2. This is a very simplified description of XP. There are many other rules in XP relating to issues like rights of programmers and customers, communi- cation between the team members and use of metaphors, trust and visibility to all stakeholders, collective ownership of code in which any pair can change any code, team management, building quick spike solutions to resolve diffi- cult technical and architectural issues or to explore some approach, how bugs are to be handled, how what can be done within an iteration is to be esti- mated from the progress made in the previous iteration, how meetings are to be conducted, how a day in the development should start, etc.

The website www. 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.

And as it envisages strong involvement of the customer in the development, as well as in planning the delivery dates, it works well when the customer is willing to be heavily involved during the entire development, working as a team member.

What is the need for the different models? As mentioned earlier, while developing industrial strength software, the purpose is not only to develop software to satisfy the needs of some users or clients, but we want that the project be done in low cost and cycle time, and deliver high-quality software.

In addition, there could be other constraints in a project that the project may need to satisfy. Hence, selecting a suitable development process model for a project is a key decision that a project manager has to take.

Let us illustrate this by a few examples. 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.

The team has been given 4 months to finish the project, and an extension of the deadline seems very improbable. It also seems that the auction site will have some features that are essential, but will also have some features that are desirable but without which the system can function reasonably well. 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.

However, the iterative delivery approach in which the complete requirements are done in the first iteration but delivery is done in iterations seems well suited, with delivery being done in two or three iterations as time is short.

From the requirements, the project team can decide what functionality is essential to have in a working system and include it in the first iteration. The other desirable features can be planned for the second iteration. With this approach, the chances of completing the first iteration before the final deadline increase.

That is, with this model, the chances of delivering a working system increase. RUP, as it allows iterations in each phase, is also a suitable model. 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. Furthermore, to reduce cost, the customer wants to outsource as much project work as possible to another team in another country.

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. XP will be hard to apply as it requires that the entire team, including the customer, be collocated.

For this project, the timeboxing model seems to fit the best. The whole project can employ three teams—one of analysts who will work with the customer to determine the requirements, one to do the development which could be in some low-cost destination , and the third to do the deployment, which will be where the site is hosted. By suitably staffing the teams, the duration of each of the three phases—analysis and design, build, and deployment—can be made approximately equal.

Software Processes the timeboxing model can be applied. Consider another project, where a university wants to automate the reg- istration process. It already has a database of courses and pre-requisites, and a database of student records.

In this project, as the requirements are well understood since registrations have been happening manually , the waterfall model seems to be the optimum. And quality and productivity in the project will also depend critically on these decisions. To meet the cost, quality, and schedule objectives, resources have to be properly allocated to each activity for the project, and progress of different activities has to be monitored and corrective actions taken when needed.

All these activities are part of the project management process. Hence, a project management process is necessary to ensure that the engineer- ing process ends up meeting the real-world objectives of cost, schedule, and quality. The project management process specifies all activities that need to be done by the project management to ensure that cost and quality objectives are met.

Its basic task is to ensure that, once a development process is chosen, it is implemented optimally. That is, the basic task is to plan the detailed implementation of the process for the particular project and then ensure that the plan is properly executed.

For a large project, a proper management process is essential for success. The activities in the management process for a project can be grouped broadly into three phases: planning, monitoring and control, and termination analysis.

Project management begins with planning, which is perhaps the most critical project management activity. The goal of this phase is to develop a plan for software development following which the objectives of the project can be met successfully and efficiently.

A software plan is usually produced before the development activity begins and is updated as development proceeds and data about progress of the project becomes available. During planning, the major activities are cost estimation, schedule and milestone determination, project staffing, quality control plans, and controlling and monitoring plans. Project planning is undoubtedly the single most important management activity, and it forms the basis for monitoring and control.

Project monitoring and control phase of the management process is the longest in terms of duration; it encompasses most of the development process. It includes all activities the project management has to perform while the development is going on to ensure that project objectives are met and the development proceeds according to the developed plan and update the plan, if needed.

As cost, schedule, and quality are the major driving forces, most of the activity of this phase revolves around monitoring factors that affect these. Monitoring potential risks for the project, which might prevent the project from meeting its objectives, is another important activity during this phase.

And if the information obtained by monitoring suggests that objectives may not be met, necessary actions are taken in this phase by exerting suitable control on the development activities. Monitoring a development process requires proper information about the project.

Such information is typically obtained by the management process from the development process. Consequently, the implementation of a development process model should ensure that each step in the development process produces information that the management process needs for that step.

That is, the development process provides the information the management process needs. However, interpretation of the information is part of monitoring and control. Whereas monitoring and control last the entire duration of the project, the last phase of the management process—termination analysis—is performed when the development process is over. The basic reason for performing termi- nation analysis is to provide information about the development process and learn from the project in order to improve the process.

This phase is also of- ten called postmortem analysis. In iterative development, this analysis can be done after each iteration to provide feedback to improve the execution of fur- ther iterations. We will not discuss it further in the book; for an example of a postmortem report the reader is referred to [57]. The temporal relationship between the management process and the devel- opment process is shown in Figure 2. This is an idealized relationship show- ing that planning is done before development begins, and termination analysis is done after development is over.

As the figure shows, during the development, from the various phases of the development process, quantitative information flows to the monitoring and control phase of the management process, which uses the information to exert control on the development process. We will in a later chapter discuss in detail the project planning phase. As a plan also includes planning for monitoring, we will not discuss the monitoring separately but discuss it as part of the planning activity.

Due to this, processes form the heart of software engineering. A process model is a general process specification which has been found to be best suited for some situations. There are many different process models, each being well suited for some type of problems. It has been very widely used, and is suit- able for well-understood problems. This is useful for projects where requirements are not clear.

A phase may itself be done iteratively. The subprocesses of requirements, de- sign, coding, testing, etc. RUP is a flexible frame- work which can allow a project to follow a traditional waterfall if it wants to, or allow prototyping, if it so wishes. There is a committed team for each stage of an iteration. The different iterations are then executed in a pipelined manner, with each dedicated team working on its stage but for different iterations. As multiple iterations are concurrently active, this model reduces the average completion time of each iteration and hence is useful in situations where short cycle time is highly desirable.

In extreme programming XP approach, a project starts with short user stories, details of which are obtained in the iteration in which they are implemented. In an iteration, development is done by programmer-pairs, following the practices of test- driven development, frequent integration, and having simple designs which are refactored when needed. Much of project management revolves around the project plan, which is produced during the planning phase.

What is the relationship between a process model, process specification, and process for a project? What are the key outputs during an iteration in a project following an iterative development model? Which of the development process models discussed in this chapter would you employ for the following projects? Software Processes a A simple data processing project. The user interface and user-friendliness are extremely important.

A project uses the timeboxing process model with three stages in each time box as discussed in the chapter , but with unequal length. Suppose the requirement specification stage takes 2 weeks with a team of 2 people, the build stage takes 3 weeks with a team of 4 people, and deployment takes 1 week with a team of 2 people. Design the process for this project that maximizes resource utilization. Assume that each resource can do any task.

Hint: Exploit the fact that the sum of durations of the first and the third stage is equal to the duration of the second stage. What effect is the project monitoring activity likely to have on the development process?

Note that in software requirements we are dealing with the requirements of the proposed system, that is, the capabilities that the system, which is yet to be developed, should have.

As we have seen, all development models require requirements to be speci- fied. Approaches like agile require only high-level requirements to be specified in written form—detailed requirements are elicited through interaction with the customer in the iteration the requirement is to be implemented and di- rectly reflected in software.

Other approaches prefer that the requirements are specified precisely. In such situations, the goal of the requirements activity is to produce the Software Requirements Specification SRS that describes what the proposed software should do without describing how the software will do it.

Software Requirements Analysis and Specification — The use case approach for analyzing and specifying functional requirements, and how use cases can be developed. The software system itself is created by some developers. Finally, the completed system will be used by the end users. Thus, there are three major parties interested in a new system: the client, the developer, and the users. Somehow the requirements for the system that will satisfy the needs of the clients and the concerns of the users have to be communicated to the developer.

This causes a communication gap between the parties involved in the de- velopment project. A basic purpose of the SRS is to bridge this communication gap so they have a shared vision of the software being built.

Hence, one of the main advantages of a good SRS is: — An SRS establishes the basis for agreement between the client and the sup- plier on what the software product will do. This basis for agreement is frequently formalized into a legal contract between the client or the customer and the developer the supplier.

So, through SRS, the client clearly describes what it expects from the supplier, and the developer clearly understands what capabilities to build in the software. A related, but important, advantage is: — An SRS provides a reference for validation of the final product. That is, the SRS helps the client determine if the software meets the require- ments.

Without a proper SRS, there is no way a client can determine if the software being delivered is what was ordered, and there is no way the developer can convince the client that all the requirements have been fulfilled.

Providing the basis of agreement and validation should be strong enough reasons for both the client and the developer to do a thorough and rigorous job of requirement understanding and specification, but there are other very practical and pressing reasons for having a good SRS.

Clearly, if we want a high-quality end product that has few errors, we must begin with a high-quality SRS. In other words, we can conclude that: — A high-quality SRS is a prerequisite to high-quality software. Finally, the quality of SRS has an impact on cost and schedule of the project. We know that errors can exist in the SRS. It is also known that the cost of fixing an error increases almost exponentially as time progresses [10, 12].

Hence, by improving the quality of requirements, we can have a huge savings in the future by having fewer expensive defect removals. In other words, — A high-quality SRS reduces the development cost. The requirements process typically consists of three basic tasks: problem or requirement analysis, requirements specification, and requirements validation.

The basic purpose of this activity is to obtain a thorough under- standing of what the software needs to provide. Frequently, during analysis, the analyst will have a series of meetings with the clients and end users. In the early meetings, the clients and end users will explain to the analyst about their work, their environment, and their needs as they perceive them. Any documents de- scribing the work or the organization may be given, along with outputs of the existing methods of performing the tasks.

In these early meetings, the analyst is basically the listener, absorbing the information provided. Once the analyst understands the system to some extent, he uses the next few meetings to seek clarifications of the parts he does not understand. He may document the infor- mation or build some models, and he may do some brainstorming or thinking about what the system should do. In the final few meetings, the analyst essen- tially explains to the client what he understands the system should do and uses the meetings as a means of verifying if what he proposes the system should do is indeed consistent with the objectives of the clients.

Software Requirements Analysis and Specification The understanding obtained by problem analysis forms the basis of require- ments specification, in which the focus is on clearly specifying the requirements in a document. Issues such as representation, specification languages, and tools are addressed during this activity. As analysis produces large amounts of in- formation and knowledge with possible redundancies, properly organizing and describing the requirements is an important goal of this activity.

Requirements validation focuses on ensuring that what have been specified in the SRS are indeed all the requirements of the software and making sure that the SRS is of good quality. The requirements process terminates with the production of the validated SRS. We will discuss this more later in the chapter.

Figure 3. It should be pointed out that the requirements process is not a linear se- quence of these three activities and there is considerable overlap and feedback between these activities. The overall requirement process is shown in Figure 3. As shown in the figure, from the specification activity we may go back to the analysis activity. This happens as frequently some parts of the problem are analyzed and then specified before other parts are analyzed and speci- fied.

Furthermore, the process of specification frequently shows shortcomings in the knowledge of the problem, thereby necessitating further analysis. Once the specification is done, it goes through the validation activity. As analysis precedes specification, the first question that arises is: If formal modeling is done during analysis, why are the outputs of modeling not treated as an SRS? The main reason is that modeling generally focuses on the problem structure, not its external behavior. Consequently, things like user interfaces are rarely modeled, whereas they fre- quently form a major component of the SRS.

Similarly, performance constraints, design constraints, standards compliance, recovery, etc. It should therefore be clear that the outputs of a model cannot form a desirable SRS. The transition from analysis to specification should also not be expected to be straightforward, even if some formal modeling is used during analysis.

A good SRS needs to specify many things, some of which are not satisfactorily handled during analysis. Essentially, what passes from requirements analysis activity to the specification activity is the knowledge acquired about the sys- tem. The modeling is essentially a tool to help obtain a thorough and com- plete knowledge about the proposed system. The SRS is written based on the knowledge acquired during analysis. As converting knowledge into a structured document is not straightforward, specification itself is a major task, which is relatively independent.

Some of the desirable charac- teristics of an SRS are [53]: 1. Correct 2. Complete 3. Unambiguous 4. Software Requirements Analysis and Specification 5. Consistent 6. It is complete if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. It is unambiguous if and only if every requirement stated has one and only one interpretation.

Requirements are often written in natural language, which is inherently ambiguous. If the requirements are specified in a natural language, the SRS writer has to be especially careful to ensure that there are no ambiguities. An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement.

It is consistent if there is no requirement that conflicts with another. Terminology can cause inconsistencies; for example, different requirements may use different terms to refer to the same object. There may be logical or temporal conflict between requirements that causes inconsistencies. This occurs if the SRS contains two or more requirements whose logical or temporal characteristics cannot be satisfied together by any software system.

For example, suppose a requirement states that an event e is to occur before another event f. But then another set of requirements states directly or indirectly by transitivity that event f should occur before event e. Inconsistencies in an SRS can reflect some major problems.

Generally, all the requirements for software are not of equal importance. Some are critical, others are important but not critical, and there are some which are desirable but not very important. Some provide more value to the users than oth- ers. Stability of a requirement reflects the chances of it changing in the future.

It can be reflected in terms of the expected change volume. This understanding of value each requirement provides is essential for iterative development—selection of requirements for an iteration is based on this evaluation. Of all these characteristics, completeness is perhaps the most important and also the most difficult property to establish.

One of the most common defects in requirements specification is incompleteness. Missing requirements necessitate additions and modifications to the requirements later in the development cycle, which are often expensive to incorporate. Incompleteness is also a major source of disagreement between the client and the supplier.

The pursuit of completeness can lead to specifying details and assumptions that may be commonly understood. For example, specifying in detail what a common operation like add a record means. And specifying these details can result in a large requirements document, which has its own problems including making validation harder.

For example, if the waterfall model is to be followed in the project, it is better to have detailed specifications so the need for changes is minimized. On the other hand, for iterative development, as feedback is possible and opportunity for change is also there, the specification can be less detailed.

And if an agile approach is being followed, then completeness should be sought only for top-level requirements, as details may not be required in written form, and are elicited when the requirement is being implemented. Together the performance and interface requirements and design constraints can be called nonfunctional requirements.

Account Options Sign in. See all customer images. In this new edition two trends are clearly highlighted: Please try again later. The goal of this third edition is to impart to the student knowledge and skills that are needed to successfully execute a project of a few person-months by employing proper practices and techniques. Add all three to Cart. See our Returns Policy. Its emphasis softsare on a case study approach in which a project is developed through the course of the book illustrating the different activities of software development.

An Integrated Approach to Software Engineering. Much of the difficulty stems from the fact that Software Engineering is a very wide field which includes a wide range of topics. The sequence of chapters Showing of 1 reviews. Sold by Manav Books and ships from Amazon Fulfillment. But the outer side of the book is full of dust While engineering deals with issues of engineeribg, design, coding, testing, etc.

Another objective of the book is to lay the foundation for the student for advanced studies in Software Engineering. This textbook provides an introduction to software engineering for undergraduate students of computer science. Computer Graphics, C Version, 2e. I have believed for some time that we often tend to teach too many concepts and topics in an introductory course resulting in shallow knowledge and little insight on application of these concepts.

And Software Engineering is? Goals I believe that an introductory course on Software Engineering should focus on imparting to students the knowledge and skills that are needed to successfully execute a commercial project of a few person-months e?

Its emphasis is on a case study approach in. This item: an integrated approach pankaj jalote software engineering pdf to software engineering by pankaj jalote paperback rs. Software engineering by pankaj jalote 1.

Undergraduate topics in computer science 2. Undergraduate topics in computer science utics delivers high- quality instructional content for under- graduates studying in all areas of computing and information science. It seems that you're in Germany.