Design Quality Criteria

Chapter 2

Design Quality Criteria

This chapter discusses what qualities are desirable of an application protocol design, and what quality criteria can be used when evaluating or engineering an application protocol design. We recognize that design quality must be enabled by the design model that is used in composing designs, and that quality achievement can be supported through a design methodology. The quality criteria presented are not peculiar to application protocol design, but are applicable to design in many other areas, including data transfer protocol design. We illustrate the criteria with examples taken from the OSI Session Layer stand-ards.

The purpose of this chapter is to provide a basis for evaluating the quality of designs and for successfully pursuing quality when engineering designs. This objective is moti-vated by the fact that quality achievement is one of the major requirements on the design methodology that is developed in this thesis.

The structure of this chapter is as follows: section 1 introduces the problem of design evaluation: what are desirable qualities and what are adequate measures of quality? Effi-ciency and ease of use are considered as two possible qualities that could be evaluated. Ease of use is taken as the principal yardstick for assessing overall quality; section 3 intro-duces criteria for evaluating ease of use; section 4 discusses quality in relation to the use of a design model, a specification language, and a design methodology; and section 5 presents the conclusions of this chapter.

2.1Design evaluation

Design starts out from user requirements, or from user needs, that have to be satisfied, subject to a cost function. Possibly a minimum set of user requirements and a maximum cost are set. The task of the designer is to maximize the number of requirements that are satisfied by the design and to minimize the cost during the design process, given these boundary conditions. It seems natural, therefore, to evaluate a design on basis of require-ments-satisfaction and cost. There is, however, a major problem with (high level) design

19

20

as a combination of system efficiency, which is inversely proportional to the computa-tional complexity of protocol actions, and network efficiency, which is inversely propor-tional to the amount of control information that is exchanged. A possible approach to evaluating system efficiency is by assigning weights to protocol actions, representing the relative computational complexity of the actions. In [Ravindran93], for example, applica-tion protocol efficiency is evaluated based on the relative complexity of state transitions and the number of messages exchanged.

In general, however, the relationship between aspects directly represented by a design and its efficiency is not straightforward. Moreover, there are no general principles or rules which can be used to evaluate the efficiency of a design solution, independent of the level of abstraction.

Although efficiency is an important quality of a design, it is not the only quality, and it is even debatable whether it is the most important quality when overall costs are consid-ered. For example, efficiency is not concerned with overall development and maintenance costs, neither is it concerned with functionality as a design variable.

2.1.2Ease of use

Ease of use of a design denotes the quality of the design to be used in a straightforward way. A design has different types of users. Assuming that the design is an architecture, e.g. a service, these users are (see also Figure 2.1):

?the architect, who has to conceive and maintain the architecture;

?the implementor, who has to interpret the architecture in order to transform it into an implementation; and

?the system user, for example an application programmer, who sees the realized system through its architecture and thus uses the architecture to learn and operate the system.

Ease of use has a different meaning for each of these types of users:

?the architect likes the architecture to be robust to changes that concern its implementa-tion, its realization, or the way it is used. For example, it should be possible to change the architecture’s implementation, e.g. to replace it by a more efficient implementation, without changing the architecture. On the other hand, if changes are necessary that effect the architecture, e.g. to satisfy additional user requirements, the architect chooses the architecture to be easily adaptable, without requiring major redesign;?the implementor prefers an architecture that is precise and unambiguous, without unnecessarily constraining implementation options; and

?the system user chooses an architecture that is easy to learn and easy to use, since this will facilitate job performance and improve productivity.

21

22Similar arguments apply to an implementation, e.g. a protocol that implements a service, since an implementation has to be maintained as well, must be transformed into a realization, and is used through the architecture that it implements. Notice that an imple-mentation may act as an architecture for a lower level implementation. For example, a protocol architecture defines protocol actions as integrated functions. A protocol imple-mentation replaces these integrated functions by implementations, i.e. specific applica-tions of an underlying computer system or operating system architecture.

Ease of use will certainly optimize functionality: omitting required functions will decrease job performance for (some of) the system user(s). One the other hand, providing too many, too specialized functions will again hamper ease of use. It is unclear at first glance, however, how ease of use will effect cost and performance optimization. The achievement of ease of use of a design requires attention and effort of the designer, and thus even appears to increase development costs.

We believe, however, that the overall costs of developing, using and maintaining a system will be less if ease of use is pursued during design. This is confirmed by experi-ence with designing all kinds of (complex) systems. With respect to an architecture, the following arguments apply:

?if the architecture is robust and adaptable, it is cheap to maintain. Moreover, it facili-tates future changes of the implementation or realization that would improve perform-ance;

?if the architecture does not constrain implementation, the implementor has maximum freedom to optimize cost and performance of the implementation; and

Figure 2.1: Different types of users of an architecture

architecture

system user:implementor:architect:learn and operate

interpret and transform

conceive and maintain

?if the architecture is easy to learn and use, user education is cheaper and user produc-tivity is higher.

Again, similar arguments apply to an implementation.

Optimizing ease of use during design thus leads to an optimization of overall function-ality, overall performance, and overall, long-term costs. For this reason we will take ease of use as the principal yardstick for evaluating designs.

2.2Quality criteria

In this section we discuss some criteria for evaluating ease of use. The criteria are based on a decomposition of ease of use into a number of sub-qualities. A design that is easy to use should be correct, clearly defined, and ‘clean’.

The necessity of a correct design is obvious. A design should not contain errors or otherwise the derived realized system will not work or will not work properly. Since correctness depends on the user requirements, no general criteria can be provided.

A clearly defined design is a design that is represented without ambiguities and incon-sistencies, in terms of the elementary design concepts available to the designer. It should also be represented at the right abstraction level. Also this quality is obvious. Since clear-ness depends on the contents of the design, no general criteria can be provided in this case either. Clearness also depends on the choice of elementary design concepts, which may be furnished by a predefined design model. The impact of a design model on ease of use will be discussed later in section 2.3.

Cleanliness ([Blaauw85], [Roman85]) is concerned with the conceptual integrity of the design, which in turn is strongly related to the choice of functions that collectively deter-mine the functionality defined by the design. A clean design is well structured, well balanced, well fit. Hence, cleanliness is basically an aesthetic quality, and therefore to some extent a matter of taste, not completely arbitrary but also not rigidly defined. It is possible to formulate a number general principles or rules which can act as cleanliness criteria. Designs can be evaluated with respect to their compliance to these criteria, although, as mentioned before, there are no clear boundaries between ‘bad’, ‘good’, and ‘better’. Still cleanliness criteria can be very useful in evaluating the overall quality of a design. Cleanliness criteria are not restricted to application protocol design, but have proven to be useful in many design domains. For example, in [Blaauw75] they were used to assess the quality of computer architectures, in [Vissers88] they guided the develop-ment of styles for service and protocol specification, and in [Scollo93] they were taken as touchstone in the engineering of logics for data type specification.

23

The importance of cleanliness is often underestimated, whereas correctness and clear-ness are always important objectives during design. For example, cleanliness is often sacrificed for efficiency reasons ([White93]). In the case of service and protocol stand-ards, cleanliness is normally not improved after the first release of a standard. Reported defects related to errors, ambiguities and inconsistencies, on the other hand, are always corrected (which is not surprising since such defects have an immediate effect on the interworking of real systems).

Each of the cleanliness rules will be explained in a separate subsection below. These explanations will be in general terms, referring to two levels of design, viz. architecture and implementation. When architecture is mentioned, this can also be understood as service, or, more specifically, application service. When implementation is mentioned, this can be understood as protocol, or application protocol. Similarly, architecture func-tions can be understood as service functions (service elements), and implementation func-tions as protocol functions (elements of protocol procedure). Also, small examples of violations of the cleanliness rules are presented. All examples are taken from the first version of the OSI Session Layer standards, defined by ISO: the basic connection oriented Session Service definition ([IS8326:87]), and the basic connection oriented Session Protocol specification ([IS8327:87]). The examples are based on our experience with these standards through their formal specification in LOTOS ([Scollo87, Sinderen89]). 2.2.1Consistency

“do not include what is conflicting with previous design choices”

A consistent design exhibits regularity and suggests a single, coherent line of reasoning behind it. This regularity makes it possible to anticipate parts of the design once other parts are known ([Blaauw85]). Hence a consistent design confirms our expectation and, conversely, an inconsistent design contradicts our expectation.

For example, an architecture or implementation should define uniform constraints on the use of functions and function features, independently of when they are used and in what context they are used, whenever possible. Consistency is needed above all because people are involved in using a design. Its main purpose is to facilitate understanding, learning, and using a design.

