Supporting Distributed Collaborative Prioritization for WinWin Requirements Capture and Neg

Supporting Distributed Collaborative Prioritization for WinWin Requirements

Capture and Negotiations

Jung-Won Park, Daniel Port, Barry Boehm

University of Southern California

Center for Software Engineering

Los Angeles, CA 90089, USA

{ jungpark, dport, boehm } @ https://www.wendangku.net/doc/da2893756.html,

Hoh In

Texas A&M University

Computer Science Department

College Station, TX 77843-3112, USA

hohin@https://www.wendangku.net/doc/da2893756.html,

ABSTRACT

One of the most common problems within a risk driven software collaborative development effort is prioritizing items such as requirements, goals, and stakeholder win-conditions. Requirements have proven particularly sticky in this as it is often the case that they can not be fully implemented when time and resources are limited introducing additional risk to the project. A practical approach to mitigating this risk in alignment with the WinWin development approach is to have the critical stakeholders for the project collaboratively negotiate requirements into priority bins which then are scheduled into an appropriate incremental development life cycle. We have constructed a system called the Distributed Collaboration Priorities Tool (DCPT) to assist in collaborative prioritization of development items. DCPT offers a structurally guided approach to collaborative prioritization much in the spirit of USC’s WinWin requirements capture and negotiation system. In this paper, we will discuss the prioritization models implemented within DCPT via an actual prioritization of new WinWin system features. We also discuss DCPT’s two-way integration with WinWin system, some experiences using DCPT, and current research directions.

Keywords: Prioritization, WinWin, Requirement Capture, Requirement Negotiation, Distributed System, Risk Assessment and Management.

1. INTRODUCTION

Prioritizing software development items such as requirements, goals, and stakeholder win-conditions is important yet often neglected part of the development process. Frequently items must be prioritized up or down based on a multitude of complex factors that are amortized across many stakeholders. Under such conditions it is important not only to explicitly prioritize the items, but also to ensure stakeholder concurrence. Failure to do so may introduce critical risk [6] into the project. For example it is common for a project to have more requirements than can be fully implemented within a limited schedule and budget. Implementing requirements under these conditions optimistically expecting a result that is mutually satisfactory to all stakeholders is nearly absurd. In such a case it is inevitable that some requirements will not be fully implemented and the developer is usually left to decide which requirements will be scaled down or dropped. All too often this is done in a panic as a deadline approaches or the budget burns up. Even if a developer is provided priorities, there are too many complex factors that a developer does not or can not account for in order to mitigate the critical risk of not implementing an acceptable subset of the requirements. There must be a balance between stakeholder priorities such as described by Royce [7] in principle 16 of “the old way and the new” software engineering principles. An approach to this difficulty is to incorporate early input of the critical stakeholders through prioritization and to avoid “late risk resolution” - also described by Royce [7] as one of the top five conventional management flaws.

Prioritization approaches have proven to be effective, yet cumbersome. The general approach is to have all stakeholders negotiate the relative priority of a set of items through negotiation in the same place at the same time. This is often not practical within many software development projects where stakeholders (including developers) are highly distributed and have greatly conflicting schedules. Naturally this problem sharply increases with the number of people. Even under ideal conditions, the true value of prioritization is never realized due to “collaborative memory loss.” Here vital information generated through discussion and interaction of the stakeholders slips into a veritable black hole. If (i.e. when) requirements need to be re-negotiated, the lost information may need to be re-created at great effort and loss of integrity and original intent.

Prior work in this area that simply records collaborations are well known to generate massive quantities of data wherein the essential information is forever buried thus impractical for use. No guidance or support (such as conflict identification) is provided to drive the process or utilize the results. Other prioritization systems tend to focus on a particular voting scheme or prioritization model, avoiding the important issue of rationale capture and adaptation to project needs. Also missing is a basic foundation that defines the prioritization model, its assumptions, and its consequences. The goal of DCPT is to address these issues in a practical and effective manner within the scope of software engineering. Although

there exist numerous approaches within the business management context, they are too general to accommodate the particularities of software engineering practice. It is this limited scope however that makes this an interesting research area and allows for the creation and application of practical tools. Throughout the paper will give examples of an actual usage of DCPT for prioritizing new requirements for USC’s popular WinWin system.

2. RELATED WORK

Relatively few research efforts have been done on the area of requirement prioritization and application to the software development process [1]. Some recent work by J. Karlsson and K. Ryan [2, 3] uses the Analytic Hierarchy Process (AHP) [10] to prioritize each requirement’s relative value and implementation cost, which are then plotted on a cost-value diagram. H. Jung extended Karlsson and Ryan’s work with a variant of the 0-1-knapsack model that reduces the complexity of prioritization in cases of a system with many requirements or closely grouped cost-value points [4]. However, even if above systems prove useful in examples, they have inherent limitations. Some of these limitations have to do with implicit assumptions of the prioritization model, which may not be in alignment with stakeholder needs. For example the use of fixed priority bins, an issue we will discuss in detail later. Related prioritization systems also do not accommodate multiple prioritization models that may be in better alignment with stakeholder needs; e.g. Jung and Karlsson only use the pair-wise comparison model using AHP. DCPT integrates multiple voting and bin (classification) models, and very unlike prior work, an explicit risk model. This is of increasing importance within software engineering as more developers adopt iterative risk-driven development lifecycles [6]. At a more fundamental level, related efforts neither provide a facility to capture rationale nor address issues of priority ambiguity and resolution – both major sources of difficulty in making effective use of prioritization. Furthermore, related works in this area are not concerned with distribution. That is, enabling collaboration of non co-located stakeholders to interact asynchronously. Although our system by design addresses this, admittedly only in a limited way at present and we have yet to deal with the more complex and subtle issues of distribution. In the following sections, we will discuss the WinWin system and the Distributed Collaboration Priorities Tool (DCPT). We also discuss prioritization models and show how our DCPT uses these models and address the limitations described above.

