Abstract

The Schedule as Independent Variable (SAIV) Process for Acquisition Software-Intensive Systems

Barry Boehm, Winsor Brown, LiGuo Huang University of Southern California

Center for Software Engineering

Los Angeles, CA 90089-0781

Dan Port University of Hawaii

Abstract

In this article, we show how you can use the MBASE process framework to generate a family of acquisition process models for delivering user-satisfactory systems under schedule, cost, and quality constraints. We present the six major steps of the Schedule/Cost/Schedule-Cost-Quality as Independent Variable (SAIV/CAIV/SCQAIV) process using SAIV and a representative Department of Defense (DoD) Command, Control, and Communications Interoperability application as context. We then summarize our ex perience in using SAIV on 26 University of Southern California electronic services projects, followed by discussions of SAIV/CAIV/SCQAIV application in the commercial and defense sectors, of model application within the DoD acquisition framework, and of th e resulting conclusions.

Introduction

In our earlier Cross Talk articles on the Spiral Model (Boehm, Hansen 2001) and Model-Based (System) Architecting and Software Engineering (MBASE) (Boehm, Port 2001), we showed that these were actually process model generators for the acquisition of software intensive systems. They use risk considerations to determine the most appropriate sequence of activities to perform (among specification, prototyping, simulation, benchmarking, increments of development, etc.) in order to achieve the most cost-effective system capability within various resource constraints such as cost, schedule, personnel, and platform characteristics.

In this article, we show how you can use the MBASE process framework to generate a particularly attractive family of acquisition process models for delivering user-satisfactory systems under such constraints. Many software-intensive systems acquisitions in DOD and elsewhere try to fix the required capabilities, and then hopefully deliver them within a pre-committed set of cost and schedule constraints. This has been shown to be a highly risky approach.

For example, the Standish Report (Standish) found that 84% of the software-intensive system projects it surveyed either overran their budgets an d schedules or were cancelled before completion. The average overruns on these projects were 189% of planned cost and 222% of planned schedule. And the completed overrun projects delivered an average of only 61% of the originally specified features.

The risk-driven MBASE-Spiral approach uses this overrun risk to invert the software-intensive-system acquisition process. Either schedule, cost, or some combination of

cost, schedule, and quality becomes the independent variable, and the lower-priority features become the dependent variable. This requires several sub-processes:

1.Determination of a top-priority core capability and quality level strongly assured to be

achievable within the schedule-cost-quality constraints;

https://www.wendangku.net/doc/f818786416.html,er expectations management and continuing update of feature priorities;

3.Architecting the system for ease of dropping borderline-priority features and future addition

of lower-priority features;

4.Careful progress monitoring and corrective action to keep within cost-schedule-quality

constraints.

Given current commercial time-to-market pressures, a number of more-and-less-successful versions of the Schedule as Independent Variable (SAIV) approach are practiced in the commercial sector. Within DOD, the Cost as Independent Variable (CAIV) approach is currently used to determine a set of required features achievable for a given cost, but the resulting cost and feature set is then usually fixed during system acquisition. With evolutionary acquisition, the ability to use spiral development approaches is encouraged, and often a fixed time period of 18 or 24 months is desired for early increments. The SAIV model is particularly well-suited for this objective. However, further adjustments in system acquisition, source selection, and contracting processes are needed to enable its use in competitive procurements.

In this article, we next review the SAIV-relevant portions of the MBASE process framework. We then present the six major steps of the SAIV/CAIV/SCQAIV process, and relate them to previous rapid-development processes such as design-to-schedule and timeboxing. We then summarize our experience in using SAIV on 26 USC electronic services projects, 24 of which have successfully delivered systems with high client-satisfaction ratings on a fixed schedule. This is followed by discussions of SAIV/CAIV/SCQAIV application in the commercial and defense sectors, of model limitations and extensions, and of the resulting conclusions.

The MBASE Process Framework

Software projects are guided by models th at they adopt (knowingly or unknowingly) to help their participants make decisions affecting the project. These models include Product models such as object models, architectures, and traditional requirements models; Process models such as lifecycle and risk management models; Property models such as cost, schedule, and performance models; and Success models such as contractual agreements, correctness, business-case analysis, and stakeholder win-win. Many of the most serious difficulties encountered by software projects can be traced to clashes among the models they have adopted (Boehm, Port 1999, Boehm et. al 2000b).

MBASE uses a process framework in which stakeholders express their initial desired success models, and proceed to adjust these and their associated product, process, and property models to achieve a consistent and feasible set of models to guide the project and its stakeholders. The actual process, as illustrated in Figure 1, generally takes several iterations, and requires some common intermedi ate checkpoints. MBASE also uses an extension of the original spiral model (Boehm 1998) to include stakeholder win-win model negotiation and a set of common anchor point milestones (Boehm 1996): key life-cycle decision points at which a project verifies th at it has feasible life-cycle objectives (LCO); a feasible life-cycle architecture and plan (LCA); and a product ready for operational use (IOC). More detailed descriptions and examples of the MBASE

process framework are available in our previous Cross Talk article, "Balancing Discipline and Flexibility with the Spiral Model and MBASE"(Boehm, Port, 2001).

MBASE differs from Model-Based Systems Engineering (MBSE) (Fisher 1998), in that MBSE concentrates almost exclusively on product models (and their associated property models). This is also the case for the Software Engineering Institute’s Model-Based Software Engineering (Gargaro, Peterson 1996) and Honeywell’s Model-Based Software Development (Honeywell 1998) approaches.

MBASE is most compatible with the Rational Unified Process (Jacobson et al. 1999, Kruchten 1998,Royce 1998), which has adopted the MBASE anchor point milestones. MBASE has adopted Rational’s Inception/Elaboration/Construction/Transition phase definitions for the activities between the milestones.

The SAIV Process Model

The SAIV Process model is described in terms of a representative set of SAIV applications: USC's annual series of e-services projects (Boehm et. al 1998, Boehm et. al 1999b). These projects are largely web-based applications developed by 5-person MS-student teams, using the MBASE Guidelines (Boehm et. al 2001a) and the MBASE Electronic Process Guide (Metha 1999).

The teams' main challenges are to develop a Life Cycle Objectives (LCO) package and a Life Cycle Architecture (LCA) package, described below, for a USC Information Services Division client's application in weeks during the fall semester; and to develop and transition an Initial Operational Capability (IOC) in 12 weeks during the spring semester. These are extreme examples of schedule being the independent variable, since the USC semester schedule is fixed and the students disappear (to graduation or summer jobs) at the end of the spring semester.

Figure 2 shows how the general MBASE process framework in Figure 1 is mapped onto the SAIV version of the win-win spiral model. The process models for CAIV and SCQAIV are essentially the same except for the definition of the radial dimension of the spirals. For CAIV projects, the spiral's traditional radial dimension of cumulative cost is used. For SAIV projects, the radial dimension is cumulative calendar time, with the USC SAIV project milestones occurring at 7 weeks for LCO, 12 weeks for LCA, 24 weeks for IOC, and a Core Capability milestone around 18-20 weeks, depending on the application. The USC e-services projects are pre-screened and expectations-managed with clients to ensure that acceptable capabilities can be developed within these constraints.