An example of a violation of the consistency rule can be found in the constraints on the Synchronization Point Serial Number (SPSN) parameter in the Resynchronize function and the Activity Resume function of the Session Service and Protocol. A SPSN is used by the Session Service users to identify a common synchronization point; the Session Protocol constrains the value of each SPSN that is used by the Session Service users. The Resynchronize function is provided to assist orderly re-establishment of communication. It sets the session connection to an agreed, hence defined, state. The value of the SPSN

24

that is agreed between the users is the next SPSN that will be used. The Activity Resume function is provided to indicate that a previously interrupted activity is resumed. It also sets the session connection to a new defined state. The value of the SPSN that is agreed between the users is the next SPSN to be used minus one. It would have been consistent, however, if this value had the same meaning as in the Resynchronize function.

2.2.2Orthogonality

“do not link what is independent”

Orthogonality calls for the separation of aspects of a system that are independent of each other. For example, functions that are independently needed by system users should be separated in the architecture. Similarly, implementation functions that are independently needed in support of the architecture’s functionality should be separated, i.e. assigned to different entities in the implementation.

The principle of orthogonality complies with that of separation of concerns. A special case of this principle is encapsulation, or information hiding ([Parnas72]), which is used in structuring implementations. Encapsulation leads to a structure of entities, where each entity hides as much as possible of its inner workings from the others. Encapsulation is the leading principle in object oriented approaches to system design ([Booch86]).

The rule stated above does not prohibit the separation of aspects that are largely, but not completely, independent. The benefits of orthogonality still apply to some extent in these cases. On the other hand, the complementary rule to the one stated above should also be respected:

“do not separate what is dependent”

Thus, functions that are strongly related should not be separated in an architecture, or assigned to separate entities in an implementation. Otherwise complex relationships between functions, and complex interactions between entities, have to be defined.

Orthogonality primarily supports maintenance: it permits to make changes to functions without (much) effecting other functions, and to make changes to entities’ implementa-tions without (much) effecting other entities. Orthogonality also facilitates learning and using a design: orthogonal functions can be understood on their own and can be used inde-pendently. Finally, orthogonality supports concurrency of design: a subdivision of a design into orthogonal functions permits the independent implementation of these func-tions.

An example of a violation of the (first) orthogonality rule can be found in the constraints associated with the Resynchronize Type parameter in the Resynchronize

25

function of the Session Service and Protocol. The Resynchronize Type parameter is used to indicate one of three possible resynchronize options (abandon, restart, or set). The choice of an option effects the Resynchronize function in two respects. First, each option implies different constraints on the value of the Synchronization Point Serial Number (SPSN) that can be used by the Session Service users. And second, each option implies a different ‘precedence’ which is used by the Session Protocol to resolve collisions of function invocations that involve at least one invocation of the Resynchronize function. Since the semantics of synchronization points is transparent to the Session Protocol, the range of synchronization points from which the users may select, and the precedence of a resynchronization attempt can better be treated as independent aspects at this level, which can be served by separate parameters in the Resynchronize function.

2.2.3Propriety

“do not introduce what is immaterial”

Aspects that are defined by a design should be proper to the purpose of the system, where the purpose of the system is determined by the user requirements. For example, functions which are not required by the system users and whose usefulness is not clear are better omitted in the architecture.

Propriety also demands that aspects that are defined by a design should be proper to the purpose of the design, i.e. correspond to the level of abstraction of the design. Thus, an architecture should not define aspects of the implementation that are irrelevant to the system user. And an implementation should not define aspects of functions that are only relevant to a lower level implementation, or a realization. This allows a clean division of work, with proper attention of the designers to problems that are their concern and maximum freedom to resolve these problems.

Propriety implies parsimony. Not only should designs only define relevant functions, corresponding to essential, well understood user and domain requirements, they also should define each function only once. Adherence to parsimony avoids abundance in the architecture, thus aiding its comprehensibility, and avoids redundancy in the implementa-tion, contributing to efficiency.

An example of a violation of the propriety/parsimony rule can be found in the basic concatenation function of the Session Protocol. Basic concatenation yields a concatenated sequence of two session protocol data units (SPDUs) which is mapped onto a single trans-port service data unit (TSDU). The first SPDU in a basic concatenation sequence is a so called category 0 SPDU (either a GIVE TOKENS SPDU or a PLEASE TOKENS SPDU), the second SPDU is a category 2 SPDU (a class of various types, including the DATA TRANSFER SPDU). Category 2 SPDUs are never mapped one-to-one onto a TSDU. This means that if a category 2 SPDU has to be sent, it is either appended to a category 0 SPDU

26

which also has to be sent, or it is appended to a ‘dummy’ category 0 SPDU which is generated for the purpose of sending the category 2 SPDU. In the latter case the basic concatenation function does not serve any real purpose (the constraint that a category 2 SPDU is never sent alone is inherited from a predecessor of the Session Protocol, CCITT Recommendation T.62, and has been retained for compatibility reasons).

2.2.4Generality

“do not restrict what is inherent”

Aspects covered by a design should be defined in their most general form. Thus, functions of the architecture should be general purpose or generic, as opposed to being tailored to the current conception of how the architecture will be used. Also entities of an implemen-tation should be general purpose or generic, permitting their use in several contexts, and, consequently, permitting the composition of several more complex or more specialized functions. An implementation that allows alternative compositions of entities can adapt to different user environments, or a changing environment, and thus supports flexibility and adaptability.

Generality implies open-endedness, i.e. the property of allowing future extensions. An open-ended system does not require modifications of its architecture, or, worse, its imple-mentation, in order to be used in supporting an extended functionality. Instead, the original architecture and implementation can be extended with appropriate functions and entities, respectively. Generality thus facilitates maintenance.

Generality also allows re-use of functions of an architecture and of entities of an imple-mentation. Generic functions or entities of a design can be re-used in other, new designs that possess some degree of similarity with the existing one. This property clearly aids cost-effectiveness of design.

In order to be general, a design should be complete. For example, an architecture should include all functions that are proper to its purpose. If not, at least some intended user environments can not use the architecture. Also each function should be complete, permitting all possible uses that are proper to its purpose. A complementary rule to the one above should therefore be respected as well ([Scollo93]):

“do not forget what is relevant”

To illustrate generality, we use the example that was used in subsection 2.2.2 to illus-trate orthogonality. The constraints associated with the Resynchronize Type parameter in the Resynchronize function of the Session Service and Protocol imply that only specific combinations of resynchronization point ranges and resynchronization preferences can be used. For example, it is not possible to use a Synchronization Point Serial Number with a

27

28value that is greater than the value that is most recently used, and a low precedence.Hence, the Resynchronize function is not complete in this respect, and may not be appro-priate to some user environments. Another consequence of the provision of rather arbi-trary options is that some options may never, or hardly ever used (indeed, the set option is not used by any of the currently defined Application Layer protocols).

2.3Quality and design engineering

This section discusses the relationship between design engineering, i.e. the activity of developing a design, and the achievement of quality characterizing a clean design. Three elements of the design process will be considered, viz. the design model, the specification language, and the design methodology used in the design.

2.3.1Relation to design models

Often a designer has a predefined set of concepts at his disposal which form the basic building blocks in which designs have to be expressed ([Gotzhein93], [Ferreira93]). These concepts are the elementary design concepts , or architectural concepts, which together with rules for their composition form a design model or design language (to be distin-guished from a specification language, see subsection 2.3.2). Since complex designs need to be structured, a design model may also include structuring techniques that yield partic-ularly useful structures in the considered design domain. Figure 2.2 illustrates the applica-tion of a design model.

Since a design is expressed using the design model, the quality of a design is indirectly determined by the suitability of the design model. What, then, constitutes a suitable design model? Specific requirements on a design model are determined by the design domain, in our case application protocol design. A general requirement with respect to a design

Figure 2.2: Application of a design model

design

application

structuring design design model

concepts

techniques

model is ease of use, and the same criteria apply as have been proposed for the evaluation of design quality:

?consistency: design concepts should be consistent in their representation of, or abstrac-tion from, aspects of the ‘real world’;

?orthogonality: distinct design concepts should be used to represent different, inde-pendent aspects;

?propriety: design concepts should be proper to the needs of the design domain as well as straight to the point;

?generality: design concepts should be general purpose in the design domain, and the complete set of design concepts should completely cover the needs of the design domain.

Compliance to these criteria leads to a ‘clean’ design model which satisfies often stated requirements on design models, such as relevance, appropriateness, and completeness (see [Vissers93], for example). A clean design model defines a minimal set of general purpose design concepts that completely covers the needs of the design domain, and so enables designs to be efficiently and effectively expressed. In practice, however, it turns out to be very difficult to determine the right design concepts, mainly because the needs of the design domain are not clear from the start. Only through experience one finds that certain aspects, that are considered proper to the design domain, are cumbersome or even impossible to express with the design concepts available. An iterative process of applica-tion and improvement based on application feedback is usually needed to establish the right concepts.

