7 1 INDEX 8 8 9
Software Engineering Seventh Edition: A Practitioner's Approach is intended to serve as a guide to a mature engineering discipline. Seventh edition. The 32 chapters of the seventh edition have been reorganized into five parts.
P REFACE
Moreover, debates and controversies about the true nature of the software engineering approach continue. The content of the seventh edition of Software Engineering: A Practitioner's Approach has been shaped by industry professionals, university professors, and students who have used previous editions of the book and taken the time to convey their suggestions, criticisms, and ideas.
S OFTWARE AND
The old view of software - you buy it, you own it, and it's your job to manage it - is coming to an end. It will be delivered via the Internet and will appear as if it resides on each user's computing device.
S OFTWARE E NGINEERING
The problem is that we have to do it 'quickly' because the market has accelerated in all areas of application." The problem is that we have to convince another generation of technicians that it's true!"
Defining Software
In theory, the error rate curve for software should therefore take the form of the "idealized curve" shown in Figure 1.2. Software engineering methods strive to reduce the size of the peaks and the slope of the actual curve in Figure 1.2.
Software Application Domains
Open World Computing - The rapid growth of wireless networking may soon lead to true pervasive, distributed computing. Netsourcing - The World Wide Web is fast becoming a computing engine as well as a content provider.
Legacy Software
The network may enable worldwide access and communication (ie the Internet) or more limited access and communication (ie a corporate intranet). Although immediacy—the imperative to get software to market quickly—is a hallmark of many application domains, WebApps often exhibit a time-to-market that can be a matter of a few days or weeks.7 Security.
Tools
Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. In the context of software engineering, a process is not a rigid prescription for how to build computer software.
A quality focusMethods
When tools are integrated so that information created by one tool can be used by another, a system for supporting software development called computer-aided software engineering is established. Anactivity strives to achieve a broad goal (eg communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering must be applied.
ProcessFIGURE1.3
The Essence of Practice
Who has a stake in solving the problem? That is, who are the stakeholders. Does the solution match the plan? Is source code traceable to the design model.
General Principles
In recent years, many books have been published that deal with the software process and software engineering. There are many different sources of information on software engineering and the software process available on the Internet.
T HE S OFTWARE P ROCESS
The process is a dialogue in which the knowledge to become software is brought together and embodied in the software. Indeed, the production of computer software is an iterative process of social learning, and the result, something Baetjer would call "software capital," is the embodiment of knowledge collected, distilled, and organized during the course of the process.
2 P M ROCESS ODELS
Defining a Framework Activity
Therefore, you face 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 sponsoring the project. work tasks work products quality assurance points project points. work tasks work products quality assurance points project points. work tasks work products quality assurance points project points. work tasks work products quality assurance points project points. Each of these software engineering activities would have many work tasks and a number of separate work products.
Identifying a Task Set
Process Patterns
Initial context. The following conditions must be met before the initiation of this pattern: (1) stakeholders have been identified; (2) a mode of communication is established between stakeholders and the software team. 3) the overall software problem to be solved has been identified by stakeholders; (4) an initial understanding of the project scope, basic business requirements and project constraints has been developed. However, software engineering and the product it produces remain on the "edge of chaos".
The Waterfall Model
A working version of the program(s) will not be available until late in the project period. In an interesting analysis of real projects, Bradac [Bra94] found that the linear nature of the classical life cycle leads to "blocking conditions" in which some project team members must wait for other members of the team to complete dependent tasks.
Incremental Process Models
The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. Early increments are stripped down versions of the final product, but they do provide capability that serves the user and also provides a platform for user evaluation.8.
Evolutionary Process Models
A prototype can serve as a "first system." The one Brooks recommends you throw away. Unlike other process models that end when the software is delivered, the spiral model can be adapted for use throughout the life of the computer software.
Concurrent Models
Concurrent modeling defines a sequence of events that will cause state-to-state transitions for each of the software engineering activities, actions, or tasks. This generates the event analysis model correction, which triggers the requirements analysis action from the 'done' state to the 'pending changes' state.
A Final Word on Evolutionary Processes
Rather than limiting software engineering activities, actions, and tasks to a series of events, it defines a process network. Every activity, action, or task on the network exists simultaneously with other activities, actions, or tasks.
Daniel Hunt
- Component-Based Development
- The Formal Methods Model
- Aspect-Oriented Software Development
- A Brief History
- Phases of the Unified Process 19
- Personal Software Process (PSP)
- Team Software Process (TSP)
Process patterns can be used to solve common problems encountered as part of the software process. Glass (Facts and Fallacies of Software Engineering, Prentice-Hall, 2002) offers an unvarnished, pragmatic view of the software engineering process.
A GILE D EVELOPMENT
Agility Principles
Although agile processes embrace change, it is still important to examine the reasons for the change. Business software is important, but remember that it must also exhibit a number of qualities, including reliability, usability and maintainability.
The Politics of Agile Development
Not every agile process model applies these twelve principles equally, and some models choose to ignore (or at least downplay) the importance of one or more of the principles. However, the principles define an agile spirit that is maintained in each of the process models presented in this chapter.
Human Factors
In the context of agile development, self-organization implies three things: (1) the agile team organizes itself for the work to be done, (2) the team organizes the process to best accommodate its local environment, (3) the team organizes the work schedule to achieve the best delivery of the software increment. Ken Schwaber [Sch02] addresses these issues when he writes: “The team chooses how much work it believes it can accomplish within the iteration, and the team commits to the work.
XP Values
As each class is developed, the team develops a unit test to perform each operation according to its specified functionality. As they successfully deliver software increments, the team develops a growing respect for the XP process.
The XP Process
CRC cards are the only design work product produced as part of the XP process. Essentially, when you refactor, you're improving the design of the code after it's written.
Industrial XP
An IXP project requires measurable criteria to assess the state of the project and the progress made to date. Because learning is a vital part of continuous process improvement, XP team members are encouraged (and possibly incentivized) to learn new methods and techniques that can lead to a higher quality product.
The XP Debate
As a result, the scope of the project may change and earlier work may need to be done. For example, I like the concept of pair programming and the idea that stakeholders should be part of a team.
Adaptive Software Development (ASD)
It is important to note that all agile process models are consistent (to a greater or lesser extent) with the Manifesto for Agile Software Development and the principles outlined in section 3.3.1. As ASD team members begin to develop the components that are part of the adaptive cycle, the emphasis is on both "learning" and progress toward a completed cycle.
Scrum
Adaptive cycle planning uses project initiation information (the customer's mission, project constraints (for example, delivery dates or user descriptions), and baseline requirements) to define the set of release cycles (software increments) required for the project. Demos: Deliver the software increment to the customer so that the functionality implemented can be demonstrated and evaluated by the customer.
Dynamic Systems Development Method (DSDM)
DSDM can be combined with XP (Section 3.4) to provide a combination approach that defines a solid process model (the DSDM life cycle) with the nuts and bolts practices (XP) required to build software increments. In addition, the ASD concepts of collaboration and self-organizing teams can be adapted to a combined process model.
Crystal
Design and build iteration - reviews the prototypes built during the functional model iteration to ensure that each one is designed in a way that will enable it to provide operational business value to end users. In either case, the DSDM development work continues by turning to the activity of iterating the functional model.
Feature Driven Development (FDD)
FDD provides a greater emphasis on guidelines and project management techniques than many other agile methods. If deadline pressure is high, it is critical to determine whether software (feature) increments are properly planned.
Lean Software Development (LSD)
For example: Making a product sale is a set of features that would include the features mentioned earlier and others. The FDD approach defines five "collaborative" framework activities [Coa99] (in FDD these are called "processes") as shown in Figure 3.5.
Agile Modeling (AM)
AM suggests that to provide the necessary insight, each model should present a different aspect of the system and only those models that provide value to the intended audience should be used. Much of the software engineering community has adopted the Unified Modeling Language (UML)16 as the preferred method for representing analysis and design models.
Agile Unified Process (AUP)
Although AUP has historical and technical ties to the Unified Modeling Language, it is important to note that UML modeling can be used in conjunction with any of the agile process models described in Section 3.5. Cockburn (Crystal Clear, Addison-Wesley, 2005) presents an excellent overview of the Crystal family of processes.
M ODELING
I should be concerned; in another part of my being—late, maybe when we get out of this room full of computers—I'll be very interested in why and for whom and to what end I'm writing software.
4 P G RINCIPLES UIDE P RACTICE T HAT
Principles That Guide Process
Every aspect of the work you do should focus on economics: keep your technical approach as simple as possible, keep the work products you produce as concise as possible, and make local decisions wherever possible. The end condition for each process activity, action and task should focus on the quality of the work product produced.
Principles That Guide Practice
Every work product produced as part of software engineering practice will be transferred to someone else. 3 PR I N C I P L E S TH AT GU I D E E CH FR A M E W O R C T I V I T In the sections that follow, I consider principles that have a strong influence on the success of each generic framework activity defined as part of the software process.
Communication Principles
If you are responsible for holding a meeting, prepare an agenda before the meeting. Collaboration and consensus occur when the collective knowledge of members of the team is used.
Planning Principles
Others are “traditionalists,” who argue that the plan provides an effective roadmap and that the more detailed it is, the less likely the team is to get lost. If pair programming is used during construction (chapter 3), this must be explicitly defined in the plan.
Modeling Principles
It starts by imagining the totality of the thing to be built (eg a three-dimensional rendering of the house) and slowly refines the thing to guide the construction of every detail (eg the plumbing layout). However, it should emphasize ease of use in every case. The user interface is the visible manifestation of the software.
Components should be loosely coupled to one another and to the external environment. Coupling is achieved in many ways—
- Construction Principles
- Deployment Principles
If the testing is successfully performed (according to the objectives previously stated), it will detect bugs in the software. Modeling principles serve as the foundation for the methods and notations used to create software representations.
U NDERSTANDING
R EQUIREMENTS
Introduction 1 Purpose
Overall Description 1 Product Perspective
External Interface Requirements 1 User Interfaces
Other Nonfunctional Requirements 1 Performance Requirements
- Identifying Stakeholders
- Recognizing Multiple Viewpoints
- Working toward Collaboration
- Asking the First Questions
- Collaborative Requirements Gathering
- Quality Function Deployment
- Usage Scenarios
- Elicitation Work Products
- Elements of the Requirements Model
- Analysis Patterns
Facilitator (pointing to whiteboard): So that's the current list of objects and services for the home security function. And the stick figures represent actors—. the people or things that interact with the system as described by the use case. oh, I'm using the labeled square to represent an actor that isn't a person.
Weigers (Software Requirements, Microsoft Press, 1999) and Leffingwell and his colleagues (Managing Software Requirements: A Use Case Approach, 2d ed., Addison-Wesley, 2003) present a useful collection of requirements best practices and provide pragmatic guidelines for the most aspects of the requirements engineering process. Use case modeling is often the driver for the creation of all other aspects of the analysis model.
6 R EQUIREMENTS M ODELING : S CENARIOS ,INFORMATION, ANDANALYSISCLASSES
Overall Objectives and Philosophy
The customer may be unsure of what exactly is required for certain aspects of the system. 3 Alternatively, the software team may choose to create a prototype (Chapter 2) in an effort to better understand the requirements for the system.
Analysis Rules of Thumb
It is important to note that all elements of the requirements model will be directly traceable to parts of the design model. Some design always occurs as part of analysis, and some analysis will be performed during design.
Domain Analysis
Domain analysis does not look at a specific application, but rather at the domain in which the application resides. 4 A complementary view of domain analysis “involves modeling the domain so that software engineers and other stakeholders can better learn about it.
![Figure 6.2 [Ara89] illustrates key inputs and outputs for the domain analysis process](https://thumb-ap.123doks.com/thumbv2/filepdfnet/10987611.0/181.904.115.737.138.297/figure-ara89-illustrates-inputs-outputs-domain-analysis-process.webp)
Requirements Modeling Approaches
Each element of the requirements model (Figure 6.3) presents the problem from a different perspective. Behavioral elements describe how external events change the state of the system or the classes that reside within it.
Creating a Preliminary Use Case
I want to have access to the surveillance function either through the computer or through the Internet. However, I want to be able to display camera footage on a computer and control the pan and zoom for a specific camera.
Refining a Preliminary Use Case
Each of the situations described in the preceding paragraphs is characterized as an exception use case. In some cases, an exception will trigger the development of another use case (to handle the flagged condition).
Writing a Formal Use Case
The homeowner selects 'View Thumbnail Photos for All Cameras' - see View Thumbnail Photos for All Cameras use case. Like any other form of written description, a use case is only as good as the author(s).
Developing an Activity Diagram
A use case focuses on functional and behavioral requirements and is generally inappropriate for non-functional requirements. In situations where the requirements model must have significant detail and precision (e.g. safety-critical systems), a use case may not be sufficient.
Swimlane Diagrams
The activity diagram notes two prompts that are the responsibility of the interface—“ask for reentry” and “ask for another view.”. A software engineer or analyst defines all data objects that are processed within the system, the relationships between the data objects and other information relevant to the relationships.
Data Objects
The entity-relationship diagram (ERD) addresses these issues and represents all data objects that are entered, stored, transformed, and produced within an application.
Data Attributes
The set of attributes appropriate for a given data object is determined by understanding the context of the problem. When discussing data objects, a common question arises: Is a data object the same as an object-oriented class11.
Relationships
Furthermore, the definition of classes implies an overarching infrastructure that is part of the object-oriented software engineering approach. In some variations of the ERD, the connecting line contains a diamond that is labeled with the relationship.
Identifying Analysis Classes
Retain information. The potential class will only be useful during analysis if information about it needs to be remembered for the system to function. Necessary services. The potential class must have a set of identifiable operations that can change the value of its properties in some way.
Specifying Attributes
Defining Operations