Figure 2 also shows the major SAIV process elements to be described next. These are executed concurrently within the spirals. As discussed in our spiral model article (Boehm, Hansen 2001), feedback and iteration of previous-cycle results are part of the spiral process, but are omitted from Figure 2 for simplicity.

Figure 2. Mapping of SAIV Spiral Process Elements Onto Win-Win Model

Shared Vision and Expectations Management. As graphically described in Death March (Yourdon 1997), many software projects lose the opportunity to assure a rapid, on-time delivery by inflating client expectations and overpromising on delivered capabilities. The first step in the SAIV process model is to avoid this by obtaining stakeholder agreement that meeting a fixed schedule for delivering the system's Initial Operational Capability (IOC) is the most critical objective or success model in Figure 1, and that the other objectives such as the IOC feature content can be variable, subject to meeting acceptable levels of quality and post-IOC scalability.

Often, the USC librarians and other Information Services personnel and the computer science students have unrealistic expectations about what is easy or hard for each other to do. We have found that providing them with lists of developer and client "simplifiers and complicators" improves their ability to converge on a realistic set of expectations for the delivered system (Boehm et. al 1999a). The resulting shared vision enables the stakeholders to rapidly renegotiate

the requirements as they encounter changing conditions.

Feature Prioritization. With MBASE at USC, stakeholders use the USC/https://www.wendangku.net/doc/f818786416.html, EasyWinWin requirements negotiation tool (Boehm et. al 2001b) to converge on a mutually

satisfactory (win-win) set of project requirements. One step in this process involves the stakeholders prioritizing the requirements by assessing their relative importance and difficulty, each on a scale of 0 to 10. This process is carried out in parallel with initial system prototyping, which helps ensure that the priority assessments are realistic, and that the domain model and product model in Figure 1 are feasibly scoped.

Schedule Range Estimation. The developers then use a mix of expert judgement and parametric cost modelling (the property models in Fi gure 1) to determine how many of the top-priority features can be developed in 24 weeks under optimistic and pessimistic assumptions. For the parametric model, we use COCOMO II, which estimates 90% confidence limits on both cost and schedule (Boehm et. al 2000a). Other models such as SLIM (Putnam 2001), SEER (Galorath 2001), and Knowledge PLAN (Jones 2001) provide similar capabilities.

Architecture and Core Capability Determination. The most serious mistake a project can make at this point is just to pick the topmost-priority features with 90% confidence of being developed in 24 weeks. This can cause two main problems: producing an IOC with an incoherent and incompatible set of features; and delivering these without an underlying architecture supporting easy scalability up to the full feature set and workload.

First, the core capability must be selected so that its features add up to a coherent and workable end-to-end operational capability. Second, the remainder of the lower-priority IOC requirements and subsequent evolution requirements must be used in determining a system architecture facilitating evolution to full operational capability. Still the best approach for achieving this is to use the Parnas information-hiding approach to encapsulate the foreseeable sources of change within modules (Parnas 1979). The architecting process may take two or more win-win spiral cycles of prototyping, COTS product evaluation, and stakeholder renegotiation to reconcile the system’s product, process, property, and success models into a Life Cycle Architecture Package as in Figure 1.

Incremental Development. The LCA package includes an incremental development plan (item 5a in figure 2) indicating the schedules and pass/fail criteria for the core capability (item 5b), IOC (item 5c), and perhaps other milestones.

Since the core capability has only a 90% assurance of being completed in 24 weeks, this means that about 10% of the time, the project will have to stretch to deliver the core capabilities in 24 weeks, perhaps with some extra effort or occasionally by further reducing the top-priority feature set. In the most likely case, however, the project will achieve its core capability with about 20-30% of the schedule remaining. This time can then be used to add the next-highest priority features into the IOC (again, assuming that the system has been architected to facilitate this).

An important step at this point is to provide the operational stakeholders (users, operators, maintainers) with a Core Capability Demonstrati on. Often, this is the first point at which the realities of actually taking delivery of and living with the new system hit home, and their priorities for the remaining capabilities may change.

Also, this is an excellent point for the stakeholders to reconfirm the likely final IOC content, and to synchronize plans for conversion, training, installation and cutover from current operations to the new IOC. A rapid, "cold-turkey" cutover to Information Services Division operations and maintenance is extremely important and challenging for the USC applications, since the students disappear after IOC.

Change and Progress Monitoring and Control. This process element is not shown in Figure 2,

as it is applied continuously in each spiral cycle. As progress is being monitored with respect to plans, there are three major sources of change, which may require revaluation and modification of the project's plans:

1. Schedule slips. Traditionally, these can happen because of unforeseen technical difficulties, staffing difficulties, customer or supplier delays, etc.

2. Requirements changes. These may include changes in priorities, changes in current requirements, or needs for new high-priority requirements.

3. Project changes. These may include staffing changes, COTS changes, or new marketing-related tasks (e.g., interim sponsor demos).

In some cases, these changes can be accommodated within the existing plans. If not, there is a need to rapidly renegotiate and restructure the plans. If this involves the addition of new tasks on the project's critical path, some other tasks on the critical path must be reduced or eliminated. There are several options for doing this, including dropping or deferring lower-priority features, reusing existing software, or adding expert personnel. In no cases should new critical-path tasks be added without adjustments in the delivery schedule.

Related Approaches. Design-to-cost and design-to-schedule processes have been used for a long time, particularly for such activities as rapid prototyping. The 1989 book Software Risk Management defines them as "prioritizing the desired system capabilities and organizing the architecture to facilitate dropping lower-priority capabilities as one finds that their development does not fit within one's available budget or schedule." (Boehm 1989, p.437)

The related Timeboxing approach developed at Du Pont in the late 1980's by Scott Schulz and others was a highly successful application of the SAIV approach to moderate-size business applications (Martin 1991). Steve McConnell's book, Rapid Development, has a particularly good description of Timebox Development (McConnell 1996, pp.575-583). It includes such key features as prioritizing requirements, realistic schedules, end-user involvement, not sacrificing quality, and use of small, skilled, highly motivated teams. Its focus is on fixed 60-120 day timeboxes with a binary accept/reject decision at the end. It has less emphasis than SAIV/CAIV/SCQAIV on such practices as expectations management, schedule range estimation, architecting for ease of adding and dropping marginal features, and core capability determination. The more adaptive and scaleable form of timeboxing used in Jim Highsmith's Adaptive Software Development (Highsmith 1999) comes closer to the SAIV approach, but is considerably more informal. The SAIV approach described here tries to steer the project toward a balance of flexibility and discipline with a low risk of failure.

SAIV Experience