A design domain is generally not focused on a single level of abstraction, but, instead, covers an abstraction spectrum with several distinguished abstraction levels. Design concepts which are proper at one abstraction level may not be proper at another abstrac-tion level. A design model may therefore be subdivided into a number of sub-models, corresponding to abstraction levels, with distinct or partially overlapping sets of design concepts. For example, the concept of PDU is proper at the protocol level, but not at the service level. The concept of service primitive, on the other hand, is proper at both the service level and the protocol level. (One may, of course, decide that a more general purpose concept is needed, of which the concepts of PDU and service primitive are special cases.)

Another desirable quality of the design model, besides cleanliness, is clearness. All design concepts identified should be precisely formulated, without ambiguities or incon-sistencies. Sometimes a mapping is defined between elementary design concepts and their representation in a formal specification language in order to satisfy this requirement. Such a mapping determines the so called architectural semantics of the specification language ([Turner87], [Schot90]). When defining an architectural semantics one should be careful

29

about preserving the cleanliness of the design model. For example, design concepts as originally intended should not be inadvertently changed due to limitations of the specifi-cation language. Also structures can be represented using a formal specification language (as demonstrated in [Turner95]), although, in practice, the motivation for this is usually not clarification of the structuring techniques but illustration of the applicability of the specification language.

The structuring techniques provided by a design model should not limit the applica-bility of the design concepts, but should merely aid in composing structures that can be used for separation of concerns (see orthogonality, subsection 2.2.2). Examples of compo-nent types, or high level design concepts, that are useful in the protocol design domain are service provider, protocol layer, and protocol entity.

2.3.2Relation to specification languages

A design has to be represented using some specification language. There is a broad consensus among designers that preferably a formal specification language should be used for this, provided that the language satisfies besides formality also other important requirements that determine its effective use in practice (see [Weber93] and [Vissers93], for example). Formality enables the precise and unambiguous formulation of the design and permits evaluation of the correctness of the design using language based validation tools. A formal specification language has an underlying mathematical model which determines the choice of (elementary) language elements. This fact, and the fact that the application domain for which the specification language has been defined is usually not the same as the design domain at hand, makes that there is not a one-to-one relationship between elementary design concepts and elementary language elements. It is therefore useful to distinguish between a design and its representation, where the latter is referred to as the design specification. This is illustrated in Figure 2.3.

A formal specification language should be sufficiently expressive in order to support the needs of the design domain. A useful test is the definition of an architectural seman-tics, i.e. a mapping between the elementary design concepts and specification language constructs that can be used for the representation of these concepts. If this is not possible, a subset of the design concepts may be considered, in case this subset permits expression of designs at least one abstraction level distinguished in the design domain.

Sufficient expressiveness, also called appropriateness ([Roman85, Vissers93]), is the principal requirement on formal specification languages. Other requirements are composi-tionality, which allows the support of structuring techniques, and the support of a design methodology. Experience with the application of formal specification languages in service and protocol specification indicates that neither of these requirements are completely satisfied by current formal specification languages ([Vissers93]). For example, the formal specification of the OSI Session Service ([IS8326:87]) and Session Protocol

30

31([IS8327:87]) in LOTOS took about 5 years to complete, which was partly due to lack of resources and to lack of quality of the standards, but certainly also partly to blame on the inappropriateness of the specification language.

2.3.3Relation to design methodologies

A design methodology is used to systematically transform a set of user requirements into a design that satisfies these requirements. Since the ‘gap’ between requirements and the conceptual solution embodied by the final design is potentially wide, a design method-ology should indicate how this gap can be bridged, e.g. by setting out a design trajectory that can be followed by the designer. Each step along this trajectory should serve a well defined purpose, thus permitting division of work and sometimes concurrency of design.The subdivision of the design process into a design (architectural) phase, implementation phase, and realization phase is an example of a design trajectory. Another example is the subdivision into a service design phase and a protocol design phase. Design steps of a design trajectory may also be recursive, in the sense that subsequent steps aim at similar types of transformations. For example, a design step may be concerned with the decompo-sition of an architecture into a composition of functional entities, each of which is again defined by an architecture. The architectures of the functional entities may again be decomposed in the same way.

A design process involves many decisions from the designer, where each decision typi-cally requires a selection from many design alternatives that satisfy the given user require-ments. A design methodology should maintain a consistent set of principles or rules

application

design model

design specification

application

specification design

interpretation representation interpretation representation

Figure 2.3: Application of a specification language language

32

33

level. This will enable the identification of similarities among designs at the highest possible level, hence at the earliest possible time in the design process. Specialization of general purpose or generic components at the proper abstraction level will shorten the development time of the final design.

?domain interaction: during the design of a system it is necessary to be aware of the relationships with other design domains. Clear boundaries between design domains will lead to a cleaner design from an integrated domain perspective. These boundaries should be provided at the proper, i.e. the highest possible, abstraction level in order to simplify domain interaction and, consequently, to support trade-offs across design domains. Different design domains may have boundaries defined at different abstrac-tion levels. For example, application protocol design is related to (application) software design and (network or distributed) operating system design. The relation to the former is best considered at an application service or application interface level; the relation to operating system design is best considered at an application protocol archi-tecture (with integrated protocol actions) or implementation (with protocol actions defined in terms of operating system calls) level.

The relation to quality is obvious: division of work will concentrate attention and speed up development; conceptual integrity will provide a well balanced, clean design which is easy to maintain, implement, learn, and operate; design for re-use will reduce design effort; and clear domain interaction will facilitate integration of design products from different domains and avoids redundant solutions.

All of the above mentioned advantages rely on the fact that the design methodology employs a set of abstraction levels and exploits the relationships between these abstraction levels. We will therefore consider as desirable characteristics of a design methodology:?definition of abstraction levels: each abstraction level should correspond to a well defined purpose of a design step, i.e. to an identifiable need in the design process.

There should be a highest abstraction level that supports the expression of user require-ments; there should be a lowest abstraction level that allows the expression of the final design. For each abstraction level a design (sub-) model must be defined that will enable expression of designs at that abstraction level.

?definition of relationship between abstraction levels: each next (lower) abstraction level should be related to the previous (higher) abstraction level. This implies that their design models, if different, are related and that of each construct expressed at the lower abstraction level it is in principle possible to establish whether it is consistent with a corresponding construct at the higher abstraction level. This latter relationship is called conformance: if a lower level construct conforms to a higher level construct it is a correct implementation of that construct, and, conversely, the higher level construct is an abstraction of the lower level construct.

34

A design methodology may incorporate many strategies, methods, and techniques for attacking design problems. Strategies, methods, and techniques, in turn, may include the use of heuristics and quality criteria in order to support identification of, and selection from, design alternatives. Heuristics are rules of thumb, based on experience, and particu-larly valuable when no algorithmic techniques are applicable, e.g. because of the complexity of the design problem at hand (a situation which is not unusual in distributed systems design). Like the quality criteria for cleanliness, heuristics are not precise and subject to personal judgement, but nonetheless of great value, especially to high level design engineering ([Rechtin92]).

The efficiency of a design process and the quality (in particular correctness and unam-biguity) of designs may be improved by the use of formal methods that support design transformation or design validation ([Sinderen92], [Turner93]). Formal methods are most convenient if they are based on the formal specification languages that are also used to represent design results.

2.4Conclusion

Design engineering should aim at optimizing satisfaction of user requirements related to functionality and performance and at minimizing costs. It is difficult to establish criteria for evaluating the efficiency (performance to cost ratio) of a design in quantitative terms. And even if efficiency if this is possible, this would not provide insight in the overall costs of the design, related to its development, use, and maintenance.

Another quality that can be considered is ease of use, where ease of use is related to conception and maintenance, interpretation and implementation, learning and using a design. Ease of use demands correctness, clearness, and cleanliness. With respect to cleanliness a number of general design quality criteria are presented, which are summa-rized in Figure 2.6. Although these criteria can be considered as essentially aesthetic criteria, they are also of practical use, especially when pursuing adequate functionality and low overall costs.

The following elements of a design environment influence design quality:

?design model: a design model defines the elementary design concepts that are used for the expression of a design, composition rules for these concepts and possibly struc-turing techniques. If the design model is not suitable for the design domain, the quality of designs expressed with this model will also be poor.

