研一"软件工程与软件过程"课程书籍——SEPA(Software Engineering: A Practitioner’s Approach)笔记。
PREFACE
CHAPTER 1: Software And Software Engineering
KEY CONCEPTS:
application domains
characteristics of software
framework activities
legacy software
practice
principles
software engineering
umbrella activities
WebApps
1.1 The Nature Of Software
KEY POINT: Software is both a product and a vehicle that delivers a product.
1.1.1 Defining Software
Software is a logical rather than a physical system element.
-
Software is developed or engineered; it is not manufactured in the classical sense.
-
Software doesn’t “wear out”.
KEY POINT: Software doesn’t wear out, but it does deteriorate.
-
Although the industry is moving toward component-based construction, most software continues to be custom built.
1.1.2 Software Application Domains
seven broad categories of computer software:
System software
-
process complex, but determinate, information structures.
e.g., compilers, editors, and file management utilities
-
process largely indeterminate data.
e.g., operating system components, drivers, networking software, telecommunications processors
Software is determinate if the order and timing of inputs, processing, and outputs is predictable.
Software is indeterminate if the order and timing of inputs, processing and outputs cannot be predicted in advance.
Application software
e.g., point-of-sale transaction processing, real-time manufacutring process control.
Engineering/scientific software
Embedded software
Product-line software
Web applications(WebApps)
Artificial intelligence software
Vote: “You can’t always predict, but you can always prepare.”
1.1.3 Legacy Software
ADVICE: Every software engineer must recognize that change is natural. Don’t try to fight it.
1.2 The Unique Nature Of WebApps
The following attributes are encountered in the vast majority of WebApps.
Network intensiveness.
Concurrency.
Unpredictable load.
Performance.
Availability.
Data driven.
Content sensitive.
Immediacy.
Security.
Aesthetic.
1.3 Software Engineering
KEY POINTS:
Understand the problem before you build a system.
Design is a pivotal software engineering activity.
Both quality and maintainability are an outgrowth of good design.
Definitions of software engineering:
IEEE:
Software Engineering: (1) The applications of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).
KEY POINT:
Software engineering encompasses a process, methods for managing and engineering software and tools.
Software engineering is a layered technology.
1.4 The Software Process
A generic process framework for software engineering:
Communication.
Planning.
Modeling.
Construction.
Deployment.
Umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrealla activities include:
Software project tracking and control
Risk Management
Software quality assurance
Technical reviews
Measurement
Software configuration management
Reusability management
Work product preparation and production
KEY POINT: Software process adaptation is essential for project success.
1.5 Software Engineering Practice
1.5.1 The Essence Of Practice
- Understand the problem (communication and analysis).
- Plan a solution (modeling and software design).
- Carry out the plan (code generation).
- Examine the result for accuracy (testing and quality assurance).
1.5.2 General Principles
The First Principle: The reason it all exists
A software system exists for one reason: to provide value to its users.
The Second Principle: KISS(Keep it simple, stupid!)
The Third Principle: Maintain the Vision
The Fourth Principle: What you produce, others will consume
The Fifth Principle: Be Open to the Future
The Sixth Principle: Plan Ahead for Reuse
The Seventh Principle: Think!
1.6 Software Myths
Management myths.
Customer myths.
Practitioner’s myths.
1.7 How it all starts
1.8 Summary
万事开头难，但第一章也读太长时间了😭。
PART One THE SOFTWARE PROCESS
CHAPTER 2: Process Models
KEY CONCEPTS:
component-based development
concurrent models
evolutionary process models
formal methods model
generic process model
incremental process models
personal software process
prescriptive process models
process patterns
task set
team software process
Unified Process
2.1 A generic process Model
2.1.1 Defining a Framework Activity
2.1.2 Identifying a Task Set
Task Set
A task set defines the actual work to be done to accomplish the objectives of a software engineering action. For example, elicitation (more commonly called “requirements gathering”) is an important software engineering action that occurs during the communication activity. The goal of requirements gathering is to understand what various stakeholders want from the software that is to be built.
2.1.3 Process Patterns
“The repetition of patterns is quite a different thing than the repetition of parts. Indeed, the different parts will be unique because the patterns are the same.”
Patterns can be defined at any level of abstraction.
a template for describing a process pattern:
-
Pattern Name.
-
Forces.
-
Type.
- Stage pattern
- Task pattern
- Phase pattern
- Initial context.
- Problem.
- Solution.
- Resulting Context.
- Related Patterns.
- Known Uses and Examples.
2.2 Process Assessment and improvement
2.3 Prescriptive Process Models
KEY POINT
Prescriptive process models define a prescribed set of process elements and a predictable process work flow.
2.3.1 The Waterfall Model
The waterfall model sometimes called the classic life cycle, suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software.
Communication——Planning——Model —— Construction——Deployment
project initiation, requirements gathering——estimating, scheduling, tracking——analysis, design——code, test——delivery, support
A variation in the representation of the waterfall model is called the V-model. The V-model provides a way of visualizing how verification and validation actions are applied to earlier engineering work.
2.3.2 Incremental Process Models
The incremental model delivers a series of releases, called increments, that provide progressively more functionality for the customers as each increment is delivered.
2.3.3 Evolutionary Process Models
Evolutionary process models produce an increasingly more complete version of the software with each iteration.
Two common evolutionary process models:
-
Prototyping.
Advice: When your customer has a legitimate need, but is clueless about the details, develop a prototype as a first step.
Advice: Resist pressure to extend a rough prototype into a production product. Quality almost always suffers as a result.
-
The Spiral Model.
KEY POINT: The spiral model can be adapted to apply throughout the entire life cycle of an application, from concept development to maintenance.
Advice: If your management demands fixed-budget development (generally a bad idea), the spiral can be a problem. As each circuit is completed, project cost is revisited and revised.
2.3.4 Concurrent Models
Advice: The concurrent model is often more appropriate for product engineering projects where different engineering teams are involved.