USC Electronic Services Projects. The USC electronic services projects (Boehm et. al 1998, Boehm et. al 1999b) use the MBASE approach as detailed in (Boehm et. al 2001a) and (Metha 1999). To elaborate on its top-level description in Figure 1, it involves the concurrent development of several initial artifacts: an Operational Concept Description, a Requirements Definition, an Architecture Description, a Life Cycle Plan, a Feasibility Rationale, and one or more prototypes. These are evaluated at two major pass/fail points, the Life Cycle Objectives (LCO) and the Life Cycle Architecture (LCA) milestones. Both milestones use the same primary pass-fail criterion:

?If we build the system to the given architecture, it will satisfy the requirements, support the operational concept, be faithful to the prototypes, and be buildable within the processes, budgets, and schedules in the plan.

For the LCO milestone, this criterion must be satisfied for at least one choice of architecture, along with demonstration of a viable business case for the system and the expressed concurrence of all the success-critical stakeholders. For the LCA milestone, the pass-fail criterion must be satisfied for the specific choice of architecture and COTS components to be used for the system, along with continued business case viability and stakeholder concurrence, plus elimination of all major project risks or coverage of the risks in a risk management plan.

One of our primary goals in the project course is to give the students experience in risk management (Port, Boehm 2001). Our risk management lectures and homework exercises emphasize a list of the ten most serious risk items: personnel risks are number 1, and budget-schedule risks are number 2. The student projects' risk management plans must show how their team will avoid the risks of delivering an unsatisfactory Life Cycle Architecture package in the first 12 weeks (fall semester), and of unsatisfactorily delivering and transitioning an Initial Operational Capability (IOC) in the second 12 weeks (spring semester). The MBASE Guidelines recommend that they adopt the SAIV model described in Section 3; so far, all the projects have done this.

Also, we work in advance with the USC Library clients to sensitize them to the risks of overspecifying their set of desired IOC features, and to emphasize the importance of prioritizing their desired capabilities. This generally leads to a highly collaborative win-win negotiation of prioritized capabilities, and subsequently to a mutually satisfactory core capability to be developed as a low-risk minimal IOC.

The projects' monitoring and control activities include:

?Development of a top-N project risk item list which is reviewed and updated weekly to track progress in managing risks (N is usually between 5 and 10).

?Inclusion of the top-N risk item list in the project's weekly status report.

?Management and technical reviews at several key milestones

?Client reviews at other client-critical milestones such as the Core Capability Demonstration.

The use of SAIV and these monitoring and control practices have led to on-time, client-satisfactory delivery and transition of 24 of the 26 products developed to date. One of the two failures was in our first year, when we tried to satisfy three clients by merging their image archive applications into a single project, and underestimated the complexity of the merge. As a result, "merging multiple applications" has become one of the major sources of project risk that we consider.

The second failure happened recently when a project which appeared to be on track at its Transition Readiness Review, simply did not implement its transition plan when its client suddenly had to go out of town. We were not aware of this until the client returned after the semester was over and the students had disappeared to graduation and summer jobs. We have since revised our system of closeout reviews to eliminate this "blind spot" and related problem sources.

On the other 24 projects, client evaluations have been uniformly quite positive, averaging about 4.4 on a scale of 1 to 5. A particularly frequent client evaluation comment has been their pleasure in being able to synchronize product transition on a specific fixed date with their other transition activities. Another pleasant surprise was the effect on clients' review timeliness: "You mean if I evaluate the prototype right away, I'll get more features in my IOC?" The e-services project artifacts can be reviewed on the class web page, https://www.wendangku.net/doc/f818786416.html,/classes.

E-Commerce Projects. One of our industrial affiliates, C-Bridge, Inc., uses a very similar SAIV process model, which enables them to consistently deliver e-commerce systems on fixed schedules between 16 and 26 weeks. Their Rapid Value TM approach uses milestones very similar to MBASE’s LCO, LCA, and IOC milestones; their counterpart phases are named Define, Design, Develop, and Deploy. They use similar approaches in working in advance with their clients to ensure a workable SAIV scope and schedule, and in anticipating and pre-working potential transition problems to client-based operations and maintenance (Madachy et. al 2001).

The CAIV and SCQAIV Process Models. Simply substituting "cost" for "schedule" in the SAIV process model described above provides you with an equally effective w ay to use CAIV as a process model. The SCQAIV model is a straightforward extension of CAIV and SAIV. It involves setting the system's quality goals (e.g., a delivered defect density of 0.3 nontrivial defects per thousand source lines of code (KSLOC), or of 0.03 nontrivial defects per function point), and tracking progress with respect to achieving the desired combination of schedule, cost, or quality goals. If any of these goals becomes unachievable in delivering the current feature set, the project must drop enough lower-priority features to make the combination of goals achievable. There may be limits to the project's ability to do this, which are discussed next.

Applying SAIV, SAIV, and SCQAIV

SAIV/CAIV/SCQAIV Limitations

The primary limitation arises in applications which have a minimum essential core capability (e.g., aircraft control) whose implementation within the quality goals and available schedule and budget is unachievable. This limitation can be visualized and addressed in terms of the project's production function relating the value of the product to the resources required to create it, as shown in Figure 3. It is slightly modified and updated from (Boehm 1981, p. 193). As with most production functions, it is an S-shaped curve with three segments:

?An investment segment, in which necessary infrastructure capabilities are developed, but very little value-generating applications capability is developed.

? A high-payoff segment, in which incremental investments in applications capability produce significant added value to the organisation.

? A diminishing returns segment, in which incremental investments in applications capability produce decreasingly small added value to the organisation.

For any given project duration T, and for any given set of project parameters such as the COCOMO II cost drivers, there is a smaller set of capabilities that can be developed with 90% confidence of completion, and a larger set of capabilities that can be developed with 50% confidence of completion. These are sh own in Figure 3 with respect to two example project durations, T = 12 months and T = 6 months.

The COCOMO II model produces Most Likely (50% confidence) and Pessimistic (90% confidence) estimates, enabling you to determine how much software can be developed to these confidence levels in 6 or 12 months. Again, it is good practice to cross-check the COCOMO estimates by using expert judgement and/or another cost model.

Figure 3. Example production function for software product features For the 12-month project duration, the value profile is compatible with a SAIV approach, since even at a conservative 90% completion confidence level, enough applications software is achievable within 12 months to produce appreciable value, and the value goes up significantly at the 50% confidence level. Thus, one could plan for an increment 1 core capability that (sometimes with some extra effort or descoping) would produce acceptable value even in the worst case.

However, for the 6-month project duration, even the 50% confidence level feature set does not reach an adequate value to be worth the investment, and the 90% core capability does even worse. Thus, we see that Step 3 of the SAIV approach, Schedule Range Estimation, actually includes a decision branch that terminates the process if an inadequate core capability results from the analysis. With both the USC digital library projects and the C-Bridge e-commerce applications, an exploratory effort with the clients is used to determine whether a project is worth pursuing within a given fixed schedule or budget.

Realizing SAIV/CAIV/SCQAIV Within the DoD Acquisition Framework Stable Post-Deployment Support. In situations such as post-deployment upgrades and pre-planned product improvements, DoD can and often has implemented versions of SAIV/CAIV/SCQAIV as smoothly as they are done commercially. Frequently, in such situations, the organization’s software maintenance budget and release cycle are relatively fixed. The biggest risk is to promise too much within these constraints, leaving the sacrifice of quality as the only way