?specification language: design concepts must be represented using a (general purpose) design language. Preferably, a formal specification language is used for this purpose. A formal specification language should be capable of representing the elementary design concepts and the structuring techniques defined by the design model. In practice, this is often not the case.

35

36?design methodology : a design methodology serves to provide methods for transforming user requirements into a satisfactory design. The quality criteria proposed here are well suited to application during design engineering. A design methodology that exploits multiple related abstraction levels has some potential advantages that contribute to design efficiency and design quality.

Consequently, the quality criteria proposed in this chapter can be used for design eval-uation, but can also be used in a design methodology to support design engineering.References

[Blaauw85] Blaauw, G.A., and Brooks, F.P. Jr., Computer architecture , Lecture notes,

University of Twente, The Netherlands, and University of Carolina at Chapel Hill,U.S.A., August 1985.

[Booch86] Booch, G. Object-oriented development, IEEE Transactions on Software

Engineering , Vol. SE-12, No. 2, February 1986, 211- 221.

[Ferreira93] Ferreira Pires, L., Sinderen, M. van, and Vissers, C.A., Advanced design

concepts for open distributed systems, In: Proceedings of the 4th Workshop on

Figure 2.6: Summary of design quality criteria

ease of use

cleanliness

yields

demands

consistency: “do not include what is conflicting”

orthogonality: “do not link what is independent”

propriety: “do not introduce what is immaterial”

generality: “do not restrict what is inherent”

good quality (related to overall functionality, performance, costs)

Future Trends of Distributed Computing Systems, IEEE Computer Society Press, 1993, 419-425.

[Gotzhein93] Gotzhein, R., Open distributed systems: on concepts, methods, and design from a logical point of view, Vieweg, 1993.

[IS8326:87] ISO, Basic connection oriented session service definition, International Standard ISO 8326 (first edition), 1987.

[IS8327:87] ISO, Basic connection oriented session protocol specification, International Standard ISO 8327 (first edition), 1987.

[Parnas72] Parnas, D.L., On the criteria to be used in decomposing systems into modules, Communications of the ACM, Vol. 15, No. 12, December 1972, 1053-1058.

[Ravindran93] Ravindran, K. , and Lin, X.T., Structural complexity and execution efficiency of distributed application protocols, Computer Communication Review, Vol. 23, No. 4, October 1993, 160-169.

[Rechtin92] Rechtin, E., The art of systems architecting, IEEE Spectrum, October 1992, 66-69.

[Roman85] Roman, G.-C., A taxonomy of current issues in requirements engineering, IEEE Computer, April 1985, 14-22.

[Schot90] Schot, J., The role of architectural semantics in the formal approach of distributed systems design, Ph.D. thesis, University of Twente, Enschede, The Netherlands, 1990.

[Scollo87] Scollo, G., and Sinderen, M. van, On the architectural design of the formal specification of the session standards in LOTOS, In: Protocol Specification, Testing, and Verification, VI, Sarikaya, B., and Bochmann, G. von (editors), Elsevier Science Publishers B.V. (North-Holland), 1987, 3-14.

[Scollo93] Scollo, G., On the engineering of logics, Ph.D. thesis, University of Twente, Enschede, The Netherlands, 1993.

[Sinderen89] Sinderen, M. van, Ajubi, I., and Caneschi, F., The application of LOTOS for the formal description of the OSI session layer, In: Formal description Techniques, I, Turner, K.J. (editor), Elsevier Science Publishers B.V. (North-Holland), 1989, 263-278.

[Sinderen92] Sinderen, M. van, and Ferreira Pires, L., Protocol design and implementation using formal methods, The Computer Journal, Vol. 35, No. 5, 1992, 478-491.

37

[Turner87] Turner, K.J., An architectural semantics for LOTOS, In: Protocol Specification, Testing, and Verification, VII, Rudin, H., and West, C.H. (editors), Elseviers Science Publishers B.V. (North-Holland), 1987, 15-28.

[Turner93] Turner, K.J (editor), Using formal description techniques: an introduction to Estelle, LOTOS and SDL, John Wiley & Sons, 1993.

[Turner95] Turner, K.J., and Sinderen, M. van, LOTOS specification style for OSI, In: LOTOSphere: software development with LOTOS, Bolognesi, T., Lagemaat, J. van de, and Vissers, C.A. (editors), Kluwer Academic Publishers, 1995, 137-160. [Vissers88] Vissers, C.A., Scollo, G., and Sinderen, M. van, Architecture and specification style in formal descriptions of distributed systems, In: Protocol Specification, Testing, and Verification, VIII, Aggerwal, S., and Sabnani, K. (editors), Elsevier Science Publishers B.V. (North-Holland), 1988, 189-204.

[Vissers93] Vissers, C.A., Sinderen, M. van, and Ferreira Pires, L., What makes industries believe in formal methods, In: Protocol Specification, Testing, and Verification, XIII, Danthine, A., Leduc, G., and Wolper, P. (editors), Elsevier Science Publishers B.V.

(North-Holland), 1993, 3-26.

[Weber93] Weber-Wulff, D., Selling formal methods to industry, In: Formal Methods Europe, I, Woodcock, J.C.P., and Larsen, P.G., Lecture Notes in Computer Science 670, Springer Verlag, 1993, 671-678.

[White93] White, S., et al., Systems engineering of computer-based systems, IEEE Computer, November 1993, 54-65.

38

品质部年度工作总结报告

2013年度品质部工作总结报告 时间一晃而过，转眼间2013年已经过去2014到来，借此机会祝愿公司领导和全体同仁：新年愉快！工作顺利！ 回想过去的一年，担任品质主管一职，虽没有轰轰烈烈的成果，但也算经历了一段不平凡的考验和磨砺。非常感谢公司给我一个成长的平台，让我在工作中，学习到更多的东西，也知道自己存在诸多不足。上级领导对我的支持与关爱，同事对我的支持和协助，令我感到在唐巨龙公司的温情无处不在，在此我向公司的领导以及全体同事表示最衷心的感谢，有你们的协助才能使我在工作中更加的得心应手，也因为有你们的努力，才能令到公司的发展更上一个台阶。在公司领导及各部门同事的正确领导与协助下，品质工作着重于公司的质量方针、宗旨和目标上，紧紧围绕重点展开工作，主要开展以下工作： 1、严格按照《进料检验规程》做好对原材料的检验工作，并配合好采购部对供应商原材料质量的评价和跟踪。对原材料及时检验试验，发现不符合要求予以退货并开出《原材料品质异常联络单》，同时要求供应商分析不亮原因及改善品质，满足我司的供货要求。 2、做好与相关部门工作的协调和沟通，配合车间做好品质工作，并针对发生的不良情况，通知当班负责人及时调整并跟踪验证，直到问题最终得到解决。认真做好客户反馈的质量信息和退货统计工作，做好一月一次的《品质月报工作》。 3、建立更加全面的品检检验流程和作业要求，从而保证了制程中的产品质量。 4、产品产生的质量问题还是存在很多的因素，主要是生产部及品质部人员的自检能力不足，致使在相关作业过程中未做到细微处；个人行为的随意性造成存在的质量隐患。 5、加强对生产及品质人员相关知识、操作技能的培训，早会的督导以及客户投诉的分析，提高检验人员的综合素质水平，打造一个工作经验丰富，工作热情高涨的团队。 作为品质部主管，我感到压力、责任重大，质量是企业的生命，要想带好一个团队，除了熟悉流程外，还需要负责具体的工作，首先要以身作则，这样才能保证在人员偏紧的情况下，大家都能够主动承担工作。 2014年工作重点： 1、做好对原材料质量的评价和跟踪，确保来料合格，也要做好制程中的品质跟进工作，吸取客户投诉及退货教训。 2、贯彻品质理念，提升品质意识，我们采取加大培训的力度，内容主要包括质量体系文件和品质理念的宣导。 品质部工作的困扰： 1、供应商来料不及时，不能满足生产，经过沟通后还总是三番五次出问题，有时好不容易送来了，但检验有问题，产线急等着要用，不得不要耗费人工进行挑选或再加工，这就违背了品质原则，使品管人员心里好痛苦。 2.、员工随意性强，没有强化作业操作要领，不良品多导致返工，后续检验测试没有充分的时间进行。 3、供应商拖欠物料，导致无法生产，将计划交期延后，给后段品质检验造成时间恐慌，没有足够的时间进行某些可靠性测试，总是急急慌慌在出货。 2013年来料统计率： 2013年生产组装统计率： 总结人：篇二：品质部年度工作总结报告 品质部年度工作总结报告 在品质部工作的这段时间里，我看到的、听到的、体会到的，让我感受很多！如何管理好品质部，使其能够更好地服务于公司，并提升公司的品牌形象！我拟制定以下工作计划： 一. 品质部人事规划：针对品质部目前的现状和实际生产需要，成衣qc组需要增加一个