3. WINWIN WinWin is a distributed system (implemented in C and Visual Basic) for the collaborative negotiation of requirements. WinWin uses Theory W - Make Everyone a Winner - as its negotiation model [8]. Developed at the USC Center for Software Engineering, WinWin has been applied to the WinWin negotiation process [9] using the WinWin2.0 negotiation tool for facilitating the negotiation of requirements for geographically and temporally distributed stakeholders. Stakeholders write their pre-requirements in the form of Win Conditions. Conflicts or concerns of the satisfaction of Win Conditions are raised as Issues that are addressed by Options. Options are considered and ultimately stakeholders propose Agreements to adopt Options and Issues which then become requirements. Through three years of use on customer based projects within USC's graduate level software engineering course (CS577), WinWin has proven useful, yet not devoid of concerns. The class projects are relatively small with between 6-18 Win Conditions and 4-7 stakeholders. We have noted that if the number of stakeholders or the number of win conditions is increased, the WinWin process tends to stall and agreements become difficult to achieve [9]. Utilizing the large amount of information captured through WinWin to create actual project requirements has also proven difficult.

4. DCPT

DCPT is a distributed client-server based system (implemented in Java) used in the collaborative prioritization of development items and risk reduction. Stakeholders assign each item a difficulty and importance (or a probability and loss) for which summary statistics are generated and used to place the items into priority bins that classify them into a relative prioritization. Figure 1 shows the snapshot of DCPT. DCPT has four basic panels. Top left and top right panels are item vote summaries. Each panel represents a particular item for which each stakeholders vote is plotted on the value-pair grid along with the initials of the stakeholder. The ellipse indicates the area of consensus between the votes for that item. The size and shape of this ellipse summarizes the degree and directions of disparity amongst the votes. A votes exact value-pair and rationale can be viewed simply by moving the mouse over the vote of interest. The line shows the linear least squares fit of the value-pairs. Two panels are shown for pair-wise comparison of the items. The bottom left panel is used for displaying the relative priorities according to the bin models. Bottom right panel is the result of the prioritization with respect to the bin model selected. An item is placed in the overlap column when the area of consensus of the item does not entirely within a bin area fall (there is a tolerance adjustment that we have set very high for the screenshot examples to avoid a cluttered display).

Fig. 1. Distributed Collaboration Priorities Tool (DCPT) snapshot. The diagonal bin model is used indicating that item 1 is in bin I, items 2 and 3 in bin II, items 4, 5, and 6 in bin III.

5. PRIORITIZATION MODELS: VOTING AND BINS Prioritization within Software Engineering

The Webster’s dictionary defines priority as:

…superiority in rank, position, or privilege, …a

preferential rating; especially one that allocates

rights to goods and services usually in limited

supply, …something given or meriting attention

before competing alternatives.

Then prioritization is defined as “to list or rate (as projects or goals) in order of priority”. For the remainder of the paper we will use requirements as the items to be prioritized. Other software development items such as goals, win conditions and so forth could be substituted easily with only minor modifications. Within software engineering the definition of prioritization translates into choosing an ordered partition of the requirements with respect to the tradeoffs and constraints of the project. In spirit this is an application of the classic “divide, order, and conquer” paradigm. The goal is to minimize overall risk (through reduced complexity) by identifying classifications and an ordering that maximize satisfaction over all the stakeholders.

The satisfaction aspect requires input from the stakeholders. One way to do this is have stakeholders assign judgements through voting on the items. Judgements vary, but must include some form of comparison with an absolute (i.e. a value assignment) or relative to the requirements, such as pair-wise comparison. The votes are then summarized according to some agreed upon policy (such as majority rules, average value, median) and then a value is assigned to the requirement. This only deals with part of what is needed for a prioritization. Requirements eventually must be grouped with respect to some model based on the voting. Example groupings are “high, medium, low” or “priority I, II, III”. These groupings are what we will refer to as priority bins. A prioritization model is the combination of a voting model and a bin model.

DCPT uses four different kinds of bin models: the average bin model, the ratio model, the diagonal model, and the risk assessment model. An important feature of these bin models is that the bin locations and sizes are adjusted relative to the vote values of the items. This in contrast to fixed bins, where bin locations are arbitrarily chosen and have no direct relation to the particular values assigned to the items. This we will see enables a more meaningful prioritization and avoids such problems as all items falling into a single bin. At present DCPT accommodates only one voting model where stakeholders assign a pair of values between 0-10 as to their assessment of the relative importance and difficulty, or the relative probability and loss for a given requirement. The voting scheme is used to assign importance-difficulty (benefit-cost) values and the probability-loss (risk) values to requirements. The two value assignments are not necessarily totally orthogonal, yet they still provide an important new dimension in which to form valuable (i.e. risk minimizing, satisfaction maximizing) prioritization. We will soon support pair-wise comparison (AHP) and finite budget voting model (points). The exact relationship between different voting models and how it affects bin choice and disambiguating requirements into bins is an important active area of our current research.