to meet budget and schedule. This inevitably leads to degradations of the software’s maintainability, operational fitness, and future maintenance productivity.

Thus, a form of SCQAIV is the best option for software maintenance, in which quality standards are set, infrastructure upgrades are given appropriate priorities, and lower-priority features are shed to meet cost, schedule, and quality objectives.

This approach is workable because DoD’s operations and maintenance acquisition practices are similar to their commercial counterparts. Budgets are generally not tied to premature promises of delivered features, and there is usually a long-term customer-supplier relationship with a shared product vision am ong the customer, supplier, and users. This continuing relationship usually increases mutual trust, the ability to share and respect each other’s win conditions and to negotiate mutually satisfactory or win-win agreements and priorities.

Competitive Development. In some cases, such as the Air Force Electronic Systems Center’s Command Center Product Line (CCPL) and within classified-application organizations, DoD customers have been able to create development arrangements similar to the stable post-deployment support situation described above. CCPL, for example, developed a flexible contractual instrument focused on creating user value rather than prespecified features, and allowing in-process renegotiation of priorities. It selected three contractors via competitive source selection. The evaluation criteria included track record on similar developments, software CMM process maturity, technical and management approach, and demonstration of the approach via a representative exercise.

Once selected, the contractors operated as a team with the customer, developing a strong shared vision for the product line, and taking on new assignments based on best-matched available expertise, ensuring effective employment of all three contractors’resources. In this situation, SAIV/CAIV/SCQAIV-type approaches were highly feasible and preferable.

In many cases, however, DoD organizations must develop a new system vision and set of acquisition parameters (schedule, cost, quality attribute levels, feature scope) within a competitive acquisition framework. Here, complete multi-contractor shared vision development is impractical, as developers will be unwilling to share their competitive-discriminator technology solutions with competing developers. Frequently, this leads acquisition organizations to exclude developers from participating in the creation of the shared vision. This is highly risky, as the resulting decision may exclude attractive developer technology solutions. And it may leave serious vision mismatches between the customer, user, and selected developers, making SAIV/CAIV/SCQAIV system scoping and feature prioritization difficult to achieve, particularly if the program’s funding and schedule have been tied to a particular set of delivered capabilities.

Unfortunately, there is no ideal solution to this dilemma. The most attractive near-solution involves the use of multiple competitive spiral cycles of system definition, with the number of competitors being reduced from one cycle to the next. The earlier cycles are shorter and less expensive, making a larger number of participants affordable. They can be run as SAIV/CAIV procurements with equal opportunity for each competitor. Some care is necessary to avoid leaking competitors’key discriminators, but many competitive DoD concept definition efforts have achieved this.

These earlier cycles enable overall system scoping and trade-off analysis to be performed, along with the evaluation of readiness levels of key technologies via prototyping, benchmarking, modeling and simulation, etc. This also enables the acquirers to evaluate the competing developers’capabilities and understanding of the system context and objectives. Some similar criteria to those used by CCPL (track record, technical and management capabilities, concept

definition and evaluation performance) are used for initial competitor selection and early downselection. Later downselection criteria increasingly involve development capabilities such as process maturity and realism of development plans, schedules, and budgets. Here again, the final development competition can fix the cost and/or schedule, provide a prioritized feature set, and compete on scope and realism of feature set delivery plans.

All three Services are making progress toward mastering this kind of evolutionary acquisition in the context of the new DoD 5000-series of acquisition regulations (DoD 2000). These include the extensive use of simulation and modeling in the Army’s SMART program, the Air Force’s Instruction 63-123, “Evolutionary Acquisition of Command and Control Systems”(US Air Force 2000), use of downselected contractors’expertise in other system life-cycle roles, and Service use of new contractual vehicles such as Cooperative Research and Development Agreements (CRADAs) and the DARPA-originated “Other Transactions”approach (US Air Force 2000). All of these are compatible with and have been used successfully with SAIV/CAIV/SCQAIV-type approaches.

Conclusions

The six-step SAIV process model presented here has been used successfully on 24 of 26 e-services applications at USC, and on a similar percentage of e-commerce applications at C-Bridge, to deliver highly client-satisfactory applications on a fixed schedule in a climate of rapid change. Its 92% success rate compares favorably with the 16% success rate in the Standish Group's survey of current practice. Its critical success factors are:

?Working with stakeholders in advance to achieve a shared product vision and realistic expectations;

?Getting clients to develop and maintain prioritized requirements;

?Scoping the core capability to fit within the high-payoff segment of the application’s production function for the given schedule;

?Architecting the system for ease of adding and dropping borderline features;

?Disciplined progress monitoring and corrective action to counter schedule threats.

The approach can also be applied to its counterpart Cost As Independent Variable (CAIV) process model. It can also provide a way to transform the current dilemma, “Schedule, Cost, Quality: Pick Any Two,”to “Schedule, Cost, Quality: Pick All Three,”via the SCQAIV version of the model, whenever your project is able to shed lower-priority features to meet its SCQ objectives. Proven strategies are also available for applying SAIV/CAIV/SCQAIV to competitive DOD system acquisitions.

References

Boehm, B., Software Engineering Economics, Prentice Hall, 1981.

Boehm, B., Software Risk Management, IEEE-CS Press, 1989.

Boehm, B., “Anchoring the Software Process,” IEEE Software, July 1996, pp. 73-82. Boehm, B., “A Spiral Model of Software Development and Enhancement,” IEEE Computer, May 1998, pp. 61-72.

Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, A. and Madachy, R., “Using the WinWin Spiral Model: A Case Study”, IEEE Computer, July 1998, pp. 33-44.

Boehm, B., Abi-Antoun, M., Kwan, J., Lynch, A. and Port, D., “Requirements Engineering, Expectations Management, and the Two Cultures,”Proceedings, 1999 International Conference on Requirements Engineering, June 1999.

Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J. and Madachy, R., “A Stakeholder Win-Win Approach to Software Engineering Education”, Annals of Software Engineering, April 1999. Boehm, B. and Port, D., “Escaping the Software Tar Pit: Model Clashes and How to Avoid Them,”

ACM Software Engineering Notes, January 1999, pp. 36-48.

Boehm, B., Abts, C., Brown, A.W., Chulani, S., Clark, B., Horowitz, E., Madachy, R., Reifer, D.

and Steece, B., Software Cost Estimation with COCOMO II, Prentice Hall, 2000.

Boehm, B., Port, D. and Al-Said, M., “Avoiding the Software Model-Clash Spiderweb,” IEEE Computer, November 2000, pp. 120-122.

Boehm, B., and Hansen, W., "The Spiral Model as a Tool for Evolutionary Acquisition,"

CrossTalk, May 2001, pp. 3-11.

Boehm, B., and Port, D., "Balancing Discipline and Flexibility with the Spiral Model and MBASE," Cross Talk, 2001