物业公司品质部工作计划

物业公司品质部工作计划 物业品质部的工作重点是健全各岗位工作手册，完善管理职能，实现规范化运营。打造一支强有力、高素质的物业服务队伍。下面是第一范文网小编整理的物业公司品质部工作计划，希望对大家有所帮助! 物业公司品质部工作计划(一) 为了做好品质管理部各项工作，达到公司要求的发展目标，现将20XX年度工作计划安排如下： 1月份： 1)完成体系文件的管理评审工作，保证满足体系认证的符合性; 2)准备公司物业资质申报工作，并做好相关的工作; 3)加强与业主的沟通，制定公司工作简报; 2月份： 1)2月底完成体系文件的第二次内审工作;并及时整改和关闭不合格项，力求体系文件运行的完好性; 2)确保大厦评优资料的全面和完整性，有必要向市局提出书面性报告，并协助相关资料的移交工作; 3)完善公司规章制度的内部建设，确保公司工作开展的正常运作; 3月份： 1)做好一切ISO9000质量认证体系的准备工作，并保证认证工作顺利的通过; 2)做好大厦评"区优"的申报工作，同时完善好评优资料的创建工作;

4月至6月： 1)做好评优工作的各项准备，迎接"区优"的评审工作;保证"区优"评比工作顺利通过; 2)持续改进体系文件的适用性和可操作性;并按要求深入工作现场，做好体系文件正常的运行工作; 3)做好用户意见调查工作，分析用户的需求，客观评价用户的满意度，并提出预防纠正整改措施; 7月至9月： 1)做好市优创建的准备工作和市优申报工作，以"市优"标准整理相关的评优资料; 2)全面展开体系文件的内审工作和管理评审工作; 10月至12月： 1)完成体系文件运行的复审工作; 2)做好评优工作的各项准备，迎接"市优"的评审工作;保证"市优"评比工作顺利通过; 3)做好用户意见调查工作，分析用户的需求，客观评价用户的满意度，并提出预防纠正整改措施; 4)提交年度总结和下年度计划; 物业公司品质部工作计划(二) 为了提高物业整体工作质量，更好地为公司持续发展培养优秀人才，20xx 年，品质培训部将在上一年度工作基础上，立足公司发展，创新工作形式，拓展工作的深度和广度。20xx年度工作计划如下所示：

品质部周工作总结与计划

篇一：2013年品质部工作总结及2014年品质部的工作计划及重点 -0 - 2013年品质部工作总结及2014年品质部的工作计划及重点 目录 一．部门组织架构和人员状况 二．部门的工作职责 三．2014年度的主要工作内容 四．2013年存在的不足和改善的方案 五：2014年的成本控制计划 六．总结和本年度的目标 一．部门组织架构和人员状况 品质部目前人力配置满员编制为人数:43人 副经理：1人、科长：1人 工程师:8人(包括sqe\体系工程师\高级工程师\qe\pqe); 文员:2人(dcc和品质) 组长:7人(包括iqc\oqc\注塑\喷涂\丝印 a\b班) qc:24人(包括iqc\oqc\注塑\喷涂\丝印a\b班\2名驻厂人员) 目前品质部组织架构新的一年品质部将对公司内部的品质管控系统进行重新调整，品质部门的组 织架构也要进行重新规划，预计的补足现有的组织架构人员外，因2014年客户群的提升，所以 供应商管理与客户维护是我们的工作重点，所以在组织架构上面加入厂商及客户驻厂技术员职位。新的组织架构： 目前由于生产人员的不稳定，导致生产过程中不良产生较多，流入客户处的不良也较多，还有外 发加工厂品质不稳定给公司造成了巨大的损失，外发加工厂的品质控制工作成为了重中之重，而 品质部职责范围甚广，包括：进料，产线，入库，出货，投诉处理，供应商辅导，还要包括体系 完善，部门建立等，所以人员的合理利用和调配成为了工作的重心。 二.部门职责 为贯彻质量管理体系，促进公司产品品质管理及质量改善活动，保证为客户提供满意的产品及优 质的服务，以达到公司利益最大化，暂定以下职责： 1，贯彻公司质量方针，不断完善公司质量保证体系文件，确保iso9001：2008质量管理体系 能持续运行并有效执行； 2，根据公司质量目标，督导各部门建立相关品质目标，负责对各部门的品质管理工作进行评估，并根据实际业绩和生产情况组织检讨，规划； 3，负责公司各种品质管理制度的制订与实施，组织与推进各种品质改善活动。 4，建立质量管理责任制，落实到各相关部门（人），建立并完善品质考核制度办法，执行“每一 道工序严格把关，做到人人有职责，事事有依据，作业有标准，层层有监督”；

物业品质部培训计划

物业品质部培训计划 篇一：物业品质部培训计划 1 ．品质部员工培训实施 标准作业规程 1.0 目的 规范品质部员工培训工作，使内审员培训系统化、规范化，最终使员工具备满足工作需要的知识和技能。 2.0 适用范围 适用于物业管理公司品质部内审员的培训工作。 3.0 职责 3.1 管理者代表负责监督及抽检培训的实施情况、验证培训的效果。 3.2 品质部经理负责制定培训计划，并具体组织实施。 4.0 程序要点 4.1 培训计划的制定 4.1.1 品质部经理于每年的12 月15 日前做出下年度的内审员培训计划，并上报 公司总经理和管理者代表审批。 4.1.2 内审员培训计划必须符合下列要求 a ) 不违反国家的有关法律、法规； b ) 有具体的实施时间； c ) 有考核的标准； d ) 有明确的培训范围； e ) 有培训费用预算。 4.2 品质部标准作业规程的培训 4.2.1 培训内容： a ) 《质量体系文件编制标准作业规程》；

b ) 《质量体系文件和资料管理标准作业规程》； c ) 《内部质量审核实施标准作业规程》； d ) 《内部质量审核管理标准作业规程》； e ) 《质量体系文件编码管理标准作业规程》； f ) 《品质部日常抽检工作质量标准作业规程》； g ) 《住户意见征集、评价标准作业规程》； h ) 《工作记录管理标准作业规程》； i ) 《绩效考评管理标准作业规程》； j ) 《不合格纠正、预防标准作业规程》; k ) 《品质部员工绩效考评实施标准作业规程》。 4.2.2 培训要求： a ) 内审员必须熟练掌握品质部标准作业规程中规定的工作程序和工作要求，对重要内容要求熟记； b ) 内审员必须充分理解按照标准作业规程进行工作的意义，充分理解作业规程中的每项条款的内在含义。 4.2.3 培训的形式： a ) 教员边讲边示范，内审员随听、随记、随操作的形式； b ) 内审员边讨论、边理解、边回忆的形式。 4.2.4 品质部标准作业规程的培训每月至少进行两次，每次不少于60 分钟 4.2.5 品质部标准作业规程的培训由管理者代表或品质部经理组织，教员可以由 公产领导和任何一位工作技能较高的品质部员工担任。 4.3 ISO9000 基本理论和现代企业管理基本理论的培训。 4.3.1 培训的内容： a ) ISO9000 质量体系基本理论培训(2000 版国家标准) ； b ) 内审员培训； c ) 行为科学培训；

公司企业品质部2017年工作总结及2018年工作计划及打算目标

公司企业2017年品质部工作总结及2018年品质部工作计划及打算目标 2017年品质部工作总结及2018年 工作计划及重点 (说明：此文为WORD文档，下载后可直接使用)

目录 一．部门组织架构和人员状况 二．部门的工作职责 三．2018年度的主要工作内容四．2017年存在的不足和改善的方案五：2018年的成本控制计划 六．总结和本年度的目标

一．部门组织架构和人员状况 品质部目前人力配置满员编制为人数:43人 副经理：1人、科长：1人 工程师:8人(包括SQE\体系工程师\高级工程师\QE\PQE); 文员:2人(DCC 和品质) 组长:7人(包括IQC\OQC\注塑\喷涂\丝印 A\B 班) QC:24人(包括IQC\OQC\注塑\喷涂\丝印A\B 班\2名驻厂人员) 目前品质部组织架构 新的一年品质部将对公司内部的品质管控系统进行重新调整，品质部门的组织架构也要进行重新规划，预计的补足现有的组织架构人员外，因2018年客户群的提升，所以供应商管理与客户维护是我们的工作重点，所以在组织架构上面加入厂商及客户驻厂技术员职位。 新的组织架构： 品质副经理 ISO 工程师 高级品质 SQE 品质 IQC/OQC 组DQE 工程师 注塑QC 组长 喷涂/组装/丝喷涂/组装/丝印 注塑/压铸 IQC(1人) OQC(2人)品质文员 品质课长 DCC 文员 PQE 工程师 客户驻厂