The Voting Model

A stakeholder votes by logging into the DCPT server after which a voting display is presented. The stakeholder selects an item in which to assign a difficulty and importance value pair. Simply moving the cursor to the point on the grid that represents their judgement and pressing the mouse button makes the value pair assignment. To change a vote, the stakeholder moves the mouse over the point to be changed and drags it to a new location. If any vote requires additional notes or rationale, it can be entered in the notes text box. The figure below shows an Importance-Difficulty voting on items 1,2,4,6 from the list at the top (where item 1 is the currently selected item). Note how the stakeholder can visually asses the relative importance (or benefit) of items and the relative difficulty (or cost) of all the items he has an interest in. It is not required that a stakeholder vote on all the items. A stakeholder can access the system anytime and from any location, thereby addressing a simple distribution issue. At present DCPT handles notification of issues through its integration with the

WinWin system.

Fig 2. Voting on Importance-Difficulty (Benefit-Cost) for WinWin new feature requirements.

Bin Model

In this section we describe the currently supported bin models, their assumptions, and application to the prioritization. Given a set of assumptions on the relationship between difficulty and importance, bin models represent various ways in which the value-pair grid is to be partitioned. The regions in which the grid is partitioned are assigned bin labels. Currently DCPT supports partitions into exactly four regions which are labeled I, II, III, and IV. When a requirements summary vote value places it in on the grid, it falls within one of the regions. DCPT bin models only place items into bins according to a voting model. The stakeholders must determine the ordering of the bins with respect to an individual project. For example, a-priori why should an item placed in bin II have higher priority over an item placed in bin III? It should not unless we prefer importance to difficulty.

Average Bin Model:This model provides independent baselines for importance and difficulty. The base is set by the average value whereby there are an approximately equal number of items above and below the baseline. The horizontal line near Importance 7 indicates the average of importance of items and items 4,5,6 are above and 1,2,3 below. The vertical line near Difficulty 6 indicates the average of difficulty of items with 1,2,3 to the left, and 4,5,6 to the right. Although there are not equal numbers of items in each bin, there are equal numbers above and below the baselines.Fig. 3. Average Bin Model. Numbers within a square indicates the prioritization item number. Item 1 is ambiguous which may belong to Region 1 or Region III. Item 4, 5, and 6 belongs to Region II. Item 2 and 3 belongs to Region III.

Ratio Bin Model: The ratio bin model partitions the grid into regions based on baselines where importance over difficulty is a constant. The baseline is set where importance / difficulty = (average importance) / (average difficulty). The other regions are determined by adding and subtracting a value of 0-3 standard deviations (fractions allowed) of the importance and difficulty from the numerator and denominator respectively. This model is similar to Karlsson and Ryan’s cost-value model [3], which can be, interpreted as Return-On-Investment (ROI). However, in their work the regions were fixed rather than relative to the averages as described above. Fig. 4. Ratio Model. Item 1 has the largest Return-On-Investment (ROI). Item 2 has a medium ROI. Items 3, 4, 5,

and 6 have the relatively small ROI.

Diagonal Bin Model: This model assumes that importance and difficulty are exchangeable in which the importance minus the difficulty is constant. The baseline is where importance - difficulty = average importance - average difficulty. The other bases are set at this value plus or minus the sum of 0-3 standard deviations of the importance and difficulty. This model can be interpreted as Net Value [5]. Fig. 5. Diagonal Model. Item 1 has the largest net value. Item 2 has the second. Item 3, 4, have third largest net value. Item 5 is ambiguous. Item 6 has the lowest net value.

Risk Bin Model: This model can be used for assessing relative risk of the requirements based on the importance-difficulty value-pairs and additional stakeholder judgements, or an algorithmic determination from theoretical considerations. The latter is complex and highly experimental, but is loosely based on COCOMO approaches to effort and risk determination [5]. At present we do not have much theoretical basis to draw upon. What we do know is that there are important relationships between risk and prioritization (see future work section.) The generally accepted evaluation of risk of individual independent requirements is the product of probability of the risk occurring and the loss of the outcome if the risk occurs (i.e., risk = probability * loss). Figure 6 then illustrates the risk exposure of prioritization items [6]. The regions are partitioned according to contours of constant risk exposure where the probability of loss times the cost of loss is constant. The baseline is set at the average probability of loss times the average cost of loss. The other regions are chosen to be 0-3 standard deviations from the baseline.

The addition of risk assessment allows for a different dimension in which to prioritize requirements. Depending on the risk tolerance of the stakeholders, the risk view will help determine an ordering and meaningful interpretation of the bins. The goal of prioritization is to minimize risk (not risk exposure necessarily) while maximizing stakeholder satisfaction (i.e. the cost-benefit).

Fig. 6. Probability-Loss (Risk Exposure) Model. Risk Exposure(RE) of item 4 over 67. RE of items 4,6 is between 41 and 67. RE of item 3 is between 20 and 41. Items 1,2 have lowest risk exposure.

6. EXPERIENCE USING DCPT AT USC