Boehm, B., Port, D., Abi-Antoun, M. and Egyed, A., “Guidelines for Model-Based Architecting and Software Engineering (MBASE)”version 2.2, USC-CSE, (Feb.2001), https://www.wendangku.net/doc/f818786416.html,/Research/MBASE

Boehm, B., Gruenbacher, P., and Briggs, R. "Developing Groupware for Requirements Negotiation: Lessons Learned, "IEEE Software, May/June 2001, pp. 46-55

Department of Defense Instruction 5000.2, “Operation of the Defense Acquisition System,”

September 2000, https://www.wendangku.net/doc/f818786416.html,/ap/i50002p.doc

Fisher, J. et al., “Model-Based Systems Engineering: A New Paradigm,” INCOSE INSIGHT, October 1998, pp. 3-16.

Galorath, D., “SEER-SEM,”Galorath, Inc., 2001, https://www.wendangku.net/doc/f818786416.html, Gargaro, A. and Peterson, A.S., “Transitioning a Model-Based Software Engineering Architectural Style to Ada 95,”SEI Technical Report CMU/SEI-96-TR-016, 1996. Highsmith, J., Adaptive Software Development, Dorset House, 1999.

Honeywell Technology Center, “Model-Based Software Development,”Course Announcement, Minneapolis, MN, 1998.

Jacobson, I., Booch, G. and Rumbaugh, J., The Unified Software Development Process, Addison-Wesley, 1999.

Jones, C., “Knowledge PLAN,”Artemis/SPR, 2001, https://www.wendangku.net/doc/f818786416.html,

Kruchten, P., The Rational Unified Process, Addison-Wesley, 1998.

Madachy, R., Pan, A. and Arboleda, A., “Processes for Rapid Development of Internet Applications,”LA SPIN Presentation, January 24, 2001.

Martin, J., Rapid Application Development, Prentice Hall, 1991.

McConnell, S., Rapid Development, Microsoft Press, 1996

Mehta, N., “MBASE Electronic Process Guide,”USC-CSE, September 1999, https://www.wendangku.net/doc/f818786416.html,/Research/MBASE

Parnas, D., “Designing Software for Ease of Extension and Contraction,” IEEE Trans. Software Engr., March 1979, pp. 128-137.

Port, D. and Boehm, B. “Educating Software Engineering Students to Manage Risk,”Proceedings, ICSE 2001, May 2001.

Putnam, L. “Software Life Cycle Model (SLIM),”QSM, 2001, https://www.wendangku.net/doc/f818786416.html, Royce, W.E., Software Project Management: A Unified Framework, Addison-Wesley, 1998.

Standish Group, "CHAOS," https://www.wendangku.net/doc/f818786416.html,/chaos.htm

U.S. Air Force Instruction 63-123, “Evolutionary Acquisition for C2 Systems,”April 2000, https://www.wendangku.net/doc/f818786416.html,/

Yourdon, E., Death March, Prentice Hall, 1997.

如何写英文Abstract

How to Write an Abstract 一、什么是摘要Abstract? an abstract comprises one paragraph which describes the main content of a paper and appears at the very beginning of the paper. 摘要是叙述文章主要内容的一个段落，并且位于文章的开头部分。 摘要是以梗概形式呈现的一篇文章要点的总结，它强调了一篇文章所包含的重要的信息。它也可以帮助读者快速的了解到是否这篇文章是他们感兴趣的，是否他们需要来阅读整篇文章。而且，国家或国际出版社的编辑通常通过浏览投稿文章的摘要来决定是否投稿人的文章是可以被录用的。因此，对于学者和研究人员来说，写一份好的摘要至关重要。 二、写作Abstract的目的 对于科技论文的摘要，Abstract的目的有以下几点： 1.Introduce journal articles. https://www.wendangku.net/doc/f818786416.html,rm readers about article`s content. 3.Help readers decide whether or not to read article. 4.Overview conference programs,abstract collections,and book chapters. 三、学习写作Abstract的必要性 1.Helps you present complex information in a clear,concise manner. 2.Helps you read abstracts more effectively. 3.Helps you conduct research. 4.Helps you write abstracts for future publications. 5.Helps you condense report information into a short format for database searches. 四、Abstract的写作要求 https://www.wendangku.net/doc/f818786416.html,e one or more well-developed paragraphs,which are unified,coherent,concise,and able to stand alone（200-300 words). https://www.wendangku.net/doc/f818786416.html,e an introduction-body conclusion structure in which the parts of the parts of the report are discussed in order:purpose,researcquestions,method,findings,conclusions,recommendations.

UPPAAL建模工具教程

Uppaal4.0:Small Tutorial? 16November2009 1Introduction This document is intended to be used by newcomers to Uppaal and veri?cation.Students or engineers with little background in formal methods should be able to use Uppaal for practical purposes after this tutorial. Section2describes Uppaal and Section3is the tutorial itself. 2Uppaal Uppaal is a tool box for validation(via graphical simulation)and veri?cation(via automatic model-checking)of real-time systems.It consists of two main parts:a graphical user interface and a model-checker engine.The user interface is implemented in Java and is executed on the users work station.Version4.0of Uppaal requires that the Java Runtime Environment5or higher is installed on the computer.The engine part is by default executed on the same computer as the user interface,but can also run on a more powerful server. The idea is to model a system using timed automata,simulate it and then verify properties on it.Timed automata are?nite state machines with time(clocks).A system consists of a network of processes that are composed of locations.Transitions between these locations de?ne how the system behaves.The simulation step consists of running the system interactively to check that it works as intended.Then we can ask the veri?er to check reachability properties,i.e.,if a certain state is reachable or not.This is called model-checking and it is basically an exhaustive search that covers all possible dynamic behaviours of the system. More precisely,the engine uses on-the-?y veri?cation combined with a symbolic technique re-ducing the veri?cation problem to that of solving simple constraint systems[YPD94,LPY95].The veri?er checks for simple invariants and reachability properties for e?ciency reasons.Other prop-erties may be checked by using testing automata[JLS96]or the decorated system with debugging information[LPY97]. 3Learning Uppaal Uppaal is based on timed automata,that is?nite state machine with clocks.The clocks are the way to handle time in Uppaal.Time is continuous and the clocks measure time progress.It is allowed to test the value of a clock or to reset it.Time will progress globally at the same pace for the whole system. A system in Uppaal is composed of concurrent processes,each of them modeled as an automa-ton.The automaton has a set of locations.Transitions are used to change location.To control when to take a transition(to“?re”it),it is possible to have a guard and a synchronization.A guard is a condition on the variables and the clocks saying when the transition is enabled.The synchronization mechanism in Uppaal is a hand-shaking synchronization:two processes take a ?This description covers version4.0.7

Java中的abstract方法和abstract类的问题