目前由于生产人员的不稳定，导致生产过程中不良产生较多，流入客户处的不良也较多，还有外发加工厂品质不稳定给公司造成了巨大的损失，外发加工厂的品质控制工作成为了重中之重，而品质部职责范围甚广，包括：进料，产线，入库，出货，投诉处理，供应商辅导，还要包括体系完善，部门建立等，所以人员的合理利用和调配成为了工作的重心。 二.部门职责 为贯彻质量管理体系，促进公司产品品质管理及质量改善活动，保证为客户提供满意的产品及优质的服务，以达到公司利益最大化，暂定以下职责： 1，贯彻公司质量方针，不断完善公司质量保证体系文件，确保ISO9001：2008质量管理体系能持续运行并有效执行； 2，根据公司质量目标，督导各部门建立相关品质目标，负责对各部门的品质管理工作进行评估，并根据实际业绩和生产情况组织检讨，规划； 3，负责公司各种品质管理制度的制订与实施，组织与推进各种品质改善活动。 4，建立质量管理责任制，落实到各相关部门（人），建立并完善品质考核制度办法，执行“每一道工序严格把关，做到人人有职责，事事有依据，作业有标准，层层有监督”； 5，制定本部门考核制度，组织实施绩效管理；并提供各项质量问题统计数据，配合公司对各部门绩效考核过程进行监督； 7，制定质量管理培训计划，开展全面的质量管理教育活动。定期组织检验员、管理人员、操作员等不同岗位的质量教育培训，强化质量管理，提高公司全员质量意识和质量管理水平； 8，加强对有关国际，国家或行业标准及技术要求等信息的收集、整理，然后发行到相关部门及人员学习掌握，并落实执行； 9，参与特殊订单的审核与产品设计评估，并制定出相应的检验规范以及质量控制计划； 10，负责样品的检验，将检验结果反馈到相关部门，促进项目改善，并按照质量控制计划归档相关文件； 11，落实供应商的质量管理，参与公司合格供应商的评定；对供应商进行有效的管控及辅导监督。 12，按照规定的作业流程，参考检验标准或检验规范对原辅材料，外协品，半成品及成品进行检验，巡视检验，形成书面检验记录反馈相关部门； 13，配合业务课进行客户投诉处理，主导异常原因分析并将改善措施切实执行，验证，减少内外部客户投诉，不断提高客户满意度；

物业品质部述职报告

物业品质部述职报告 公司领导： 品质培训部XX年各项工作有条不紊进行。现将本年度具体工作总结汇报如下： (一)规范维修、客服、环境等文件档案管理 先后三次组织各物业处经理、项目负责人、维修、客服、办公室相关人员进行文件规范化管理培训与交流，以质量标准体系为依据，针对各项目文件管理方面存在的问题，如记录不完善、归档不及时等进行限期整改、完善，为内审、外审工作顺利进行奠定基础，促进了物业管理的标准化和规范化 (二)三级责任状管理办法的制定与实施 制定了物业总公司三级责任状管理办法，以“安全第一，预防为主”为指导方针，依照“谁主管，谁负责”的职责定位，执行“三级安全管理”。物业总公司对集团、项目经理对总公司、主管对项目经理、员工对主管分别签订责任状。 先后与15个物业处经理、3个职能部门经理负责人签订了责任状。签订责任状后，增强了各项目负责人的安全管理意识，有效降低了企业风险。统计显示，XX年度仅发生一起工伤事故。责任状的签订，对物业总公司范围内各项工作良性发展有积极意义。 (三)经理绩效季度考核工作 制定了《项目经理季度考核实施办法》《项目经理绩效考核内容及评分细则》《职能部门经理绩效考核内容及评分细则》，二、三、四季度分别对项目经理和职能部门经理进行了季度考核工作。 通过对各项目经理季度工作的实际情况评估，将月度绩效工资的发放与实际工作业绩紧密结合起来。利用绩效工资的激励性，提高了经理的工作积极性，对服务品质的提升有一定的推动作用。 (四)项目创优工作

依据评优标准，品质培训部主要围绕整改做相关工作： 1.创优整改 围绕评优标准，制定创优整改850多条，全程跟踪完成情况，累计抽查整改完成项300余项。 2.培训交流 组织创优项目员工培训、参观、交流计逾100人次，为进一步规范各种作业记录、提升服务标准起到了促进作用。 3.创优资料规范 围绕创优汇报PPT及创优资料整理，完成品质部修订、审核、定稿材料10余套。 4.设备房规范 对4个创优项目的设备房进行规范，更换、悬挂设备标识牌以及安全生产标识牌300余块，并对地面统一进行刷漆，清除设备锈迹、上油、刷漆保养，规范了设备房维修、巡查等记录表格。 (五)公司内审与外审工作 根据贯标认证工作整改要求，组织物业相关人员对XX、XX、XX、XX和XX 物业处进行了内部审核，验证公司质量环境体系及覆盖产品是否符合 ISO9001;XX、ISO14001;XX标准规定的要求。内审后，XX物业处作为各物业处代表，顺利通过了专家组的外审工作。内审与外审工作的顺利通过，确认了物业公司质量环境质量体系的符合性和有效性。 (六)住户xx调查工作 组织各物业处部分房管、秩序队员协助进行XX年度业主满意度调查，上、下半年各一次。组织入户调查180多人次，发放入户问卷8850份;统计整理业主合理化建议600余项，并下发各处制定计划整改。从统计结果看，XX年住户满意度整体保持97以上(比去年有所提升)。

Hibernate中Criteria的完整用法

QBE (Query By Example) Criteria cri = session.createCriteria(Student.class); cri.add(Example.create(s)); //s是一个Student对象 list cri.list(); 实质：创建一个模版，比如我有一个表serial有一个giftortoy字段，我设置serial.setgifttoy("2"), 则这个表中的所有的giftortoy为2的数据都会出来 2: QBC (Query By Criteria) 主要有Criteria,Criterion,Oder,Restrictions类组成 session = this.getSession(); Criteria cri = session.createCriteria(JdItemSerialnumber.class); Criterion cron = Restrictions.like("customer",name); cri.add(cron); list = cri.list(); ============================== 比较运算符 HQL运算符QBC运算符含义 = Restrictions.eq() 等于 <> Restrictions.not(Exprission.eq()) 不等于 > Restrictions.gt() 大于 >= Restrictions.ge() 大于等于 < Restrictions.lt() 小于 <= Restrictions.le() 小于等于 is null Restrictions.isnull() 等于空值 is not null Restrictions.isNotNull() 非空值 like Restrictions.like() 字符串模式匹配 and Restrictions.and() 逻辑与 and Restrictions.conjunction() 逻辑与 or Restrictions.or() 逻辑或 or Restrictions.disjunction() 逻辑或 not Restrictions.not() 逻辑非 in(列表) Restrictions.in() 等于列表中的某一个值 ont in(列表) Restrictions.not(Restrictions.in())不等于列表中任意一个值 between x and y Restrictions.between() 闭区间xy中的任意值 not between x and y Restrictions.not(Restrictions..between()) 小于值X或者大于值y 3: HQL String hql = "select https://www.wendangku.net/doc/324597769.html, ,avg(s.age) from Student s group by https://www.wendangku.net/doc/324597769.html,"; Query query = session.createQuery(hql); list = query.list(); .... 4: 本地SQL查询 session = sessionFactory.openSession(); tran = session.beginTransaction();

质量管理部度工作总结及计划

第三章：质量管理部月度工作计划制定管理办法 1.目的 为了提高质量管理部的工作效率，增强质量管理部工作的主动性，使质量管理部工作有条不紊的进行，特制定本管理办法，同时月度计划的工作进度和质量作为月度绩效的考核标准。 2.范围 适用于质量保证QA所有人员。 适用于质量控制QC各检验岗位人员、文件专员、样品及标准品岗位人员。 3.职责 质量管理部人员需按照此管理办法每月制定月度工作计划，并按计划进行实施，质量管理部各级负责人监督、跟踪计划执行情况。 4.程序 工作计划的制定 每月月底质量管理部人员需制定月度工作计划，计划依据各自岗位工作内容及阶段性重点开展的工作制定，计划制定的标准遵循SMART原则。 S—specific目标一定要明确，不可含糊。 M—measurable制定目标一定是可度量的。

