Chapter 1: Software built views and quality objectives 1.2 software build quality objectives
1.2 software to build quality objectives
outline
quality attributes of the software system - trade-off between quality factors - external and internal quality factors - important factors external quality five key quality goals to build the software - easy to understand: elegant and beautiful code / intelligibility - readily available change: maintainability and adaptability - low development costs: designed for / reuse: reusability - prevent errors: robustness - efficient operation: performance summary
1.2 software build quality objectives
aim of this seminar
understand the quality factors in building software concern; understand the consequences can not achieve quality objectives; understanding of research in this course of each quality factor method.
Software build
a software system quality attributes
1.2 software build quality target external and internal quality factors
External quality factors: speed or ease of use quality, which the user can detect the presence or absence of the software product (and not only the actual end product human interaction, as well as a contract to purchase the software or human) its development). be applied to other quality software products, such as modularity or readability, internal factors are only able to access the actual text of computer software professionals to perceive.
Finally, only external factors are important. But the key to these external factors, internal factors is: To allow users to enjoy the visible qualities, designers and implementers must use techniques to ensure internal quality hidden.
External factors can affect the quality of the user.
Internal factors can affect the quality of the software itself and its developers.
External Quality by internal quality.
Software build
(1) External quality factors
1.2 software build quality objectives
External 1: Correct
correctness of software products is the ability to perform precise tasks of its specification as defined. correctness is the most important quality. ensure the correctness of the method: conditional. - A serious software system involves many areas, by treating all components and attributes in a level to ensure its accuracy is impossible. In contrast, a hierarchical method is necessary, each layer depends on the lower layers. - we should ensure that the library is right, individually and ensure that the application is correct, assuming library Yes.
⇒ reusability (reusable design, Chapter 5)
assume that the software system is a hierarchical development.
Each layer to ensure its accuracy, it is assumed that the lower layer is also true.
Quality Objectives 1.2 software to build
external 1: Correct
ensure the correctness of the method: test and debug.
typing and assertions such as defensive programming, designed to help build right from the start of the software, rather than its commissioning correctness .⇒Robustness (Chapter 7)
formal method: "Check," "guarantee" and " to ensure that "- a formal program specification and verification of mathematical techniques ⇒ graduate programs
target quality 1.2 software to build
external 2: sound
robustness is the ability of a software system to make an appropriate response to abnormal situations. - Robust Supplement correctness. - correctness solved in the case of the behavior of the system covered by their specifications; - robustness characterized happened outside the specification. robustness is to ensure that if this happens, the system will not lead to a catastrophic event; it should generate an appropriate error message, cleanly terminate its execution, or to enter the so-called "graceful degradation" mode.
Quality Objectives 1.2 software to build
external 2: sound
robustness and "anomalies" related, which means that the concept of normal and abnormal conditions is always relative to some norm - exceptions are only cases not covered by specification. - If the expansion of specifications, past unusual situation becomes normal - even if they correspond to user input errors and other events you do not want. - "normal" in this sense does not mean "ideal", but only "program used to design software." - Although at first may seem contradictory, erroneous input should be called normal, but any other method must rely on subjective criteria, and therefore useless.
⇒ exception handling (Chapter 7) External 3: Scalability
Scalability refers to the ease of software products to meet specifications change. scalability problem is the size of the problem. - For small projects, changes are usually not a problem; but as more and more software, it becomes increasingly difficult to adapt to. - a large-scale software systems often its defenders as a huge house of cards, which pull out any one element might cause the entire building to collapse. We need scalability, because there are some human phenomena on the basis of all the software, so fickle. traditional methods do not adequately take into account changes, relying instead on an ideal view of the software life cycle, where the initial analysis stage to freeze the demand, and the rest dedicated to the process of designing and building solutions.
Quality Objectives 1.2 software to build
external 3: Scalability
two principles for improving the scalability is crucial: - Simple design: simple architecture is always easier to adapt to changes than the complex architecture. - Decentralization: the more independent module, the possibility of a simple change affects only a small number of modules or modules of the greater, rather than the entire system changes trigger a chain reaction.
⇒ Chapter 3 (ADT and of OOP) ⇒ Chapter 6 (modularity and adaptability)
target mass 1.2 software to build
the external 4: Reusability
Reusability is the ability of software elements used to build many different applications. demand stems from the reusability of software systems typically observed followed a similar pattern; should be able to take advantage of this commonality, avoid re-solve the problems encountered before. - By capturing such a model, reusable software elements will be applicable to many different development.
⇒ Chapter 5 (designed / reused)
1.2 software to build quality objectives
external 5: Compatibility
compatibility of the software is simple and other elements in the combination. compatibility is very important, because we do not develop software elements in a vacuum: they need to interact with each other. but they are often difficult to interact, because they make conflicting assumptions about the rest of the world. - One example of many is not compatible with various operating systems supported file formats. Only in the case of a file format compatible with the program can be used directly as a result of other inputs.
1.2 software build quality objectives
external 5: Compatibility
Key compatibility homogeneity that design, and to agree on a standardized agreement between communications procedures.
method comprising: - a standardized file format, such as in the Unix system, each text file is just a sequence of characters. - standardized data structure, as in Lisp system, all data is also represented by a binary tree and a program (referred to in the list in Lisp). - standardized user interface, such as various versions of Windows, OS / 2 and MacOS, all tools are dependent on a single paradigm for communication with the user, based on standard components, such as windows, icons, menus, etc. . more general solution is obtained by the standardized access protocol defines all the important entities manipulated by software.
Compatibility is the key to standardization, in particular, it is a standard protocol.
Quality Objectives 1.2 software to build
external 6: Efficiency
efficiency refers to the ability to minimize the software system needs hardware resources such as processor time, memory inside and outside the space occupied by the bandwidth used in the communication device. If the software is not correct, efficiency is not important (recommended a new motto), "Do not worry about how fast it is, unless it is also correct"). Focus on efficiency must be balanced with other goals scalability and reusability; an extreme optimization of the software so specialized that it is not suitable for change and reuse. - weigh algorithm, I / O, memory management between various quality factors
⇒ Chapter 8 (act)
is calculated with the accuracy of abstraction for performance by optimizing embodied
Construction 1.2 software quality target external 7: available portability (portability)
§ portability of software products is transferred to the convenience of various hardware and software environments. portability not only solved the changes in the physical hardware, but also more broadly to address the hardware - software machine, we really programmed machine, including the operating system, window system (if applicable), and other basic tools. External 8: Easy to use
easy-to-use refers to a variety of backgrounds and qualifications of person can easily learn to use the software product and apply it to solve the problem. It also includes easy to install, operate and monitor. how to provide detailed guidance and interpretation for the novice user, without bothering expert users who want to enter the business. One of the key easy to use is a simple structure. A well-designed system, based on a clear, well thought-out structure to build, is often easier to learn and use than the messy system. understand user. The focus of debate is good designer must strive to understand the intended user community system. ⇒ Chapter 10 (GUI)
quality targets 1.2 software to build
an external 9: Function
feature is the range of possibilities provided by the system. Features (usually "feature creep") programming of one unfavorable trend that software developers to add more and more features in an attempt to keep up with the competition, with the consequence that extremely complex, inflexible, take up too much disk space - the problem is easier to add new features may result in the loss of consistency, thus affecting its ease of use. In fact, users complained that the new version of the product does all the "bells and whistles" makes it very complicated. - more difficult to avoid this problem is to focus on features that you forget other quality (overall quality ignored).
Osmond curve
quality objectives 1.2 software to build
an external 9: Function
Osmond recommended (color curves) in enhancing the quality of OO development with the help of technology, maintaining the same level of quality in all aspects of the entire project, but functional . you do not compromise in terms of reliability, scalability: Before you satisfied with the functions have you refused to use the new features. ⇒ Chapter 2 (agility, SCM)
starts a small part of the key features, taking into account all the quality factors.
Gradually add more features in the development process, and to ensure the key functions of the same quality.
Quality Objectives 1.2 software to build
outside 10: Timeliness
timeliness of the software system is the ability to publish or prior to when the user needs. appear too late excellent software products may be completely missed the target.
External quality objectives 1.2 software to build 10 ++: Other quality
verifiability is ready to ease of inspection procedures, in particular, test data, and error tracking and verification procedures in the operational phase and fault detection. Integrity is the software system to protect its various components (programs, data) from the ability to access and unauthorized modification. repair refers to the ability to facilitate the repair of defects. economy is accompanied timeliness, is the system's ability to complete its designated under budget or under.
Software build
(2) internal quality factors
1.2 build software quality goals
Factors internal quality
factors associated with the architecture source code related factors, such as lines of code (LOC), Cyclomatic Complexity the like, such as coupling, cohesion, etc.
readability, intelligibility and clarity size complexity
inside quality factor quality factor is generally used as the external part of the measurement.
Software build
(3) trade-off between quality attributes
tradeoff between 1.2 software build quality objectives quality attributes
How does the introduction of a variety of case integrity protection is obtained, this will inevitably interfere with ease of use? economy seems to function and often fight. optimum efficiency requires perfectly adapted to specific hardware and software environment, which is contrary portability, and fully meet the standards, which promote reusability solve the more general problem than originally given. timeliness pressure may induce us to use the "Rapid Application Development" techniques, the result may not get too much scalability. Trade-off between quality attributes
developers need to be weighed. - In many cases, developers implicitly make these trade-offs, but did not take the time to check the problem involved and the variety of choices available; efficiency is often the dominant factor in silence decisions. - real software engineering approach means that efforts to clearly state the criteria and consciously make a choice. Since the trade-off between quality factors it may be necessary, and therefore one of the prominent factors: correct. - for other issues such as efficiency, I never had any reason to compromise accuracy. - If the software does not perform its functions, the rest is useless.
Key issues 1.2 software to build software to build quality objectives
all the qualities discussed above are important. But in the current software industry, there are four stand out:
- Correctness and robustness: System Reliability • Software • construction • formal specification development process automatically checks • better language mechanisms • Consistency Checker tool
- Scalability and reusability: Modular
1.2 How to build the software to improve the quality of the quality objectives OOP
accuracy: a package dispersion Robustness: encapsulation, error handling scalability: encapsulation, information hiding Reusability: Module and component design, model, model § compatibility: standardized modules and interfaces § portability: information hiding, abstract § easy to use: the GUI component framework § efficiency: reusable components, § timeliness: modeling, economic reuse §: reuse features: scalable
software building
2 software construction of the five key quality objectives
quality considering the quality objectives of the course 1.2 software to build
elegant and beautiful code ⇒ easy to understand, easy to understand design / development cheaper reuse ⇒ low complexity ⇒ ready to change, easy to expand robustness and accuracy ⇒ safe flawless, error-prone performance and efficiency ⇒ efficient operation of
Chapter 4 intelligibility
Chapter 5 reusability
Chapter 6 scalability / maintainability Chapter 7 robustness / Chapter 8 correctness efficiency / performance
Chapter 3 ADT and OOP reconstructed Chapter 9
1.2 software build quality objectives
straightforward
time period substituting Code Level Code Level component assembly stage
when building
intelligibility code (variable / routines / configurations with standard naming statement, the code layout styles, notes, complexity) drill;
of the function specification
intelligibility member / Project ( tissue package, file organization, namespaces)
reconstruction
operation
recording tracks
1.2 software to build quality objectives
reusability
time period Code level Code level assembly component level
buildtime
ADT / OOP; separation of interface from implementation; Overload; Inheritance / heavy / rewriting; compositions / agents; polymorphism; subtype and generic programming; OO design pattern
API design; Library; frame (for / reuse)
run
1.2 software build maintainability and quality of the adaptive target
time period Code level Code level component assembly stage
when building
a modular design; polymerization degree / coupling; solid; OO design pattern; table-based programming; national plans; based the syntax of the programming
solid; grasp
SCM version control
run
1.2 software build quality objectives
robustness
time period code-level component level code level assembly stage
when building the
error handling; exception handling; assert; defensive programming; test-first programming
unit testing integration testing RegressionTesting
run
debug dump
recording track performance
time period Code level Code level assembly component level
design patterns build
run
complex space (memory management); time complexity (algorithms); Code tuning
distributed system
performance analysis and adjustment of
the parallel / multi threaded program
software building
summary
1.2 software build quality objectives
summary
quality attributes of software systems - external and internal quality factors - important factors external quality - quality targets five key trade-off between quality factors software built - easy to understand: elegant and beautiful code / intelligibility - readily available change: maintainability and adaptability - developing cheap: design / re-use: reusability - prevent vulnerabilities: robustness - efficient operation: building technical performance this course is to be studied (classified according to the direction of five key quality objectives)
software to build
ends