Software engineering by summer ville pdf free download

Complete restructuring to make it easier to use the book in teaching software engineering. The book now has four rather than eight parts and each part may be used on its own or in combination with other parts as the basis of a software engineering course.

The four parts are an introduction to software engineering, dependability and security, advanced software engineering, and software engineering management. Several topics from previous editions are presented more concisely in a single chapter, with extra material moved onto the Web. Additional web chapters, based on chapters from previous editions that I have not included here, are available on the Web.

I have updated and revised the content in all chapters. I have added new chapters on agile software development and embedded systems. A new case study on a patient record system for patients who are undergoing treatment for mental health problems has been used in several chapters.

I have designed the book so that it can be used in three different types of softwareengineering courses:. General introductory courses in software engineering The first part of the book has been designed explicitly to support a one-semester course in introductory software engineering.

An initial activity where you understand the function of the system and set out broad requirements for what the system should do. There is a fundamental difference between the user and the system requirements that mean they should be considered separately. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract.

They may also be used in situations where development is outsourced and the development team need a complete specification of what should be developed. The system requirements are developed after user requirements have been established.

Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence of changes to the business, business goals and business policies. Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful.

Examples of process activities that support change are: 1. Recording of requirements rationale so that the reason why a requirement is included is known. This helps with future change. Design modeling where the design model documents the structure of the software.

Code refactoring that improves code quality and so makes it more amenable to change. Advantages of process improvement frameworks 1. The approach provides a means of measuring the state of a process and a structured approach to introducing process improvements.

It is useful as a way of building on the experience of others in process improvement. Disadvantages of process improvement frameworks 1. Like any measurement system, there is a tendency to introduce improvements to improve the measured rating rather than concentrate on improvements that meet real business goals.

The maturity model approach is expensive and bureaucratic to operate. It is not really suitable for organisations that use agile development. The principles underlying agile development are: 1. Individual and interactions over processes and tools. By taking advantages of individual skills and ability and by ensuring that the development team know what each other are doing, the overheads of formal communication and process assurance are avoided.

This means that the team can focus on the development of working software. Working software over comprehensive documentation. This contributes to accelerated development because time is not spent developing, checking and managing documentation. Customer collaboration over contract negotiation. This allows useful functionality to be developed and delivered earlier than would be possible if contracts were required. Responding to change over following a plan. Agile developers argue rightly that being responsive to change is more effective than following a plan-based process because change is inevitable whatever process is used.

There is significant overhead in changing plans to accommodate change and the inflexibility of a plan means that work may be done that is later discarded. Discuss the advantages and disadvantages of this approach to requirements description.

Advantages of stories: 1. They represent real situations that commonly arise so the system will support the most common user operations. It is easy for users to understand and critique the stories. They represent increments of functionality — implementing a story delivers some value to the user.

Disadvantages of stories 1. They are liable to be incomplete and their informal nature makes this incompleteness difficult to detect. They focus on functional requirements rather than non-functional requirements. Representing cross-cutting system requirements such as performance and reliability is impossible when stories are used. The relationship between the system architecture and the user stories is unclear so architectural design is difficult.

Your comparison should be based on the effectiveness of each approach for planning the allocation of people to projects, estimating the cost of projects, maintaining team cohesion and managing changes in project team membership.

Planning allocation of people to projects Scrum Scrum handles people allocation informally. Alternatively, the tasks can be allocated by the Scrum master. There is no formal mechanism in Scrum for planning for project members with very specific expertise to be temporarily allocated to a team.

This need must be identified by the Scrum master and he or she has to discuss how the expertise can be made available. The expertise required for each part can then be identified and the allocation of people to projects planned on that basis. Estimating project costs Scrum Project costs are estimated based on the required delivery date for the software and people working in the Scrum team. The functionality of the system is adjusted so that some working system will always be delivered for the original cost estimation.

Of course, this may not be adequate for the customer and they have to become involved in rescheduling the delivery of the system. Plan-based development Project costs are based on an analysis of the functionality specified in the requirements document as well as the non-functional requirements of the system.

They may be adjusted to reflect team size and delivery schedule. It is normal for costs to be underestimated and the final project to cost much more than originally estimated.

An average cost for team members is assumed. Maintaining team cohesion Scrum Team member meet daily either face to face or electronically. Extensive informal discussions and communications are encouraged. Team members negotiate work to be done from the project backlog. This all leads to a shared feeling of product ownership and a very cohesive team. Plan-based development Team cohesion is the responsibility of the project manager and he or she has to take explicit actions to encourage this.

The general approach relies on formal meetings that are relatively infrequent and this does not lead to the development of a cohesive team.

Managing changes in project team membership Scrum This is a topic that is rarely discussed in Scrum but is a fundamental problem because so much information is informal and reliant on people remembering what has been agreed.

When someone leaves, it can be very difficult to bring a replacement team member up to speed, especially if very little project documentation is available. Therefore, if a team member leaves, then a new team member with comparable expertise can read what has been done and, after understanding this, should be able to serve as a replacement. Project planning is often essential when developing software with larger teams to a ensure that the right people are available when they are needed to be involved in the development process and b ensure that the delivery schedules of different parts of the system developed by different teams are aligned.

Quizzes for Software Engineering, 9th Edition. Download Resources. Reference Foundation. Roger S. Bourque and R. Fairley, eds.