attainable目标一定是可以实现的。 R—rusult based目标应是结果导向型的。 T—time based执行、完成是有时效性的。 工作计划制定的内容 各级人员工作计划的制定依据各自岗位职责、公司及部门年度计划、部门阶段性重点开展的工作制定，遵循5W2H原则。 W：WHY，为什么？为什么要这么做？理由何在？原因是什么？ W：WHAT，是什么？目的是什么？做什么工作？ W：WHERE，何处？在哪里做？从哪里入手？ W：WHEN，何时？什么时间完成？什么时机最适宜？ W：WHO，谁？由谁来承担？谁来完成？谁负责？ H：HOW，怎样做？怎么做？如何提高效率？如何实施？方法怎样？ H：HOW MUCH，多少？做到什么程度？数量如何？质量水平如何？ 费用产出如何？ 工作计划的审核 质量管理部经理每月将制定的月度计划交由质量总监审核。

物业公司品质部工作计划范本

Clear objectives, matters, methods and record progress, so as to make planning direction consistent, action coordinated and orderly. 姓名：___________________ 单位：___________________ 时间：___________________ 物业公司品质部工作计划

编号：FS-DY-27486 物业公司品质部工作计划 为了做好品质管理部各项工作，达到公司要求的发展目标，现将20XX年度工作计划安排如下： 1月份： 1)完成体系文件的管理评审工作，保证满足体系认证的符合性; 2)准备公司物业资质申报工作，并做好相关的工作; 3)加强与业主的沟通，制定公司工作简报; 2月份： 1)2月底完成体系文件的第二次内审工作;并及时整改和关闭不合格项，力求体系文件运行的完好性; 2)确保大厦评优资料的全面和完整性，有必要向市局提出书面性报告，并协助相关资料的移交工作; 3)完善公司规章制度的内部建设，确保公司工作开展的正常运作;

3月份： 1)做好一切ISO9000质量认证体系的准备工作，并保证认证工作顺利的通过; 2)做好大厦评"区优"的申报工作，同时完善好评优资料的创建工作; 4月至6月： 1)做好评优工作的各项准备，迎接"区优"的评审工作;保证"区优"评比工作顺利通过; 2)持续改进体系文件的适用性和可操作性;并按要求深入工作现场，做好体系文件正常的运行工作; 3)做好用户意见调查工作，分析用户的需求，客观评价用户的满意度，并提出预防纠正整改措施; 7月至9月： 1)做好市优创建的准备工作和市优申报工作，以"市优"标准整理相关的评优资料; 2)全面展开体系文件的内审工作和管理评审工作; 10月至12月： 1)完成体系文件运行的复审工作;

presentation evaluation criteria

Professional Studies Presentation Evaluation Criteria The numbers in the top of the boxes are points in a continuum. For example, you can assign 20 points for Organization. As long as you do not give more points than suggested in the leftmost box, the score will range between 0 and 100 when you add up the numbers. Organization (20%) 20 Consistently clear, concise, well organized. Points were easy to follow because of the organization. Transitions between sections smooth and coordinated. 15Usually clear, concise, well organized. Most of the presentation was easy to follow. Transitions between sections usually coordinated. 10Not always clear or concise. Organization was adequate, but weak. Occasionally wandered and was sometimes difficult to follow. Transitions between sections weak. 5Often unclear and disorganized, rambled too much. The presentation was confusing and difficult to follow. Transitions between sections awkward. Topic Knowledge (20%) 20Displayed an excellent grasp of the material. Demonstrated excellent mastery of content, application and implications. Excellent research depth. 15Displayed a general grasp of the material. Demonstrated good mastery of content, application and implications. Good research depth. 10Displayed some grasp of the material. Demonstrated adequate mastery of content, application and implications. Research not very deep. 5Displayed a poor grasp of the material. Demonstrated a superficial handling of content, application and implications. Little depth of research. Creativity (10%) 10Very creative and original. Imaginative design and use of materials. Novel handouts, visual aids, or methods. 8 Exhibited some originality and creativity. 5 Routine treatment, minimal thought given to originality or creativity. 3Lacked creativity. Very ordinary and mundane. Visual Aids (15%) 15Simple, clear, easy to interpret, easy to read. Well coordinated with content, well designed, used very effectively. Excellent example of how to prepare and use good visual aids 11Usually clear, easy to interpret, easy to read. Generally well coordinated with content, design was okay, generally used effectively. Demonstrated some understanding of how to use visual aids. 8 Marginally acceptable, too complex, crowded, difficult to read or interpret. Adequate coordination with content. Used only adequately. Showed little understanding of how to prepare and use visual aids. 4Poor quality visual aids (or none), hard to read, technically inaccurate, poorly constructed. Poor coordination with content. Used poorly. The presenter did not seem to know how to prepare or use visual aids effectively. Summary (15%) 15Clear, concise, major points emphasized, clear recommendations, strong conclusion or call for action. 11Referred to main points, recommendations weak or missing, weak conclusion or call for action. 8Vague mention of major points, no recommendations, weak conclusion, weak or no call for action. 4No summary, no recommendations, no conclusions, no call for action. Stage Presence (20%) 20 Excellent stage presence. Confident, used notes well, at ease, excellent gestures, good audience attention, good eye contact. 15Good stage presence. Fairly confident, used notes fairly well, good gestures, acceptable audience attention and eye contact. 10 Adequate stage presence. Read parts, fumbled with notes, several distracting mannerisms, minimal gestures, minimal eye contact, too many um=s. 5Poor stage presence. Unprepared, awkward, shuffled papers, poor eye contact, lots of um=s, turned from audience to read overheads, shuffled feet, fidgeted. Poor gestures. TOTAL POINTS COMMENTS:

品质部年度工作总结(最新篇)

品质部年度工作总结 品质部年度工作总结 在平谷工地等事项上存在不规范之处，于xx月份对公司所有产品的外包装材料的标识全部进行规范; 二、原材料外购件进厂检测 部门加强了对原材料外购件的质量监控： 对纳入ISO质量管理体系的所有原材料外购件全部进行跟踪检测。本年度因各种原辅材料价格上涨，导致部分原辅料品质下滑，质量部加强了对原材料、外购件的检验把关。其中原材料大部分采取折价让步接收处理，也给后续加工效率带来一定困扰。还是需要加大对原材料的监管力度，严格执行退货制度，确保原材料质量的提升;对于外购件质量部积极与同行交流，加强数据对比，每月对进厂外购件抽查多次。有效地减少了检验误差，但在采样、制样上还需进一步提升，以保证检测数据的及时性和权威性。 三、质量检测分析 这一块是质量部的主体工作。在20xx年生产负荷一直处于变动之中，生产不稳定性因素增加，各项检测工作也大大增加： 根据质量部质检员的统计，本年度1至xx月份一次交验合格率如下： 根据以上柱状图统计情况来看，公司生产过程产品的一次交验合格率在9 9.6%以上，稳中有提高，已超过年初预定目标，这说明我们的质量管理体系的执行是健全、有效、合适的。图中

1、 3、 4、 5、 8、xx月份均出现不同数量的不合格品，这几个月虽然生产时间紧，任务重，但这并不能成为降低质量要求的理由，越是这样种情形下越应做好自检、互检、专检。严格按照生产技术要求制作，按照质量要求自检、互检，认真负责的将合格的半成品转交给下道工序进行制作，力争把好每一道关。 今年半成品数量大，往往在入库码放过程中有擦刮掉漆现象。有时因现场原定进场时间有变动，要推迟发货时间，使得产成品、半成品在成品库里日晒雨淋导致褪色，虽有补漆措施，但也使得产品外观质量受到影响。这是我们今后生产中应特别注意的地方，多角度想问题，才能把工作做的更全面，提高自身的责任意识，时时处处从思想到行动都明确质量就是市场。再好的内在质量产品外观有瑕疵，也将被市场淘汰，我们始终坚信产品质量是生产出来的，只要生产部的每一个员工都有高度的质量意识，并付诸于生产操作的每一环节中，产品质量将会稳步提高，以达到满足客户质量要求的目标。为此我们还必须进一步加强生产过程中各环节的管理，使我们的生产水平、产品质量有新的突破。 四、成品检验包装 公司的主要产品是除尘器，成检车间是除尘器产品质量把关的最后一道工序，直接面对客户，其责任重大。公司于20xx克服了人员紧张，包装场地狭小，产品规格批号多的困难，出色地完成了除尘器成

物业公司及品质部职能

物业公司及品质部职能 Document number【AA80KGB-AA98YT-AAT8CB-2A6UT-A18GG】