Java中的abstract方法和abstract类的问题 当知道一个类的子类将不同的实现某个方法时，把该类声明为抽象类很有用，可以共用相同的父类方法，不必再定义。 抽象类和抽象方法的关系:含有抽象方法的类一定是抽象类，抽象类里不一定含有抽象方法。抽象类存在的意义是用来被继承的。一个类继承了一个抽象类，必须实现抽象类里面所有的抽象方法，否则，此类也是抽象类。 abstract修饰符用来修饰类和成员方法 1：用abstract修饰的类表示抽象类，抽象类位于继承树的抽象层，抽象类不能被实例化。2：用abstract修饰的方法表示抽象方法,抽象方法没有方法体。抽象方法用来描述系统具有什么功能，但不提供具体的实现。 abstract 规则： 1：抽象类可以没有抽象方法，但是有抽象方法的类必须定义为抽象类，如果一个子类继承一个抽象类，子类没有实现父类的所有抽象方法，那么子类也要定义为抽象类，否则的话编译会出错的。 2：抽象类没有构造方法，也没有抽象静态方法。但是可以有非抽象的构造方法 3：抽象类不能被实例化，但是可以创建一个引用变量，类型是一个抽象类，并让它引用非抽象类的子类的一个实例 4：不能用final 修饰符修饰 Q:java里面有抽象类么？和接口的区别是什么？ A:java中有抽象类,用关键字abstract修饰。 以下是我对这个问题的看法。 首先，从语法上讲，抽象类是一个类，根据java的单继承体系。如果它有子类，那么它的

子类只能继承它。 java允许实现多个接口。所以一个类可以实现多个接口 抽象类里面可以定义各种类型和访问权限的变量(就像普通类一样)，也可以定义各种访问权限的方法(就像普通类一样)。 但是接口不可以。在接口里面定义的方法默认就是public abstract的，变量默认就是public static final的。(不管你有没有加权限控制符，不加，默认就是这些权限；加错了，权限缩小了，那么就会报错) 其次，从意义上讲，如果继承一个抽象类，那么抽象类和它的子类就有父子关系，即有类的层次关系(这关系到类的设计问题)。 接口，在我看来，是一种契约或者协议，是一层提供给另一层的接口(可以想象成OSI各层之间的关系) 在某一层中有多个类协作实现这个层的功能，通过接口暴露出去。但这些类之间会有层次关系(is a,has a) Q:一个方法加abstract和不加abstract有什么区别？就是说不加有什么关系？加了又会怎样？ A:一方法要是加abstract，那么这个方法就是抽象的，须由子类去实现 抽象方法必须在抽象类当中，也就是说，一个类只要有一个方法是抽象的，那么这个类就必须是抽象类 抽象类里面的方法不一定要抽象的，也可以全都不是抽象的 抽象类不能实例化！ 所以可以想到，当你不想让你的类被别人实例化，只想这个类的子类可以实例化，那么只要将这个类声明为abstract的就可以了

学术论文写作的要点范文

一、研究生必备四本 俗话说好记性不如烂笔头，所以一定要首先养成做笔记的好习惯！作为研究生下面这几个本子是必不可少的。 1，实验记录本（包括试验准备本），这当然首当其冲必不可少，我就不多说了； 2，Idea记录本，每次看文献对自己有用的东西先记下，由此产生的idea更不能放过，这可是做研究的本钱，好记性不如烂笔头，以后翻翻会更有想法的； 3，专业概念以及理论进展记录本，每个人不可能对自己领域的概念都了如指掌，初入门者更是如此，这时候小小一个本子的作用就大了； 4，讲座记录本，这本本子可能有些零杂，记录听到的内容，更要记录瞬间的灵感，以及不懂的地方，不可小视！ 这四本是你必不可少的，不过作为我们这些非英语专业的研究生来说，还有一个应该具备的本子就是英语好句记录本。 二、论文写作要点 1、选题要小，开掘要深；不要题目很大，内容却很单薄。 2、写作前要读好书、翻阅大量资料、注意学术积累，在这个过程中，还要注重利用网络，特别是一些专业数据库 3、“选题新、方法新、资料新”的三新原则（老板教导的） 4、“新题新做”和“小题大做 总之，一点之见即成文。 三、如何撰写实验研究论文（唐朝枢） 论文发表意识：基础研究成果的表达方式；是否急于发表（创新与严谨的关系）；发表的论文与学位论文的区别（反映科学事实而不是反映作者水平） 论文格式：原著 original research paper, full length paper、review综述论文，快报、简报、摘要。不同于教科书、讲义，更不同于工作总结。 撰写前的准备工作：复习和准备好相关文献;再次审定实验目的(学术思想,Idea);实验资料完整并再次审核 1.Introduction:引言 问题的提出；研究的现状及背景；以前工作基础；本工作的目的；思路（可提假说）；对象；方法；结果。在…模型上，观察…指标，以探讨…（目的）

论文的Abstract写法

文摘要求 对于科技期刊的文章，论文的 abstract 主要由三部分组成，即：研究的问题、过程和方法、结果。 文摘只有写得正确，写的好，才能起到帮助读者了解原文的作用。因此必须对文献进行认真的主题分析， 找出文献的主题概念， 正确地组织好这些主题内容， 简明准确完整地写出文摘来。 文摘长度一般不超过 150 words 。少数情况下允许例外，视原始文献而定。在不遗漏主题概念的前提下，文摘应尽量简洁。 （一）.缩短文摘方法: 1.取消不必要的字句：如 ”t is reported here ”、 “new ”、 “ mainly ” 也尽量不要。 2. 对物理单位及一些通用词可以适当进行简化; 3. 取消或减少背景信息（ Background Information ）; 4. 不说无用的话，如“本文所谈的有关研究工作是对过去老工艺的一个极大的改进” ， “本工作首次实现了 …” “经检索尚未发现与本文类似的文献”等词句切不可进入文摘; 5. 作者在文献中谈及的未来计划不纳入文摘； 6. 文摘第一句应避免与题目（Title ）重复。 7. 尽量简化一些措辞和重复的单元，如： （二）.文体风格 1. 文摘叙述要完整，清楚，简明； 2. 尽量用短句子并避免句形单调； 3. 用过去时态叙述作者工作，用现在时态叙述作者结论； 如 “The structure of dislocation cores in GaP was investigated by weak-beam electron microscopy. The dislocations are dissociated into two Shokley partials with separations of 80 edge and screw cases respectively. The results show that... __________________________________ ” 可直接用名词或名词短语作定语的情况下，要少用 of 句型。 例如： 用 Thick ness of plastic sheets was measured. 不用 Measurement of thickness of plastic sheet was made. 注意冠词用法，不要误用，滥用或随便省略冠词。 避免使用一长串形容词或名词来修饰名词，可以将这些词分成几个前置短语，用连字符连接名词 组，作为单位形容词（一个形容词） 。 如应用 The chlorine-containing propylene-based polymer of high meld index. 代替 The chlorine containing high melt index propylene based polymer. 尽量用主动语态代替被动语态； 尽量用简短、词义清楚并为人熟知的词; 10?慎用行话和俗语; " Exte nsive in vestigati ons show that 'The author discusses ” This paper concerned with …”；一些不必要的修饰词，如“ in detail ”、“ briefly ±10 and 40 ±10 A in the pure 能用名词做定语不要用动名词做定 语， 例如：用 measurement accuracy 用 experimental results 能用形容词做定语就不要用名词做定语。 不用 measuri ng accuracy 不用 experime nt results 例女口 用 measurement accuracy 不用 accuracy of measureme nt 用 camera curtain shutter 不用 curta in shutter of camera 用 equipment structure 不用 structure of equipme nt 5. 可用动词的情况尽量避免用动词的名词形式; 6 . 8. 9.

