郑州大学软件工程Final Exam Study Guide征征版
Make sure you know the meaning of these terms:
1. Extreme Programming (XP)
Extreme Programming (XP) the most widely used agile approach to agile software development.
XP uses an object-oriented approach as its preferred development paradigm(范例，样式)
XP defines four framework activities
1) Planning
?Begins with the creation of a set of stories (also called user stories)
?Each story is written by the customer and is placed on an index card
?The customer assigns a value (i.e. a priority) to the story
?Agile team assesses each story and assigns a cost
?Stories are grouped to for a deliverable increment
? A commitment is made on delivery date
?After the first increment “project velocity” is used to help define subsequent delivery dates for other
increments
2) Design
?Follows the KIS (keep it simple) principle
?Encourage the use of CRC (class-responsibility-collaborator) cards (Chapter 8)
?For difficult design problems, suggests the creation of “spike solutions”—a design prototype
?Encourages “refactoring”—an iterative refinement of the internal program design
?Design occurs both before and after coding commences
3) Coding
?Recommends the construction of a series of unit tests for each of the stories before coding commences
?Encourages “pair programming”
–Mechanism for real-time problem solving and real-time quality assurance
–Keeps the developers focused on the problem at hand
?Needs continuous integration with other portions (stories) of the s/w, which provides a “smoke
testing” environment (Chapter 13)
4) Testing
?Unit tests should be implemented using a framework to make testing automated. This encourages a
regression testing strategy.
?Integration and validation testing can occur on a daily basis
?Acceptance tests, also called customer tests, are specified by the customer and executed to assess
customer visible functionality
?Acceptance tests are derived from user stories
2. Software project management
Effective software project management focuses on four items (in this order)
–The people
?Deals with the cultivation of motivated, highly skilled people
?Consists of the stakeholders, the team leaders, and the software team
–The product
?Product objectives and scope should be established before a project can be planned –The process
?The software process provides the framework from which a comprehensive plan for software development can be established
–The project
?Planning and controlling a software project is done for one primary reason…it is the only known way to manage complexity
?In a 1998 survey, 26% of software projects failed outright, 46% experienced cost and schedule overruns
3. Domain specific architectural models
–Structural models
?Organized collection of components
–Framework models
?Abstract to repeatable architectural patterns
–Dynamic models
?Behavioral (dynamic) aspects of structure
–Process models
?Business or technical process to be built
–Functional models
?Functional hierarchy of the system
4. Verification
Verification refers to the set of tasks that ensure that software correctly implements a specific function Verification: "Are we building the product right?"
5. Fault, Error, Bug
Error: a quality problem found before the software is released to end users
Defect: a quality problem found only after the software has been released to end users
Errors and defects have very different economic, business, psychological and human impact
The general consensus within the software engineering community is that defects and errors, faults, and bugs are synonymous. It is sometimes difficult to make a clear distinction between pre- and post- release.
6. Objects (in Object Oriented Design)
7. Reliability
The amount of time that the software is available for use as indicated by the following subattributes: maturity, fault tolerance, recoverability.
8. Integration testing
There are 2 different strategies for integration testing of OO system:
1) Thread-based testing integrates the set of classes required to respond to one input or event for the system
2)Use-based testing begins the construction of the system by testing those classes (called independent classes) that use very few (if any) of server classes. After the independent classes are tested, the next layer of classes, called dependent classes
3) Cluster testing is one step in the integration testing of OO software, it defines a cluster of collaborating classes (determined by examining the CRC and object-relationship model) is exercised by designing test cases that attempt to uncover errors in the collaborations.
Cluster testing integrates the set of classes required to demonstrate one collaboration
9. Regression testing
Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects
Regression testing helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors
Regression testing may be conducted manually, by re-executing a subset of all test cases or using automated capture/playback tools
10. Black-box testing
Black-box testing, also called behavioral testing, focuses on the functional requirements of the software. Black-box tests are designed to validate functional requirements without regard to the internal workings of a program. Black-box testing techniques focus on the information domain of the software, deriving test cases by partitioning the input and output domain of a program in a manner that provides thorough test coverags.
Black-box testing techniques enable you to derive sets of input conditions that will fully exercise all functional requirements for a program.
Black-box testing is not an alternative to white-box testing techniques. Rather, it is a complementary approach that is likely to uncover a different class of errors than white-box methods.
11. White-box testing
White-box testing, sometimes called glass-box testing, is a test-case design philosophy that uses the control structure described as part of component-level design to derive test cases. White-box tests focus on the program control structure. Test cases are derived to ensure that all statements in the program have been executed at least once during testing and that all logical conditions have been exercised.
Using white-box testing method you can derive test cases that:
1) Guarantee that all independent paths within a module have been exercised at least once
2) Exercise all logical decisions on their true and false sides
3) Execute all loops at their boundaries and within their operational bounds
4) Exercise internal data structures to ensure their validity
12. Fault tolerance (or tolerant)
13. Fault detection
14. Recovery block
15. Waterfall model
The process of the waterfall: Communication—planning—modeling—construction—deployment
When to use the waterfall model:
?Requirements are very well known
?Product definition is stable
?Technology is understood
?New version of an existing product
?Porting an existing product to a new platform.
Strengths:
?Easy to understand, easy to use
?Provides structure to inexperienced staff
?Milestones are well understood
?Sets requirements stability
?Good for management control (plan, staff, track)
?Works well when quality is more important than cost or schedule
Deficiencies:
?All requirements must be known upfront
?Deliverables created for each phase are considered frozen – inhibits flexibility
?Can give a false impression of progress
?Does not reflect problem-solving nature of software development – iterations of phases
?Integration is one big bang at the end
?Little opportunity for customer to preview the system (until it may be too late)
16. Software prototyping
The prototyping paradigm assists you and other stakeholders to better understand what is to be built when requirements are fuzzy.
Prototyping can be used as a stand-alone process model, it is more commonly used as a technique that can be implemented within the context of any one of the process models noted in this chapter.
The prototyping paradigm begins with communication.
The prototype serves as mechanism for identifying software requirements
Although problems can occur, prototyping can be an effective paradigm for software engineering. Evolutionary models, such as prototyping and the spiral model produce incremental work products quickly.
17. Safety critical systems
18. Systems engineering
19. Software quality assurance（SQA）
20. Software maintenance
21. Software configuration management (SCM)
Software configuration management is an umbrella activity that is applied throughout the software process. Because change can occur at any time, SCM activities are developed to:
Identify change
Control change
Ensure that change is being properly implemented
Report changes to others who may have an interest
22. Walk-through, FTR (formal technical review)
23. Software life cycle
24. Validation
Validation refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements.
Validation: "Are we building the right product?"
25. Partition testing
Reduces the number of test cases required to test a class in much the same way as equivalence partitioning for conventional software
?state-based partitioning
?categorize and test operations based on their ability to change the state of a class
?attribute-based partitioning
?categorize and test operations based on the attributes that they use
?category-based partitioning
?categorize and test operations based on the generic function each performs
26. Fault avoidance
27. Requirements analysis
Requirement analysis results in the specification of software’s operational characteristics, indicates software’s interface with other system elements, and establishes constraints that software must meet.
The requirements modeling action results in one or more of the following types of models: ?Scenario-based models of requirements from the point of view of var ious system “actors”.
?Data models that depict the information domain for the problem.
?Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve system requirements.
?Flow-oriented models that represent the functional elements of the system and how they transform data as it move through the system.
?Behavioral models that depict how the software behaves as a consequence of external “events”.
28. Software engineering
29. (Graphical user interfaces) GUI design principles