Aside from the example used in this paper, DCPT has been used to efficiently and effectively prioritize requirements for a number of development projects. We have also used DCPT to prioritize non-requirement development items. For example DCPT was used at 13th International Forum on COCOMO and Software Cost Modeling on October 6-9, 1998. At the forum, attendants wished to prioritize the COCOMO extension candidates such as COCOMO II (COnstructive COst MOdel) [11], CORADMO (COnstructive RAD MOdel), COCOTS (COnstructive COTS model), and COQUALMO (Constructive QUALity MOdel) [12]. DCPT was also used at the Focused Workshop during USC-CSE Technology Week (February 8-12, 1999). DCPT is particularly useful in workshop settings where collaboration among a large number of stakeholders must rapid and not a burden.

7. DCPT AND WINWIN

DCPT incorporates an underlying model for stakeholder voting and categorization of items that guides the collaboration effectively without being overly restrictive. Our present work focuses on an intimate two-way integration with WinWin. In this setting the WinWin system is used initially to capture possible requirements in the form of Win Conditions.

A new Win Condition is appended by DCPT (through the

WinWin API) which states that all Win Conditions should be

unambiguously placed into priority bins that indicate their priority relative to each other. The Win Conditions are extracted from WinWin and entered as items within DCPT. DCPT is used by all interested stakeholders to vote on the Win Conditions captured by WinWin. Summary statistics are used to place the items into priority bins which adjust their size dynamically to provide a true relative prioritization. Some items may be ambiguous when a sufficient consensus could not be established. In such cases DCPT will analyze the stakeholders vote data and automatically generate new WinWin Issues indicating why an item is ambiguous and how it may be in conflict with other Win Conditions. Also generated are possible Option artifacts that offer possible resolutions for the ambiguous item priority Issues. Such Options may be adopted thereby resolving the Issues and ultimately disambiguating the items. Notification of the new issues that need negotiation is handled through the WinWin system.

8. CONCLUSIONS

Although still in its infancy, DCPT has already proven to be an effective and valuable tool with respect to software engineering projects. It adapts well to a large variety of development lifecycles and enables early and continued risk reduction. At its core, the distributed voting model enables collaboration between large numbers of disparately located stakeholders. DCPT provides enough guidance through the integration of basic voting and bin models to rapidly archive a risk minimizing consensus without over constraining the projects fundamental assumptions and the workflow of the stakeholders. DCPT greatly assists in managing the complexities of a development effort through sensible prioritization. Without the use of DCPT, large prioritization collaborations are nearly impossible due to the additional complexity and as such are often neglected, introducing additional risk into a development effort. DCPT integrates naturally and easily with WinWin, and likely with other software engineering tools. Through refinements and extensions, DCPT can add attractive “agent based” issue generation and resolution that help further reduce the complexity of a prioritization task, thereby enabling the use of risk driven iterative development lifecycles. Aside from the topics discussed above, DCPT opens up the exploration into the fundamental nature of software risk management through collaboration, classification, and partitioning.

9. FUTURE WORK

Prioritization Constraints

Our current version of DCPT asks stakeholders to vote importance and difficulty at the same time. However, some stakeholders such as a typical user may not know the relative difficulty (cost) of implementing a requirement, yet still provide valuable input as to the relative importance. Similarly, some other stakeholder such as a developer may not know the relative importance (benefit) of a requirement. We are currently working on a way to handle such events. In addition, we are exploring ways to add weighting factors to the votes and handling voting by groups of stakeholders in terms of representation and weighting.

Disambiguation and Reconciliation of Item Priorities Some prioritization items may have unusual regions of consensus that non-trivially span bin partitions. We are looking into ways to provide more explicit guidance as to how such cases can be reconciled. Presently we simply place the item into an “overlap” bin and generate WinWin issue describing the nature of the ambiguity.

Handling of Prioritization Item Interdependencies

There should be a in-depth analysis of prioritization interdependencies that arise under a various conditions that implicit structural constraints on the prioritization process within software system development. We are looking into questions of how the prioritization of one item is interdependent on the prioritization of other items.

Risk Assessment and Resolution Support

As described in the introduction, one of our main objectives in prioritization was to reduce project risk by obtaining a consensus of the stakeholders as to how development effort should be focused. The assumption here being that the more stakeholders involved, the more assurance we would have of an item’s priority. We soon noticed that this introduced a form of risk in that the degree of consensus determines the level of assurance in the priority of a requirement. At present we deal with this by having an “overlap” bin. If a requirement could not unambiguously be placed into a bin (as defined by the consensus ellipse fitting entirely within a single bin model region), it is placed in the overlap bin. Subsequently, a WinWin Issue is automatically generated stating the need to negotiate stakeholder priority votes in order to resolve the ambiguity. It became clear that this was not entirely adequate, as there appears to be an intimate relationship between the priority of a requirement and its individual risk. In any attempt to resolve an ambiguity, the risk in some manner "weighs" or biases non-trivially in a way we do not understand at present. Ambiguities in risk can be defined similarly and have the same issues. Suppose a requirement’s risk exposure is ambiguous between high and medium and the majority of stakeholders deem it very important, but not difficult. This would imply a bias towards medium risk despite the actual stakeholders risk assessments, which in turn influences the priority. This only touches on the possible relationships between risk and priority. Clearly the collaborative assessment of risk is valuable for the same reasons as prioritization, yet the two combined may prove to be exceptional. The potential benefits and opportunities to apply DCPT into the risk assessment area in the future are in the following:

1.Negotiating the priority of risk resolution among multiple

stakeholders effectively through a distributed system for showing and voting on the priority of risk resolution in the spirit of USC's WinWin requirements capture and negotiation system

2.Providing the following visualization of a current

situation of risk assessment among multiple stakeholders and notifying the changes of risk assessment if stakeholders change their assessment:

?Presenting current risk assessment, voting situation and identifying the points of disagreement among

multiple stakeholders.

?Indicating the nature of consensus among the votes.

The size and shape of an ellipse indicate the degree

and directions of consensus and disparity among the

votes.

?Providing an organized view of risks based on the Risk Taxonomy.

?Managing (i.e., adding, deleting, changing, tracing, and querying) the rationales of the risk assessment

per risk item per stakeholder.

3.Providing risk-reduction guidelines for the prioritized

risk items.

?For example, a better risk-resolution strategy in Point A in Figure 7 may be to reduce risk probability

rather than loss in terms of the distance to the next

lower level of risk area. For Point B in Figure 7, a

better strategy is to reduce loss.

?Another example is that a consensus (vertical-line-like ellipse) having broad distribution of risk

probability and narrow distribution of loss requires a

focus on further sensitivity tests for determining and

verifying the risk probability.

4.Given limited resources (e.g., money, schedule, or

personnel), supporting the tradeoff analysis of resolving prioritized items

?Which one is the first to resolve risks under limited resources?

?How much should the risk items be reduced?

?How does the relationship between risk and priority affect tradeoff analysis?

Fig. 7. Risk assessment and resolution support

10. REFERENCES

[1] P. Zave, "Classification of Research Efforts in

Requirements Engineering", 2nd IEEE International

Symposium on Requirements Engineering, 1995, pp. 214-216.

[2] J. Karlsson, "Software Requirements Prioritizing",

Proceedings of ICRE 96, IEEE, pp. 110-116.

[3] J. Karlsson, K. Ryan, "A Cost-Value Approach for

Prioritizing Requirements", IEEE Software, Sept. 1997, pp. 67-74.

[4] H. Jung, "Optimizing Value and Cost in Requirements

Analysis", IEEE Software, July 1998, pp. 74-78.

[5] B. Boehm, "Software Engineering Economics", Prentice-

Hall, 1981.

[6] B. Boehm, "Software Risk Management: Principles and

Practices", IEEE Software, Jan. 1991, pp.32-41.

[7] W. Royce, "Software Project Management", Addison

Wesley, 1998.

[8] B. Boehm, R. Ross, "Theory-W Software Project

Management: Principles and Examples", IEEE

Transactions on Software Engineering, July 1989, pp. 902-916.

[9] B. Boehm, A. Egyed, "WinWin Requirements Negotiation

Process: A Multi-Project Analysis", Proceedings of the 5th International Conference on Software Processes, 1998. [10] T. Saaty, "The Analytic Hierarchy Process", McGraw-

Hill, 1980.

[11] B. Boehm, B. Clark, R. Madachy, R. Selby, C. Westland,

"Cost Models for Future Software Process: COCOMO

2.0", Annals of Software Engineering, Vol. 1, 1995. [12] S. Chulani, B. Boehm, "Modeling Software Defect

Introduction Removal: COQUALMO(COnstructive QUALity MOdel), USC-CSE Tech Report 99-510, 1999.

A

bram和dram区别

选择distributed memory generator和block memory generator标准： Dram和bram区别： 1、bram 的输出需要时钟，dram在给出地址后既可输出数据。 2、bram有较大的存储空间，是fpga定制的ram资源；而dram是逻辑单元拼出来的，浪费LUT资源 3、dram使用更灵活方便些 补充： 在Xilinx Asynchronous FIFO CORE的使用时，有两种RAM可供选择，Block memory和Distributed memory。 差别在于，前者是使用FPGA中的整块双口RAM资源，而后者则是拼凑起FPGA 中的查找表形成。 1、较大的存储应用，建议用bram；零星的小ram，一般就用dram。但这只是个一般原则，具体的使用得看整个设计中资源的冗余度和性能要求 2、dram可以是纯组合逻辑，即给出地址马上出数据，也可以加上register 变成有时钟的ram。而bram一定是有时钟的。 3、如果要产生大的FIFO或timing要求较高，就用BlockRAM。否则，就可以用Distributed RAM。 块RAM是比较大块的RAM，即使用了它的一小部分，那么整个Block RAM 就不能再用了。所以，当您要用的RAM是小的，时序要求不高的要用Distributed RAM，节省资源。 FPGA中的资源位置是固定的，例如BRAM就是一列一列分布的，这就可能造成用户逻辑和BRAM之间的route延时比较长。举个最简单的例子，在大规模FPGA 中，如果用光所有的BRAM，性能一般会下降，甚至出现route不通的情况，就是这个原因。

Distributed representations hinton1984