abstract结构分析

1.Urology is perceived as a competitivespecialty choice. Declining undergraduate exposure and thepreference for ‘‘lifestyle specialties’’ may jeopardize urology’s popularity. Our objective was to assess trends inapplication and matching rates to urology compared withother surgical specialties. 2. We reviewed data collected by CanadianResidency Matching Service (CaRMS) and the CanadianPost-MD Education Registry since expansion in Canadianmedical school enrollment began (2002-2011). The following were examined: applicant preference, number ofpositions, gender patterns, and match results. ‘‘Surgery’’included general surgery, orthopedics, plastics, ENT, and urology. 3.From 2002 to 2011 CaRMS applicantsincreased from 1117 to 2528 (126%). The number ofapplicants selecting surgery first increased from 178 to338(90%). The number of surgery positions increased from138 to 275 (100%). Urology positions increased from 15to 31 (113%). Applicants to urology increased only 40%(30-42). The proportion of all CARMs applicants selectingurology as their first choice decreased from 2.7% (30) to1.7% (42). The ratio of first choice urology applicants topositions decreased from 2 to 1.35. The probability ofmatching urology as first choice increased from 50% to76%. Female medical graduates increased from 51% to58%. The female applicants selecting surgery first increasedfrom 21% (49) to 41% (173). In contrast, females selectingurology first rose from 13% (4) to 17% (7). 4.Urology in Canada is becoming lesscompetitive. Residency positions have doubled since 2002whereas the number of applicants remains static. This trendwas not reflected in other surgical specialities. Factorsaccounting for this may include poor undergraduateexposure, demand for specialties with controllable lifestyles,gender shifts in undergraduate medicine, and lack of rolemodels. The need for undergraduate exposure to urologyand vetting numbers of residency positions remains a matterof paramount importance. ( JSurg 70:537-543. JC2013Association of Program Directors in Surgery. Published byElsevier Inc. All rights reserved.) BACKGROUND1: METHODS2: RESULTS3: CONCLUSION4:

语言学中的研究方法

第34卷第6期 唐山师范学院学报 2012年11月 Vol.34 No.6 Journal of Tangshan Teachers College Nov. 2012 ────────── 收稿日期：2012-03-25 作者简介：申丽红（1975-），女，河北邯郸人，博士研究生，讲师，研究方向为理论语言学及语言教学。 -24- 语言学中的研究方法 申丽红1,2 （1. 中国传媒大学 文学院，北京 100021；2. 河北联合大学 外国语学院，河北 唐山 063000） 摘 要：语言学作为社会科学和自然科学的交叉学科，近年来有了长足的发展。各家学者秉承不同的语言学理论，采用不同的研究方法对语言进行了多方位的研究。本文从语言学理论的不同发展阶段对语言学研究方法做一梳理。 关键词：语言学；定量研究；定性研究 中图分类号： H 0-05 文献标识码： A 文章编号：1009-9115(2012)06-0024-03 Some Research Methods of Linguistics SHEN Li-hong 1,2 (1. College of Liberal Arts, The Communication University of China, Beijing 100021, China; 2. College of Foreign Languages, Hebei United University, Tangshan 063000, China) Abstract: Linguistics, as a cross-discipline between natural and social science, has developed well in recent years. Different scholars did some researches on language with different theories and from different angles. A summary about the research methods of linguistics is made. Key Words: linguistics; quantitative research; qualitative research 语言是人类特有的宝贵财产，是人类社会生活的重要组成部分。随着社会发展，文明进步，人们开始从不同角度探索语言的奥秘，以揭示形形色色的言语背后所隐藏的规律，从而形成了林林总总的语言学流派和语言学理论。 任何一门学科的研究方法对于一门学科的发展都是至关重要的。在语言学发展的不同阶段，不同的语言学流派以不同的哲学基础建立起自己的理论框架后，因其学科发展的不同时期以及不同的研究目的而选用不同的研究方法来进行语言学相关研究。 一、语言学发展简史 西方的语言学研究自古希腊始，希腊著名的哲学家苏格拉底（Socrates, BC 470-BC 399），柏拉图（ Plato, BC 429-BC 347）和亚里士多德（Aristotle, BC 384- BC322）等通过对语言的辩论奠定了语言研究的哲学基础。此后语言学在西方历经中世纪、文艺复兴以及19世纪历史比较语言学的发展，随着一些人类学家、哲学家等相继加入语言学研究，语言学学科迅速发展。他们详细研究了语言的分类， 语言中的音变等，为现代语言学的诞生奠定了坚实的基础。 20世纪初，瑞士语言学家索绪尔提出的普通语言学理论使语言学真正成为了一门科学的学科。此后的布拉格学派、哥本哈根学派以及美国的结构主义学派基本上秉承了结构主义的衣钵，对语言的结构、音位等进行了详细的描写和切分。 20世纪50年代，乔姆斯基（Noam Chomsky ）提出了转换生成语法（Transformational-Generative Grammar ）。转换生成语法彻底颠覆了传统的结构主义语法，推动语言学研究进入当代语言学时期。乔姆斯基认为人类获得语言的过程无论采用“白板说”还是“刺激-反应”论都不足以说明问题，以此提出了“先天性假设”（innateness hypothesis ）。他认为人类的大脑先天被内置了一套“普遍语法”（universal grammar ）或“语言普遍现象”（linguistic universals ）。这种普遍语法在后天经验的触发下而形成各种各样的“个别语法”（particular grammar ）。语言学家的任务就是运用数学的运算原理，运用各种规则逐步推导以

Abstract Writing (论文摘要写作精简版)