一、物业公司区域管理中心职能 (一)全面负责区域内服务中心各项服务指标、经营指标的落实 1、落实安防、环境保洁、机电设备、客服等服务指标； 2、落实物业管理费、停车费、水费等经济指标； （二）结合实际情况制订合理组织架构，资源共享 1、制订辖下各物业服务中心组织架构，并报公司批准； 2、负责辖下各物业服务中心人员编制及岗位的申报； 3、负责辖下各物业服务中心人员的调配、安排的审核； （三）全面协调公司内部各部门工作，配合公司的各项工作计划的执行 1、负责与公司各部门相互沟通，协调处理小区事务； 2、落实公司的工作计划； 3配合品质部对辖下各物业服务中心实施绩效考核； （四）协调相关政府职能部门关系 1、协调供水、供电、有线电视、街道办事处、派出所等单位的关系； 2、与政府职能部门沟通，处理与小区日常管理有关的事务； （五）负责对区域内各服务中心主任考核监督 1、带领辖下各物业服务中心主任开展工作； 2、对辖下各物业服务中心主任工作成效进行考核； 3、指导辖下各物业服务中心月绩效考核工作的开展； （六）完成集团公司下达的其他任务 二、品质部职能 （一）从安全管理、客服管理、工程管理方面对各服务中心进行业务指导与技术支持 1、对各服务中心的安防管理工作进行指导； 2、对各小区工程问题及开发配套完善工作给予支持； 3、对各服务中心客服工作进行指导； （二）负责物业前期介入、物业招投标、管理费测算、前期接管方面工作

1、参与各个项目物业规划、设备选型等方面配合建议； 2、参与物业管理招投标工作； 3、业主收楼前将项目移交给各物业服务中心； （三）通过收集业主投诉及意见、现场检查督导找出各服务中心存在的差距，提出整改要求，并落实责任人，及完成时间 1、接收业主的投诉及意见； 2、组织对各小区物业管理工作情况的检查； 3、跟踪与落实各小区相关责任人进行按要求整改； （四）收集、建立各物业工程资料、客户资料、楼盘资料等物业管理所需要的资料 （五）统一对各物业设施、设备建档管理，并签订设备、设施维修保养合同 1、掌握物业设施、设备有关情况，并进行建档管理； 2、签订维修保养合同，对设施设备进行养护； 3、定期组织对设备、设施运行情况的检查； （六）各业务线条员工岗前培训，配合公司定期组织业务培训 1、组织对电工、安防人员进行岗前培训； 2、配合公司定期组织专业培训，提高员工业务技能； （七）每月定期组织公司品质检查，严格贯彻公司品质检查制度，做到公平、公正 1、制订月度检查考核计划； 2、按照品质检查制度，组织对各小区物业管理质量进行绩效考核； 3、汇总各服务中心品质检查得分，编写和丰物业服务质量月报； 4、列出各服务中心得分，报人事行政部存档并作做为员工绩效考核依据；（八）协助集团营销中心加强售楼处安防、保洁及接待、形象方面工作（九）开展社区文化建设 1、负责社区文化活动的策划、报批工作； 2、负责组织实施社区文化活动。

品质部个人2016年工作总结和计划

工作总结与计划 2016这一年来在公司领导的信任和同事们的帮助下，通过扎实的努力在工作中得到了很好的锻炼，非常感谢公司给我一个成长的平台，让我在工作中学到更多的知识，同时也认识到自己存在诸多不足，现就2016年重点工作做如下汇报： 一、管理体系认证工作 1、内审工作 月日至日在公司参加为期三天关于管理体系的培训，并参加考试。通过本次培训学习，加强了对管理体系的认知和理解，并运用到内审工作中。月日分别对最高领导者、管理者代表、财务部、秩序维护部、品质部、服务中心按照内部审核程序进行内审，并在王经理带领下与部门同事一起对管理评审资料进行输入汇总，最后做管理评审总结报告。 2、外审工作 月日及5月20日至21日分别进行了第一阶段外审、第二阶段的外审，外审过程中陪同外审老师按照根据管理体系标准要求、在审查范围内按流程采用抽样方法进行审核，并对外审老师提出的问题做记录。与部门同事一起对外审第一阶段问题清单进行整理，并传至各部门完善相关资料。对第二阶段提出的不符合项及时做了纠正及预防措施报告，已于月日前完成验证，并将整改报告及改善效果报于认证老师，月日顺利取得由济南方圆认证中心颁发的质量、环境、职业健康安全管理体系认证证书。 通过此次管理体系认证，促使公司各部门基础管理向更科学化、更规范方向迈进，促进了工作各方面的完善，提高了工作效率。 二、月度检查考核工作 在经理带领下，按照管理体系标准要求，遵循各手册作业指导，

围绕质量控制展开工作，监督落实认证体系文件的使用执行情况。每月做月度检查考核计划表，并报领导审批，审批后按照计划时间安排通知各服务中心，对综合管理、客服管理、秩序维护管理、工程维修管理、环境绿化管理进行月度检查，检查中拍取各项不合格项照片,并将检查的问题反馈给各项目进行整改，对重复出现的问题开具纠正措施、预防措施处理单，并对其进行验证。 对各项目空置房情况进行检查，8月份对各项目空置房集中进行逐户检查及其他月份进行抽查，经检查大部分空置房为正常状态，其中有个别户电表或水表有走字现象，并将检查异常的报与各服务中心，服务中心对异常的做了情况说明。 通过每月的月度检查，各服务中心对检查工作较为重视，并对检查组提出的问题及时进行整改，服务品质也有明显提升。 三、公司简报校对、发行 每月对部门同事编辑的公司及各服务中心每月重点工作，（服务动态、工作动态、培训动态、物业案例、学习园地）等简报内容进行校对和修改，并交于王经理做最后审核，由王经理审核通过后，发至公司群内供各部门阅读、学习公司最新动态及先进事迹。 四、各项目未供暖户措施检查 12月1日至12月3日在经理组织下，与部门同事一起对各服务中心上报至财务的未供暖用户，进行逐户检查，主要检查各项目未供暖户是否存在偷暖现象及各项目对未供暖户是否采取接管、贴封条等措施。经检查各项目上报的全部为未供暖状态，并将检查结果进行签字确认进行汇总。该次检查表明各服务中心采取措施得当，执行有效。 通过2016年的努力工作，取得了一定的工作成绩，使自己收获了不少新的物业管理及品质管理工作，同时也认识到自己在工作上还有诸多方面的不足。2017年需要更加努力来学习、完善各项工作，2017年工作计划如下：

物业品质部工作计划(共5篇)

篇一：物业公司品质部年度工作计划 物业公司品质部年度工作计划 物业公司品质部年度工作计划提要： 一、全员服务质量管理。 出主动服务、及时服务、温馨服务。把责任制作为落实全员服务质量的关键手段。 物业公司品质部年度工作计划： (二)工作重点 一、改善职能部门为一线服务的观念,提高团队协作质量。公司的职能部门首先是服务各项目管理处,为各项目管理处提供各项支持;其次才是监控,促成项目管理处各项指标的达到。只有树立了为一线服务的理念,才能营造和谐的工作环境和团队协作关系。 二、改善业绩观。 三、改进管理方式,提高制度执行质量。多到现场去,走动管理,既有利于提高自身,又能帮助一线员工提高现场发现问题、解决问题的能力。改善干部对员工的管理方式。多了解员工的思想动态和工作状态,爱护和激发员工的工作热情和积极性。减少因管理方式不当而伤害了员工的工作热情和积极性。 四、改进在岗培训方式,提高培训质量。按照员工不同的工作范围分别选取培训内容,分开组织培训。 五、优化制度,提高制度自身可执行性质量。制订岗位职责及细节描述、工作操作手册、服务质量标准和改进绩效考核制度,完善质量监督机制等。确保各项服务工作的规范化、有序化。制度是否科学,符合实际,直接关系到制度的效用。制度的效用越高,它才更有可执行性,它才能成为员工提高服务质量的工作指南。 六、完善项目管理处制。 其次,重点致力各项目管理处服务质量的管理。 一、全员服务质量管理。把诉求服务和业主(用户)满意度作为服务质量管理的源头。突出主动服务、及时服务、温馨服务。 二、全过程的服务质量管理。 三、创造人性化的服务质量管理环境。加强企业的“精神”管理与企业的人文环境建设。为员工营造一个“快乐”的工作环境,为业主营造一个有良好人际关系和社会公德的社会环境,也是品质管理的重要目标。 发现人才,培养人才,让员工和企业共同成长,共同发展。 篇二：物业公司品质部年度工作计划1[1] 蓝天物业公司品质部年度工作计划物业公司品质部年度工作计划提要： 一、全员服务质量管理。把诉求服务和业主(用户)满意度作为服务质量管理的源头。突出主动服务、及时服务、温馨服务。把责任制作为落实全员服务质量的关键手段。 物业公司品质部年度工作计划