Carnegie Mellon University Research Showcase Computer Science Department School of Computer Science 1-1-1984 Distributed representations Geoffrey E. Hinton Carnegie Mellon University Follow this and additional works at:https://www.wendangku.net/doc/da2893756.html,/compsci This Technical Report is brought to you for free and open access by the School of Computer Science at Research Showcase. It has been accepted for inclusion in Computer Science Department by an authorized administrator of Research Showcase. For more information, please contact research- showcase@https://www.wendangku.net/doc/da2893756.html, . Recommended Citation Hinton, Geoffrey E., "Distributed representations" (1984).Computer Science Department.Paper 1842. https://www.wendangku.net/doc/da2893756.html,/compsci/1842

Distributed-Temperature-Sensor多路温度传感器大学毕业论文外文文献翻译及原文

毕业设计（论文） 外文文献翻译 文献、资料中文题目：多路温度传感器 文献、资料英文题目：Distributed Temperature Sensor 文献、资料来源： 文献、资料发表（出版）日期： 院（部）： 专业： 班级： 姓名： 学号： 指导教师： 翻译日期： 2017.02.14

毕业论文（设计）外文翻译 题目：基于单片机的多路温度采集系统设计 系部名称：专业班级： 学生姓名：学号： 指导教师：教师职称： 多路温度传感器

一温度传感器简介 1.1温度传感器的背景 在人类的生活环境中，温度扮演着极其重要的角色。无论你生活在哪里，从事什么工作，无时无刻不在与温度打着交道。自 18 世纪工业革命以来，工业发展对是否能掌握温度有着绝对的联系。在冶金、钢铁、石化、水泥、玻璃、医药等等行业，可以说几乎%80 的工业部门都不得不考虑着温度的因素。温度对于工业如此重要，由此推进了温度传感器的发展。 1.2温度传感器的发展 传感器主要大体经过了三个发展阶段：模拟集成温度传感器。该传感器是采用硅半导体集成工艺制成，因此亦称硅传感器或单片集成温度传感器。此种传感器具有功能单一(仅测量温度)、测温误差小、价格低、响应速度快、传输距离远、体积小、微功耗等，适合远距离测温、控温，不需要进行非线性校准，外围电路简单。它是目前在国内外应用最为普遍的一种集成传感器，典型产品有AD590、AD592、TMP17、LM135 等；模拟集成温度控制器。模拟集成温度控制器主要包括温控开关、可编程温度控制器，典型产品有LM56、AD22105 和 MAX6509。某些增强型集成温度控制器(例如 TC652/653)中还包含了A/D 转换器以及固化好的程序，这与智能温度传感器有某些相似之处。但它自成系统，工作时并不受微处理器的控制，这是二者的主要区别；智能温度传感器。能温度传感器(亦称数字温度传感器)是在20世纪90年代中期问世的。它是微电子技术、计算机技术和自动测试技术(ATE)的结晶。智能温度传感器内部都包含温度传感器、A/D 转换器、信号处理器、存储器(或寄存器)和接口电路。有的产品还带多路选择器、中央控制器(CPU)、随机存取存储器(RAM)和只读存储器(ROM)。智能温度传感器的特点是能输出温度数据及相关的温度控制量，适配各种微控制器(MCU)；并且它是在硬件的基础上通过软件来实现测试功能的，其智能化程度也取决于软件的开发水平。温度传感器的发展趋势。进入21世纪后，温度传感器正朝着高精度、多功能、总线标准化、高可靠性及安全性、开发虚拟传感器和网络传感器、研制单片测温系统等高科技的方向迅速发展。 1.3单点与多点温度传感器 目前市场主要存在单点和多点两种温度测量仪表。对于单点温测仪表，主要采用传统的模拟集成温度传感器，其中又以热电阻、热电偶等传感器的测量精度高，测量范围

S7 Distributed Safety F系统配置

对 F-CPU 进行组态的方式与对标准自动化系统进行组态的方式基本相同。对于 S7 Distributed Safety F 系统，还必须执行以下操作： ●组态保护级别 1。 ●组态 F 参数。 使用以下步骤组态保护级别 1： 1. 在 HW Config 中，选择 F-CPU（例如 CPU 315F-2 DP），然后选择编辑 (Edit) > 对象属性 (Object Properties) 菜单命令。 2. 打开“保护” (Protection) 选项卡。 3. 设置保护级别“1: F-CPU 的访问保护” (1: Access protection for F-CPU) 和“使用密码可删除” (Removable with Password)。 在提供的域中为 F-CPU 输入密码，并选择“CPU包含安全程序” (CPU contains safety program) 选项。请注意，“模式” (Mode) 域与安全模式无关。 使用以下操作步骤组态 F 参数： 1. 在 HW Config 中，选择 F-CPU，然后选择编辑 (Edit) > 对象属性 (Object Properties) 菜单命令。 2. 打开“F参数” (F Parameters) 选项卡。打开该选项卡后，将提示您输入安全程序的密码，或者必须在另一个对话框中设定安全程序的密码。有关安全程序密码的信息，请 参考『访问保护概述』一章。 在“F参数” (F parameters) 选项卡中，可以更改或接受以下参数的默认设置： –启用或禁用取消激活安全模式功能 – PROFIsafe 地址的基数 – F-CPU 的兼容模式 （仅用于支持 PROFIsafe V2 MODE 的 F-CPU 和仅具有 PROFIBUS DP 接口而不 是 PROFINET IO 的 F-CPU） – F 数据块的编号区 – F 功能块的编号区 –安全程序的本地数据区大小