Writing: Abstract WHAT IS AN ABSTRACT 1. The Definition of an Abstract 1 ) the objectives and scope of investigation; 2) the methods used; 3) the most important results; 4) conclusion or recommendation. 2. Features of Abstracts Brevity Accuracy Specificity Objectivity Informativeness Independency CLASSIFICATION OF ABSTRACTS 1.Indicative Abstracts https://www.wendangku.net/doc/f818786416.html,rmative Abstracts https://www.wendangku.net/doc/f818786416.html,rmative-indicative Abstracts 4.Other Types of Abstracts 1) Critical Abstracts 2) Mini-abstracts FUNCTIONS OF ABSTRACTS A Screening Device of Documents: An abstract gives readers the idea of what the article is about. A Self-contained Text: We’ll know the information it contains, without seeing the article . A Helpful Preview: It "frames" the article and prepares the reader for the main points to come. To Facilitate Indexing: It will improve the chances of having it read by the right people. STYLISTIC FEATURES OF ABSTRACTS 1. The Length of Abstracts 1) In general, there is a 100-300 word limit to the number of words in an abstract. 2) Do not confuse an abstract with a review. There should be no comment or evaluation. 3) Give information only once. 4) Do not repeat the information given in the title. 5) Do not include any facts or ideas that are not in the text. 6) For informative abstracts, include enough data to support the conclusions. 7) If reference to procedure is essential, try to restrict it to identification of method or process. 8) State results, conclusions, or findings in clear concise fashion. 9) Organize the information in the way that is most useful to the reader. (a thesis-first abstract) 2. Verbs and Tenses Used in Abstracts 1) Active verbs: use active verbs rather than passive verbs. 2) Present tense: background information, existing facts, what is in the paper and conclusion. 3) Past tense /present perfect tense: completed research, methodology or major activities results. 3. Words Used in Abstracts 1) Avoid use of highly specialized words or abbreviations. Define unfamiliar words. 2) Synthesize or rephrase the information into clear, concise statements. 3) Avoid using jargon. 4. Sentence Structures of Abstracts 1) Use third person sentences. 2) Use short sentences, but vary sentence structure. 3) Use complete sentences. 4) The first sentence should present the subject and scope of the report. The thesis or the writer's focus should be presented in the second sentence. The balance of the article is a summary of the important points of each section, including methods, procedures, results and conclusions. 5) Good abstracts are sure to include a variety of pat phrases: a. Background Information (Research has shown... It has been proposed... Another proposed property... The search is on for... One of the promising new...) b. Statement of the Problem (The objective of the research is to prove / verify... The experiment was designed to determine...) e. Statement of Procedure (To investigate this .... A group of 10 specimens / subjects ... Measurements

TOPSIS方法研究讲解

TOPSIS分析方法研究 摘要 本文主要介绍了TOPSIS分析方法理论及其主要思想，运用数学理论，对其算法进行了详细的分析，并指出原始方法存在的优缺点；在此基础上提出了一种改进的TOPSIS分析方法，给出具体求权重的方法，突出其客观公正性.本文还分析了TOPSIS方法逆序产生的原因及其改进的方法，突出其实用性，推广其应用范围. 关键词TOPSIS法; 改进的TOPSIS; 权重；逆序

TOPSIS ANALYSIS METHOD ABSTRACT This paper describes a method of theory—TOPSIS, and its main idea. Using mathematical theory, its algorithm for a detailed analysis and noted the advantages and disadvantages of the original methods. On this base ,an improved TOPSIS method is given, and specific for weight, in order to highlight its objective impartiality. The paper also analyzes the causes of TOPSIS Reverse and its improved methods, highlight its practicality and the promotion of its use. Keywords TOPSIS method; Improved TOPSIS; weight; Reverse

论文写作abstract

How to Write an Abstract for a Research Paper WANG Yan School of International Studies UIBE Issues to address: 1What is an abstract? 2Functions of an abstract 3Structure of an abstract 4Principles of abstract writing 1. What is an abstract? ?An abstract is a condensed version of a longer piece of writing that highlights the major points covered, concisely describes the purpose and scope of the writing, and reviews the writing's contents in abbreviated form. ?It is a concise and clear summary of a complete research paper. ?It tells the reader What you set out to do, and Why you did it,How you did it, What you found (recommendations).

2. Functions of an abstract ?An abstract is used to communicate specific information from the article.?It is aimed at introducing the subject to readers, who may then read the article to find out the author's results, conclusions, or recommendations. 2. Functions of an abstract ?The practice of using key words in an abstract is vital because of today's electronic information retrieval systems. ?Titles and abstracts are filed electronically, and key words are put in electronic storage. ?When people search for information, they enter key words related to the subject, and the computer prints out the titles of all the articles containing those key words. ?An abstract must contain key words about what is essential in an article so that someone else can retrieve information from it. 3. Structure of an abstract ?The components of an abstract ①Background Information ②Subject Matter/Problem Statement ③Purpose ④Method (and Data) ⑤Results / Findings ⑥Conclusion / Implications

抽象函数的解题方法与技巧窍门

抽象函数的解题方法与技巧 摘要：抽象函数是没有具体的解析式，只给出它的一些特征、性质或一些特殊关系式的函数。因而显得特别抽象。所以解决抽象函数问题需要从函数的本质出发，考虑其定义，性质，加之解决抽象函数问题时常用的技巧——赋值法，换元法等。尽可能使抽象函数变得不再抽象。 关键词：抽象函数；性质；求值；解析式；解题方法；技巧 Problem-solving methods and skills of abstract functions Xue Jie School of Mathematics and Statistics, Southwest University, Chongqing 400715, China Abstract:: abstract function is not analytic type specific, given only the function characteristics, its nature or some special relationship. So it is especially abstract. So to solve the abstract function problems need from the view of function essence, considering its definition, nature, and solve the abstract function problems commonly used techniques -- assignment method, substitution method etc.. As far as possible to make the abstract function is no longer abstract. Keywords: abstract function; property; evaluation; analytic method; problem solving skills; 1.提出问题的背景 抽象函数问题是函数中的一类综合性较强的问题，这类问题通过对函数性质结构的

研究方法与论文写作

一：对语言学本身性质的阐述分析 并且从不同角度来分析语言学 1《认知语言学的最新应用及展望》述介 【作者】卢植； 【机构】暨南大学外国语学院； 【摘要】Gitte Kristiansen,Michel Achard,Ren啨Dirven&Francisco J.Ruiz de MendozaIb偄 nez(eds.).2006.Cognitive Linguistics:Current Applications and Future Per-spectives.Berlin:Mouton de Gruyter.ix+499pp.1.前言《认知语言学的最新应用及展望》是德国Moutonde Gruyter出版社“认知语言学的应用”系列丛书的第一卷。编者在导言中指出,在过去二三十年间,认知语言学逐渐发展成为一个成熟和创新的学科,并不断演化和拓展。一更多还原 【关键词】认知语言学；最新应用；认知基础；概念隐喻理论；语言学模型；展望；认知科学；计算语言学； 2以认知为基础的英汉对比研究——关于对比认知语言学的一些构想 【作者】文旭； 【机构】西南大学； 【摘要】英汉对比研究是我国语言学界研究的一个主要领域,其研究方法和视角都相当丰富。认知语言学是语言学中的一种新范式。将两者结合起来,建立一门新的学科,即对比认知语言学,必将对认知语言学和对比语言学大有裨益。本文探讨了对比认知语言学的理论基础、对比的原则和方法、对比的范围和内容。可以说,语言系统的任何方面,都可以从认知的角度进行对比研究。更多还原 【Abstract】English-Chinese contrastive study is a major field done in Chinese linguistics,which has a number of research approaches and perspectives. Cognitive linguistics is a new linguistic paradigm. Therefore, it is significant to integrate them into a new discipline called cognitive contrastive linguistics. This paper has explored its theoretical foundations, principles, approaches, scope and content. We can say that any aspect of language system can be studied contrastively from the perspective of cog... 更多 还原 3认知社会语言学