Ansoft 如何使用分布式求解(Distributed Solve Option)功能_

Ansoft 如何使用分布式求解（D istributed S olve O ption）功能 编写：y1949b 日期：2013-05-18 首发：本人博客（https://www.wendangku.net/doc/da2893756.html,/y1949b） 同发：西莫论坛（https://www.wendangku.net/doc/da2893756.html,）

1 前言 使用Ansoft的过程中，经常对某个或多个变量进行参数化扫描，这往往造成了工作量非常巨大，针对这种情况Ansoft提供了分布式求解功能（即：DSO），可以利用在同一个域中的其它装有Ansoft的机器或者利用本机的多核CPU同时求解多个扫描点，从而节省计算时间，下面我就具体讲下如何在Ansoft使用分布式求解功能。 2 正文 首先，您要安装软件包中的[REMOTE SIMULATION MANAGER],如图1所示： 图1 运行RMS,即运行[Register with RSM],如图2所示： 图2

成功注册后，出现图3的界面： 图3 进入Ansoft（譬如Maxwell），设置如下：

布式求解的机器的IP或计算机名。

当设置的是计算机名时，点选[7]，在[8]中输入计算机名，计算机名可以通过下图的[计算机]-[属性]中查到，一般设置计算名的方式多为利用本机的多核CPU，通常建议几核，就点选[9]几下，这样就可以同时求解几个参数化扫描点，譬如我的机器为双核的，就点选两下，可以同时求解两个参数化扫描点。 当设置的是IP时，点选[7]上面的那个[IP Address（format：192.168.1.2）]，在旁边中输入IP，IP可以通过在[运行]中键入”cmd”命令,在cmd命令行中输入”ipconfig”查得，一般设置IP的方式用来添加相同域中其它计算机，来做分布式求解，其它的计算机要装有Ansoft软件，并如图1-3所示，注册了RSM,当然也可以将本机的IP一般添上。

Distributed Safety

S7 分布式故障安全系统使用入门S7 Distributed Safety System Getting Started

摘要 安全工程的目的是通过使用安全为导向的技术安装，尽可能地使对人员和环境的危害最小化。本文档通过一个简单实例来描述西门子分布式故障安全系统的概念、配置、编程以及通讯，去除掉手册过多的文字性描述，以便用户能够用较短的时间增强对西门子分布式故障安全系统的了解。 关键词 安全，分布式安全，PROFISAFE通信，安全处理器、安全信号模板 Key Words Safety, Distributed Safety, PROFISAFE Communication, F-CPU, F-SM A&D Service & Support Page 2-32

目录 S7 分布式故障安全系统使用入门 (1) 1. 故障安全系统概述 (5) 1.1什么是故障安全自动化系统 (5) 1.2西门子安全集成的概念 (5) 1.3SIMATIC S7中的故障安全系统 (5) 1.3.1 SIMATIC S7自动化系统提供两种故障安全系统: (5) 1.3.2 可实现的安全要求 (6) 1.3.3 S7 Distributed Safety 和 S7 F/FH Systems 中的安全功能原理 (6) 2．S7 DISTRIBUTED SAFETY 组件 (7) 2.1硬件组件 (7) 2.2软件组件 (8) 3. 分布式故障安全系统的组态和编程 (9) 3.1综述 (9) 3.1.1 本例程使用的设备结构图 (9) 3.1.2 软硬件列表 (10) 3.2硬件组态步骤 (10) 3.2.1 组态硬件 (10) 3.2.2 组态 F-CPU (11) 3.2.3 组态 F-IO (12) 3.3程序结构 (15) 3.4程序实例 (16) 3.4.1 配置F-FB (16) 3.4.2创建Failsafe Runtime Group (17) 3.4.3 在OB35中调用F-CALL (19) 3.4.4 编译下载Failsafe程序 (19) 3.5程序测试 (20) 3.5.1 F_ESTOP1运行结果 (20) 3.5.2 急停信号的钝化与去钝 (21) A&D Service & Support Page 3-32

通信领域专业词汇中英文对照

通信领域专业词汇中英文对照（补充） 所需磁盘空间[hw] disk space required 磁盘储存[hw] disk storage 磁盘子系统[hw] disk subsystem 磁盘使用摘要[hw] disk usage summary 软盘[hw] diskette 软盘位置[hw] diskette location 软盘邮递程序[hw] diskette mailer 所需软盘[hw] diskette needed 卸下[hw] dismount 发送[hw] dispatch 发送程序[hw] dispatcher 色散补偿光栅[hw] Dispersion Compensation Grating 色散平坦光纤[hw] Dispersion Flattened Fiber 色散管理装置[hw] Dispersion-Management Device 显示(v.)，显示器(n.) [hw] display 显示控制[hw] display control 显示期限长度[hw] display due date length 显示事件长度[hw] display event length 显示间隔时间[hw] display time intervals 站间距离[hw] distance between sites 距离矢量[hw] distance vector 判别名[hw] distinguished name 分发，分布[hw] distribute 分布式应用程序[hw] distributed applications 分布式计算机环境[hw] distributed computer environment 分布式计算[hw] distributed computing

在 MATLAB 2012a 上配置 MATLAB Distributed

在MATLAB 2012a 上配置MATLAB Distributed Computing Server过程详解 最近在做一个关于分布式人脸识别的研究，利用MATLAB自带工具箱（distcomp）实现分布式计算从而达到提高人脸识别速度的效果。今天下午对采用分布式架构和不采用分布式架构的两种表情识别算法进行了测试。在只创建4个分布式任务的情况下，时间有很明显的提高，而且对算法的识别率没有任何影响。 利用MATLAB实现分布式计算的前提是配置好 MATLAB Distributed Computing Server 的环境。配置的方法有两种：基于可视化界面的配置和基于控制台命令行的配置。前几天mathwork公司发布的 MATLAB 2012a在多个方面都了升级和优化其中MATLAB Distributed Computing Server的版本现在已经升级为6.0了。下面就分享一下基于可视化界面（主要）和控制台命令行相结合方式的MATLAB 2012a中MATLAB Distributed Computing Server 6.0的详细配置过程。 一、安装MATLAB 2012a，详细步骤这里就不说了，相信看这篇文章的博友都会的。 二、安装MATLAB Distributed Computing Server 6.0。以管理员身份运行CMD，进入到MATLAB分布式工具箱（distcomp）的bin目录下，路径因各人的安装路径而异，本人的路径是：H:Program Files(win8)MATLABR2012atoolboxdistcompbin; 命令：cd H:Program Files(win8)MATLABR2012atoolboxdistcompbin

DistributedSystemsPrinciplesandParadigms中文版书名分布

《Distributed Systems Principles and Paradigms》 中文版书名：《分布式系统原理与范型》 Author: A S.Tanebaum A S.Tanebaum是我喜欢的一名计算机学者，有理论，有实践，这才是计算机的正道。纯理论，那是数学研究者；而纯实践，那是工程师的活。又没有理论，有无实践，那是什么人呢？ 分布式系统：点对点计算、传感器网络、虚拟化计算、服务器集群、网格计算、Web 服务（非集中式系统）。 所引出的新问题：分布式系统的一致性模型、时钟同步算法等。 第一章概述 计算技术自80年代两大发展： 高性能CPU Network 物理上分散的计算机系统，借助于Network互联，在逻辑层面集成为一个整体，即透明化计算。 分布式系统特性： ①隐藏各计算机系统的异构性（中间件,Middleware） ②使用者以统一一致的方式与分布式系统交互。例如，Web 分布式系统四目标： ①资源远程访问 ②透明化计算（用户只关心是否使用方便） ③开放性 服务由接口规范，如可用函数的名称、参数等，关键在于说明服务所要执行的任务，即接口语义。 ④可扩展性（SaaS） 集中式服务：DNS -〉瓶颈 集中式算法：路由问题 从理论而言，收集各节点和通信线路的状态信息，利用Floyd或Dijkstra算法计算最优路径。问题在于收集相关状态信息并上传会导致网络过载。 分散式算法，其特性： ①没有分布式系统整体状态信息，而基于局部信息决策 ②不存在全局性时钟，而是局部时钟（时钟误差扩散） 可扩张性： 缓存，一致性问题(consistency) 不同一致性模型 分布式系统类型：

Distributed Stream Computing Platform(S4)_cn

S4:分布式流计算平台 概要 S4是一个通用的，分布式的，可扩展的，分区容错的，可插拔的平台。开发者可以很容易的在其上开发面向无界不间断流数据处理的应用。编键的数据事件被分类路由到处理单元（Processing Elements，PEs），处理单元消费这些事件，做如下事情之一或全部：（1）发出一个或多个可能被其他PE处理的事件。（2）发布结果。这种架构类似提供了封装和地址透明语义的Actor模式，因此允许应用在大规模并发的同时暴露简单的编程接口给应用开发者。在这篇论文里，我们将勾画S4的架构细节，描述各种各样的应用，包括实际中的部署。我们的设计主要由大规模应用在生产环境中的数据采集和机器学习所驱动。我们展示了S4设计令人惊奇的灵活性，使其运行在构筑于普通硬件之上的大规模集群中。 关键词：编程模型(programming model); 复杂事件处理(complex event processing);并发编程(concurrent programming); 数据处理(data processing); 分布式编程（distributed programming); map-reduce; 中间件(middleware); 并行编程(parallel programming); 实时搜索(real-time search); 软件设计(software design); 流计算(stream computing) 一、介绍 S4（简单可扩展流系统的首字母简称:Simple Scalable Streaming System）是一个受Map-Reduce模式启发的分布式流处理引擎。我们设计这个引擎是为了解决使用数据采集和机器学习算法的搜索应用环境中的现实问题。当前的商用搜索引擎，像Google、Bing和Yahoo！，典型的做法是在用户查询响应中提供结构化的Web结果的同时插入基于流量的点击付费模式的文本广告。为了在页面上的最佳位置展现最相关的广告，科学家开发了算法来动态估算在给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好，地理位置，之前的查询，之前的点击等等。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了处理用户反馈，我们开发了S4，一个低延迟，可扩展的流处理引擎。 为了便于在线实验算法，我们设想一种既适合研究又适合生产环境的架构。研究的主要需求是要具有将算法快速发布到特定领域的高度灵活性。这使得以最小的开销和支持在实际流量中测试在线算法成为可能。生产环境的主要需求是可扩展性（以最小的代价通过增加更多的机器来提高吞吐量的能力）和高可用性（在