Free Essay

Dynamic Model for Cots Glue Code Development and Cots Integration

In:

Submitted By eltantillo
Words 6667
Pages 27
Dynamic Model for COTS Glue Code
Development and COTS Integration
Wook K. Kim and Jongmoon Baik
Department of Computer Science
University of Southern California
{wookkyuk,jobaik}@usc.edu

1. Introduction
1.1 Problem Statement and Description
One of the most significant changes in the software development area is the trend of building systems incorporating pre-existing software, with special emphasis upon the use of commercial-off-the-shelf (COTS) software components. COTS describes software commercially available as stand-alone products and which offer specific functionality needed by a larger system into which they might be incorporated. The purpose of using
COTS is to lower overall development costs with involving less development time by taking advantage of existing, market-proven, and vendor supported products. But we have no control over the functionality, performance, and evolution of COTS products since their Black-Box nature. Besides, most COTS products are not designed to interoperate with each other and most COTS vendors do not support glue code (sometimes called glueware and binding code). So, most software development teams that use COTS components have difficulties in estimating effort and schedule for COTS glue code development and integration of them into application systems.
Without the glue code, the components would be un-integratable and COTS-based systems can be difficult to comprehend, less evolvable than intended, and less reliable than the original components [4].
Most software development teams have also problems in deciding when they start to develop the glue code and to integrate them into system. It highly depends on some factors such as number of COTS components, requirement specification, and availability of COT component required for the developing system.

1.2 Purpose of Study
The engineering of COTS-based systems continues to involve significant technical risk.
A good indicator of the as-yet unresolved difficulties involved in building COTS-based systems is the “glue code” used to integrate components. This code is often ad hoc and

1/28

brittle, but it is needed to repair mismatched assumptions that are exhibited by the components being integrated.
The main objective of this study is to understand how glue code development process and
COTS integration process affect each other and analyze how they have an effect on schedule and efforts of glue code development and integration of components into the developing system throughout the lifecycle.

1.3 Purpose of Model Building
In order to resolve the problems mentioned in the previous section, we will implement dynamic simulation model for glue code development and COTS integration. Using this model, we will simulate how integration process is affected by various factors such as number of COTS, percentage of updated and new COTS, and requirement specification.
Especially, we will calibrate COCOTS component parameters (COTS Product Maturity,
COTS Supplier Product Extension Willingness, COTS Product Interface Complexity,
COTS Supplier Product Support, COTS Supplier Provided Training and Documentation)
[1]. We will analyze staffing levels according to concurrency profiles between glue code development and application development (or custom component development) and simulate how various starting points of glue code development have an effect on system integration process productivity. And, we will analyze the impact of new parameters such as ratio of new and updated COTS component and number of COTS component.
Finally, we will suggest several efficient scenarios for glue code development and integration process.

2. Background
2.1 System Description
The system dynamic model we built consists of four sub-models: application development, glue code development, COTS component parameter, and human resource models. Glue code for COTS components is the new code needed to get a COTS product integrated into a larger system. It is usually clearly defined as connected to the COTS component itself, acting more as a “bridge” between the COTS component and the system into which it is being integrated [1]. It can be code needed to connect a COTS component either to higher-level system code, or to other COTS components used in the system as shown in Figure 2-1.
Glue code is considered as one of following: 1) any code required to facilitate information or data exchange between the COTS component and the application, 2) any code needed to "hook" the COTS component into the application, even though it may not necessarily facilitate data exchange, and 3) any code needed to provide functionality that was originally intended to be provided by the COTS component, AND which must interact with that COTS component [1].

2/28

COCOTS parameters for the Glue code development model are divided into three categories. First, Personnel Drivers represent characteristics of COTS integrator personnel. Second, Application/System Drivers represent characteristics of the system into which COTS is being integrated. Third, COTS Component Drivers are the most important drivers because they represent characteristics of the integrated COTS component itself, so we will simulate and verify our simulation model based on these parameters. These COTS Component Drivers are divided as COTS Product Maturity,
COTS Supplier Product Extension Willingness, COTS Product Interface Complexity,
COTS Supplier Product Support and COTS Supplier Provided Training and
Documentation.
Figure 2-1 represents overall COTS-based system diagram. COTS can be multiple different modules and glue code modules are needed for connecting COTS with application system or between COTS. Although COTS can be integrated into application system directly, many of COTS also can be integrated into another COTS.

[Figure 2-1 Overview Diagram]
As mentioned earlier, COTS component is integrated with application component or another COTS component. Figure 2-2 adopted from [1] shows glue codes are used for connecting interfaces of COTS component and application component. Here, glue code development process is determined by interfaces of these two components. If the nature of the interfaces of the COTS component and the application component is complex, it is more difficult to develop glue code for those components.

3/28

[Figure 2-2 Glue Code Configuration Diagram]
Figure 2-3 represents overall system configuration of COTS integration and glue code development process. COTS component parameters affect glue code development process and some of the parameters also affect application code development process.
Nature of COTS component has an effect on application system development. However, nothing can affect COTS component because of the black-box nature. Integrated system is made up from application system and glue code. Glue code component and COTS component determines the integration productivity. We will implement our simulation model based on this system configuration model.

[Figure 2-3 System Configuration of COTS glue code development and integration]

4/28

2.2 System Reference Behavior
It is very important to observe reference behavior patterns in order to characterize the dynamic phenomenon occurred in our simulation model.
1. The productivity rates of glue code development tend to be smaller than that of application development since glue code development is constrained by the architecture of application system.
2. System integration productivity rate tends to be decreased if number of COTS is increased. However, number of COTS component does not affect glue code development. For example, let’s suppose that two application systems involved in
COTS integration project. Glue code requirements for two applications are each
1000 SLOC. But one application system integrates one COTS component and the other application system integrates 10 COTS components. In this case, glue code development productivity for two cases is same. However, integration productivity for 10 COTS is smaller than that of one COTS.
Number of COTS
Case A
Case B



Total Glue Code
SLOC
1
1000
10
1000
[Table 2-1 Number of COTS analysis]

Glue Code per a
COTS
1000
100

Glue Code Development Schedule: Case A = Case B
Integration Schedule: Case A < Case B

3. Glue code development rate is affected by the percentage of new and updated COTS component. If the percentage of updated COTS component is increased, glue code development rate will be increased because glue code also can be updated from the previous version.
4.

Effort profiles of glue code development tend to be smaller than that of application development because requirements of glue code development is smaller than that of requirements of application development and this behavior is observed from
COCOTS Data Collection Program from USC-Center for Software Engineering [6].

5/28

2.3 Assumptions and Underlying Rationale
In order to develop the simulation model, we made some assumptions.
1. This simulation model is focused on the glue code development and their effect to the integration process, so application development and workforce effort is briefly simulated. 2. Parameters, which are not COTS component drivers, are set to be nominal value.
3.

Because of following reasons, the final integrated system will be composed of glue code and application code except for COTS component.
• Because of the black-box nature of COTS component, we are not able to know the size of the COTS component.
• In case of that COTS will be upgraded in the future, COTS component is considered as a separate module.

4. Starting point of glue code development and COTS integration is based on the completion ratio of application and glue code development. For example, if the percentage of completed application reaches at X% of the total application requirements, the glue code development process is s tarted. As the same way, if the percentage of developed glue code reaches at X% of the total glue code requirements, the integration process is started concurrently.
5. As mentioned earlier, many scenarios for starting points of the integration and glue code development will be presented in order to determine the most efficient starting point for the system integration with COTS component.
6. For simplicity, we assume that this simulation model does not allow feedbacks to the outside of the system boundary such as re-evaluation of the COTS products and feedback to the requirements definition for COTS and feedback to the COTS product selection process.

3. Model Development
3.1 Modeling Process
Since our simulation model is different from traditional application development model, the simulation process is specifically tailored to accommodate COTS product integration and it causes a set of assumptions and constraints quite different from traditional application development.
The simulation model supports concurrent developing activities for glue code development and application development and integration between COTS component and application component.

6/28

[Figure 3-1 Static COTS simulation model]
Our first simulation model shown in Figure 3-1 was a static model of glue code development. We defined five parameters for COTS component. These were the only factors, which have an effect on the glue code development. Only one COTS component is simulated and integrated in the simulation model. But current model is dynamically modeled with glue code development and application development.
They are concurrently developed and integrated. According to the completed rate of application, the production rate of glue code is determined.
Our first intention of this model when we start this project is to find dynamic effects of
COTS component parameters. But we concluded that COTS component parameters do not have any dynamic aspects. So, our objective is changed to find dynamic effects between glue code development and integration process caused by the static COTS component parameters.
This simulation model consists of four sub-models, which are glue code development, application system development and integration, COTS component parameters, and human resource. We will discuss those sub-models in details in the next section.

3.2 Data Acquisition
Data for this simulation is acquired from COCOTS Data Collection Program from USCCenter for Software Engineering. For convenience, they are providing for download copies of the COCOTS research overview statement, the COCOTS data collection instrument, and the standard confidentiality agreement USC-CSE enters into with most of their data suppliers. Data points contain COTS related project regarding glue code development. Based on 13 project data among 20 projects from COCOTS database, we built this simulation model.

7/28

4. Model Description
As mentioned earlier, the simulation model for COTS integration and glue code development consists of four sub models. These four models are correlated to each other as followed Figure 4-1. The details of sub-models will be explained in the next sections.

[Figure 4-1 High-Level Design]
Figure 4-2 represents model timeframe.
The model consists of three different development processes. Starting point of glue code development is depends on the application development and integration is depends on the glue code development.

TIME

Application Development
Inception

Elaboration

Construction

MODULE

Transition
Glue Code

Integration

[Figure 4-2 Model Timeframe]

4.1 Glue Code Development Module
This module represents glue code development model from the system. The simulation model is represented in the Figure 4 The development process of glue code consists of
-3.
three levels. The completed glue code is added to completed application code for integration. Integration process is represented in the application development sub-model.
In this model, COTS components are divided into new COTS component and upgraded
COTS component. In case of the upgraded COTS component, glue code is modified

8/28

from previous version. So, glue code development productivity is higher at integrating updated COTS component than integrating new COTS component. Results of sensitivity analysis of glue code development process based on the percentage of new and upgraded
COTS is explained next section. Concurrency between design phase and implementation phase is explained.
*Caution: When changing GC_Rqmts to other value, GC_Total_Tasks also has to be changed as the same value.

[Figure 4-3 COTS Glue Code Development]











Upgraded COTS%: The percentage of upgraded COTS component. In this case,
Glue code will be modified from previous version. So development rate is higher than integrating new COTS component
New COTS%: The percentage of totally new COTS component
GC Rqmts: Glue Code Requirements as SLOC
Completed_GC: This level represents SLOC that have been implemented.
Completed_GC2: This level represents SLOC that have been implemented.
Difference from Completed_GC is that this value does not flow to the integration phase. It is for calculating cumulated completed glue code.
GC_Dev_Rate: Glue code implementation rate per month. If there is no tasks that can be developed (i.e. constrained by process concurrence), then development rate
=0
GC_Dev_Rate2: Same value with GC_Dev_Rate
Designed_GC: This level represents SLOC that have been designed.
GC_Design_Rate: Glue code design rate per month
GC_Dev_Rate: If there is no tasks that can be developed (i.e. constrained by process concurrence), then development rate = 0.

9/28








concurrence_constraint: The constraint flag is set based on whether there are tasks that can currently be developed per the concurrence relationship (1 = constrained)
GC_Comple_ratio: Percentage of completed glue code. This parameter affects to the integration process and determines glue code staffing level.
GC_Design_Productivity: The nominal glue code design productivity as
SLOC/person-month.
GC_dev_Productivity: The nominal glue code implementing productivity as
SLOC/person-month.
GC_Total_Tasks: Glue code tasks to be specified and developed. available_to_develop%: This concurrence relationship describes the percent of tasks that are available to be developed as a function of the tasks specified to-date.

4.2 COTS Component Factor Module
This module represents COTS component factor module from the system.
GC_Dev_Multiplier is calculated by multiplying five COCOTS parameters, which are
ACPMT, ACSEW, APCPX, ACPPS, ACPTD. App_Compl_ratio is used as an overhead to glue code development from application development. Especially, ‘Direct EAF Input’ can be used for determining EAF value directly without considering COTS parameter data and this feature can be used for verification of theoretical parameter values. .

[Figure 4-4 COTS Component Factor]

10/28



COTS Component Driver Specifications

1) ACPMT (COTS Product Maturity) – This parameter represents COTS product maturity. The value of this parameter is estimated by time on market of the product.
2) ACSEW (COTS Supplier Product Extension)– COTS supplier’s willingness to change features of COTS component is specified. It is estimated by observing number of changes supplier make into the COTS component and the complexity of the change.
3) APCPX (COTS Product Interface Complexity)– It represents interface complexity of COTS product. I the interface of COTS component is complex, it is difficult to f integrate COTS component into application system. The degree of the complexity is calculated by Table 4-1 [1].
4) ACPPS (COTS Supplier Product Support)– COTS supplier’s technical support is represented by this parameter. It contains technical supports for the integration team during the development, either directly from the component suppliers or through third parties. 5) ACPTD (COTS Supplier Provided Training and Documentation) – Provided training and documentation from COTS supplier is numerated. It is calculated by estimating the period of training and coverage of COTS product within documentation. Complexity
Elements
Interface
Conventions (e.g., naming, relevant usage scenarios, service signature, service order)
Control Aspects
(e.g., consistent and clear error handling/recovery) Data (e.g., conversion, number/range typing) Very Low
(point
value = 1)
N/A

Low (point value = 2)

Nominal (point value = 3

High (point value = 4)

Nearly all API conventions are clear and consistent. Most API conventions are clear and consistent. Few API conventions are clear and consistent. N/A

Nearly all control aspects are well defined and consistently applied. Most control aspects are well defined and consistently applied.

Few control aspects are well defined and consistently applied.

No data conversion required.

Little data conversion required and standard data types used.

Some data conversion required and standard data types used.

Corresp onding Points

No control aspects are well defined and consistently applied. Significant data
Extensive data conversion conversion required and/or required and/or use of nonuse of nonstandard data standard data types. types.
Total Point Score =___________

[Table 4-1 Interface Complexity Criteria]

11/28

Very High
(point value =
5)
API conventions are nonexistent.

Table 4-2 represents guidelines for determining model inputs for COTS component parameters. COCOTS Data represents definitions for each category from COCOTS.
Model Input is calibrated value for iThink input parameters within the simulation.
Time on Market
Very Low
Low
Model Input
0
0.3
COCOTS Data
Pre-release
6 months
Number of changes suppliers make
Very Low
Low
Model Input
1
3
COCOTS Data
No changes
3 changes
Nature of changes suppliers make
Very Low
Low
Model Input
0
0.5

Nominal
1
1 year

Degree of Data Conversion
Very Low
Low
Model Input
1
2
COCOTS Data Not required
Little data conversion required

Very High
2
2 year

Nominal
5
5 changes

High
7
7 changes

Very High
9
9 changes

Nominal
1

COCOTS Data
Minor Changes
Level of Tech Support Available
Very Low
Low
Model Input
1
2
COCOTS Data unsupported Telephone
Amount of Document Available
Very Low
Low
Model Input
0
¼
COCOTS Data No documents
¼ of needed
Degree of Interface Convention
Very Low
Low
Model Input
0
1
COCOTS Data Not applicable
All API consistent Degree of Defined Control Aspect
Very Low
Low
Model Input
0
2
COCOTS Data Not applicable
All consistent

High
1.5
1.5 year

High
1.5

Very High
2
Major changes

Nominal
3
Help desk

High
4
Trained support

Very High
5
consulting

Nominal
2/4
2/4 of needed

High
¾
¾ of needed

Very High
1
All needed

Nominal
2
Most API consistent High
3
Few API consistent Very High
4
API nonexistent Nominal
3
Most consistent High
4
Few consistent

Very High
5
nonexistent

Nominal
3
Some data conversion required

High
4
Significant data conversion required [Table 4-2 Model input Guidelines for COTS Parameters]

12/28

Very High
5
extensive data conversion required

4.3 Application Development / Integration Module
This model represents application development and integration model from the system.
Application development model consists of three levels. They are same with the glue code development. Completed application is flow to the integrated system with the completed glue code from previous section.
When integrating COTS component, number of COTS components is an important factor to determine integration process. If number of COTS is higher, then integration process is slower. It is explained in section
2.2. Results from sensitivity analysis of integration process based on the number of
COTS will be followed in next section.
One of most important parameters in this sub-model is Integration_Starting_Point. This parameter is for determining the stating point of integration process based on the glue code development process. For example, if this parameter is 0.5, then integration process is started when the glue code development process completed 50 % of glue code requirements. We will simulation this model with various different percentages in order to determine the most efficient starting point of the integration process.
GC_Overhead represents glue code completion rate. If percentage of completed glue code is bigger, application development productivity is higher.
*Caution: When changing App_Rqmts to other value, App_Total_Tasks also has to be changed as the same value.

[Figure 4-5 Application Development / Integration]


App_Rqmts: This level represents the application requirements as SLOC left to be implemented. 13/28


















Completed_App: This level represents SLOC that have been implemented.
Designed_App: This level represents SLOC that have been designed.
App_Design_Rate: Application design rate per month.
App_Dev_Rate: Application implementation rate per month.
App_Integration_Rate: Application integration rate per month
Integrated_system: This level represents SLOC that have been integrated. It consists of application code and glue code.
App_Compl_ratio: Percentage of completed application. This parameter affects to the integration process.
App_concurrence_constraint_flag: The constraint flag is set based on whether there are tasks that can currently be developed per the concurrence relationship (1 = constrained).
App_design_Productivity: The nominal application design productivity as
SLOC/person-month.
App_dev_Productivity: The nominal application implementing productivity as
SLOC/person-month.
App_Total_Tasks: Application tasks to be specified and developed.
Integration_Productivity: The nominal application integration productivity as
SLOC/person-month.
Number_of_COTS: Number of COTS component to be integrated.
App_available_to_develop%: This concurrence relationship describes the percent of tasks that are available to be developed as a function of the tasks specified to-date.
GC_Overhead: This value is based on the glue code completion rate
Integration_Starting_point: Integration process is started when X % of glue code is completed. 4.4 Human Resources
This sub-model represents human resources from the system. This structure builds on the two-tier infrastructure with the category of rookie and pros. A conveyor is used to represent the Rookies in the organization. Rookie attrition is used to depict leakage flow.
From the Figure 4-6, staffing level for glue code development and application development is separated as ‘GC Dev Person Multiplier’ and ‘App Dev Integration person Multiplier’. The staffing level is determined by requirements levels of glue code and application development.
The most important parameter of this sub-model is ‘GC Staring Point’. This parameter is for determining the stating point of glue code development based on the application development. For example, if this parameter is 0.5, then glue code development is started when the application development process completed 50 % of application requirements.
We will simulation this model with various different percentages in order to determine the most efficient starting point of the glue code development.

14/28

[Figure 4-6 Human Resources]















App_Dev_Integration_person_Multiplier: This parameter represents number of personnel available for application development and integration. Communication overhead is calculated here. If glue code development is finished, then personnel from glue code development is added to here.
App_Dev_Integration_person_Multiplier2: The value of this parameter is same to
App_Dev_Integration_person_Multiplier
Accum_App_Integration_Effort: Accumulated efforts for application development
GC_Dev_Person_Multiplier: This parameter represents number of personnel available for glue code development. Communication overhead is calculated here. If glue code development is finished, then every personnel is used for application development and integration.
GC_Dev_Person_Multiplier2: The value of this parameter is same to
GC_Dev_Person_Multiplier
Accum_GC_Effort: Accumulated efforts for glue code development
GC_Starting_Point: Glue code development process is started when X % of application is completed. comm_overhead: Percent of time spent communicating with other team members as a function of team size.
Pros: Fully productive employees. pro_attrition_rate: 10% of all Pros leave each month. coming_up_to_speed: It takes 5 months before Rookies come up to speed as Pros. laying_off: Layoffs happen at one moment in time. The number you choose will be laid off and then the Slider will reset until you choose to layoff again.

15/28







pros_leaving_firm: The number of Pros leaving the firm each month is a percentage of the total number of Pros at the firm. For the course of the simulation this percentage is assumed to be 10%.
Rookies: For the first 5 months at the firm, all new hires are thought of as Rookies.
After 5 months they have either left or graduated to become Pros. During this 5 month training period, a Rookie is thought to be able to produce about 50% of the work of a Pro. rookies_leaving_firm: The number of Rookies who leave each month. It is assumed that you wish to replace each one that leaves. adjusted_headcount: The adjusted headcount accounts for the fact that Rookies are only half as productive as Pros.

5. Model Verification and Validation
When deciding how to validate this simulation model, I used two approaches. The first approach I use for validating this simulation model is to test with actual data from projects that have already completed and format the data such that it could be entered into this simulation model. The second approach I use for validating this simulation m odel is to test important parameters by sensitivity test.

5.1 Sensitivity Analysis
(1). Sensitivity Analysis of ‘GC_Starting_Point’
As mentioned earlier, this parameter determines glue code development starting point.
To start glue code development, parts of application system should be implemented because glue code is developed based on the application system. We determine glue code development starting point by the percentage of completed application system.
Figure 5-1 represents integrated system by various starting point.

[Figure 5-1 Integrated System when
Starting point of glue code development = 60%, 70%, 80%, 90% 100% of application development completion]
16/28

According to the Figure 5 to start glue code development when 80-90% of application
-1,
is completed has the biggest schedule reduce.
(2). Sensitivity Analysis of ‘Integration_Starting_Point’
This test is for determining starting point of integration process. As mentioned earlier, integration process is started based on t e completed glue code development. According h to Figure 5-2, if integration process starts after 60% of glue code is completed or above, the schedule delay is higher. But if integration process is start before that point, there is very small schedule delay. Specifically, if the integration process start when 30-40% of glue code developed, the schedule delay is the smallest.

[Figure 5-2 Integrated System when
Starting point of integration = 0% - 100% of glue code development completion]
(3). Sensitivity Analysis of ‘Number of COTS’
Although glue code requirements are same, if numbers of COTS component are different, the integration productivity is different. This sensitivity analysis is based on various total
COTS component number. According to the following graph, integration process is delayed based on the number of COTS. But every other process has the same patterns and values.

17/28

[Figure 5-3 Integrated System at
Number of COTS = 1, 5.33, 9.67, 14, 18.3, 22.7, 27, 31.3, 35.7, 40]
(4). Sensitivity Analysis of ‘New_COTS_%’
When COTS component is integrated, it can be a new COTS component or upgraded one from previous COTS component. If the COTS is the upgraded one, developers do not need to develop totally new glue code. They can upgrade glue code from previous version. I had sensitivity analysis based on the percentage of new COTS component.
According to the following graph, completed glue code is delayed based on the percentage of new COTS. But every other process has the same patterns and values.

[Figure 5-4 Completed Glue Code at
New_COTS % = 1, 0.889, 0.778, 0.667, 0.556, 0.444, 0.333, 0.222, 0.111, 0]

18/28

(5). Sensitivity Analysis of COTS Component Factor-ACPMT
This analysis represents schedule of completed glue code based on the various ACPMT values. ACPMT parameter is determined by time on market of the integrated COTS component. I tested with the value from 1 to 2 years of market time.

[Figure 5-5 Completed Glue Code when
Time on Market is 1, 1.11, 1.22, 1.33, 1.44, 1.56, 1.67, 1.78, 1.89, 2 years]
Figure 5-6 represents schedule of integrated system based on the various time on market values. Although COTS component drivers are calculating efforts of glue code development, according to the following graph, the drivers also have effects on the COTS integration process.

[Figure 5-6 Integrated System when
Time on Market is 1, 1.11, 1.22, 1.33, 1.44, 1.56, 1.67, 1.78, 1.89, 2 years]

19/28

5.2 Causal Loop Diagrams
Although it is not always necessary to use a causal loop diagrams for systems characterized by a high degree of correlation, these diagrams are helpful for obtaining a common understanding of the system components and their relationships before advancing to the formality of flow diagrams. The less a system is structured by physical components and the more it depends on human interaction, then the higher the correlation and the more difficult it is to describe the structure of the system. In these kinds of systems, causal loop diagrams can be very helpful in clarifying the nature of the system
[2].

[Figure 5-7 Feedback Loop(1)]

Figure 5-7 represents a feedback diagram, which is automatically generated from iThink.
If Integrated_system is increased, App_Completion_ratio is also increased because
App_Completion_ratio is calculated by completed application and completed integration.
App_Completion_ratio is one of input data for GC_Dev_Multiplier, so if
App_Completion_ratio is increased, GC_Dev_Multiplier is also increased and it causes to increase GC_Dev_Rate. And Higher GC_Dev_Rate makes higher Completed_GC. It also increases GC_Completion_Ratio.
If Completed glue code is enough,
Integration_Rate is also increased and it causes to increase Integrated_system. This loop is continued until the addition of completed glue code and completed application is same to the integrated system.

20/28

[Figure 5-8 Feedback Loop(1)]

Figure 5-8 represents a feedback diagram of our simulation m odel. This feedback loop is consists of reinforcing (+) loops and counteracting (-) loops are hidden for simplicity.
Completed Glue Code increases Integrated System and Integrated System increase Glue
Code Dev Multiplier according to the Figure 5-7. APCPX, one of Glue Code Dev
Multipliers are affecting App Design Rate, so Glue Code Dev Multipliers can be said to increase Application Design Rate. And increased Application Design Rate also increases
Completed Application. Increased Completed Application also increases Integration
Rate. Application Dev Rate and Glue Code Dev Rate are promoting each other.

21/28

5.3 Scenario Test
For this test, I generated three scenario cases. Basically I used COCOTS data explained in the previous chapter and I systematically varied the time-dependent constants and variables. More scenarios can be generated if required.

Scenario #1
Glue Code Development
GC Rqmts
New COTS %
Upgraded COTS %
GC Design Productivity
GC Dev Productivity
GC Total Tasks
COTS Component Factor
Time on Market
Nature of Change Supplier Make
Number of Changes Supplier Make
Degree of Interface Convention
Degree of Defined Control Aspect
Degree of Data Conversion
Level of Tech Support Available
Amount of Training Available
Amount of Doc Available
Application Dev / Integration
App Rqmts
App Design Productivity
App Dev Productivity
Integration Productivity
Number of COTS Component
App Total Tasks
Human Resources
Rookies
Pros
Coming up to speed
Laying off
Pro Attrition Rate
Rookies leaving firm

Scenario #2

Scenario #3

6150 SLOC
100 %
0%
8 * 25 SLOC / PM
8 * 25 SLOC / PM
6150 SLOC

25000 SLOC
70%
30%
8 * 25 SLOC / PM
8 * 25 SLOC / PM
25000 SLOC

10000 SLOC
30 %
70 %
8 * 25 SLOC / PM
8 * 25 SLOC / PM
10000 SLOC

1 (year)
1 (nominal)
5 (nominal)
3 (nominal)
3 (nominal)
3 (nominal)
3 (nominal)
½ (Half of needed)
½ (Half of needed)

0.3 (year)
2 (high)
7 (high)
4 (high)
2 (low)
2 (low)
3 (normal)
¾ (¾ of needed)
¼ (¼ of needed)

3 (year)
0.5 (low)
3 (low)
2 (low)
2 (low)
2 (low)
3 (normal)
1 (All of needed)
½ (Half of needed)

400000 SLOC
8 * 25 SLOC
6 * 25 SLOC
20 * 25 SLOC
1
40000 SLOC

280000 SLOC
8 * 25 SLOC
6 * 25 SLOC
20 * 25 SLOC
7
280000 SLOC

737000 SLOC
8 * 25 SLOC
6 * 25 SLOC
20 * 25 SLOC
4
737000 SLOC

10,10,10
30
5
0
0.1
0

10,10,10
30
5
0
0.1
0

10,10,10
30
5
0
0.1
0

[Table 5-1 Simulation Scenarios]

22/28

5.3.1 Scenario #1 Test Result
Data for this simulation is adapted from DSR project from COCOTS data. According to the following graphs, glue code development is started when parts of application is started to complete. And there is concurrency in design and implementation phases.
When parts of glue code is started to complete, the integration process start. The integration graph has S-shaped graph. As for personal allocation, staffing pattern is affected by each development phases.

[Figure 5-9 Glue Code Development]

According to Figure 5-9 and 5-10, integration is started although glue code development is not finished. So integration can be finished just after glue code development is finished. Application development rate is reduced when the glue code development is processed because staff moves to the glue code development.

[Figure 5-10 Application Development and Integration]

23/28

[Figure 5-11 Staffing Pattern]
Figure 5-11 represents staffing pattern for glue code development and application development. If glue code development is started, staff moves from application development to glue code development. If glue code development is finished, staff goes back to the application development for integration process.

[Figure 5-12 Accumulated Effort]
Figure 5-12 represents accumulated efforts for glue code development and application development and integration. When the glue code is completed, staffing is moved to the application development process, so the glue code development effort does not increased.
Effort difference between glue code development and application development is because of the initial requirements difference.
Application development efforts contain integration efforts.

24/28

5.3.2 Scenario #2 Test Result

[Figure 5-13 Application Development and Integration]

[Figure 5-14 Glue Code Development]

5.3.3 Scenario #3 Test Result

[Figure 5-15 Application Development and Integration]

[Figure 5-16 Glue Code Development]

Figure 5-13 ~ Figure 5-16 represents test results of scenario #2 and #3 data from Table 51. According to the figures, there is a big schedule difference between the two cases. It is caused by the requirements difference from the two cases. Graphs of two scenarios are similar because we use the same starting points, which are determined in the sensitivity tests. 25/28

6. Model Application and Transition
The integration module from this glue code development and COTS integration simulation model can be applied to other integration process such as system integration containing hardware and software. Figure 6-1 and Table 6-1 represent applicable algorithm for integration process.
Design

Requirements

Implementation

Integration

Software

Implementation
Issues
Design Issues
Requirements
Issues

[Figure 6-1 Integration Process]

Cell
Entry

Feedback/In
Feedback/Out

Design
Approved requirements, changes, and development plan
Inspected and approved design and changes Design issues
Requirements issues

Task

Design

Measures

Resources, Product: Changes,
Errors, Design, Document pages

Exit

Implementation
Inspected and approved design and changes
Inspected and approved code and changes
Implementation issues
Requirements and design issues
Implementation,
inspection, and unit test
Resources, Product:
Changes, Errors, Code,
Document pages

Integration
Inspected and approved code and changes
Inspected, tested, and integrated software
Requirements, design and implementation issues
Integration, system test, system management
Resources, Product:
Changes, Errors, Code,
Document pages, Test suite

[Table 6-1 Integration Process]

7. Conclusions and Recommendations
One of the most interesting analyses of this simulation is to determine starting point of glue code development and integration. According to the sensitive analysis of previous section, glue code development should start when 80% of application (custom-based) components is completed and integration should start when 30% of glue code is completed. We extracts following conclusion regarding starting point of development.
Glue code development has to start in the ending of the application development and integration process has to start in the beginning of the glue code development.

26/28

This COTS integration simulation model was developed to prove the necessity of considering system dynamic relationships rather than rely on statistical correlation when developing glue code and integrating COTS component into system. Software planning and estimating tools such as COCOMO are statistical models, as opposed to system dynamics which incorporates nonlinear equations and feedback loops that describe causal influences on a project. Using these system dynamic relationships provides a realistic approach to modeling a project and facilitating an understanding of the various components. The ability to interact with COTS characteristic parameters during the simulation helps to model true behavior of glue code and integration during a project. A project planner has the ability to perform many "What-If" scenarios quickly and study the trade-offs to alternative approaches to scheduling and staffing decisions. Before investing time and money and implementing a decision that may prove risky, a project planner can simulate the decision and analyze the results.
Although software COTS products are attempting to simulate the "plug-and-play" capability of the hardware world, in today's reality, software COTS products seldom plug into anything easily. Most products require some amount of adaptation to work harmoniously with the other commercial or custom components in the system. The typical solution is to adapt each COTS product through the use of "wrappers," "bridges," or other "glueware.” It is important to note that adaptation does not imply modification of the COTS product [4]. However, adaptation can be a complex activity that requires technical expertise at the detailed system and specific COTS component levels.
This paper has illustrated how a system dynamics model and simulation of the COTS integration and glue code development can be used to assist in predicting when good software productivity levels will be achieved. Our model can be calibrated to a project environment taking into account integration productivity. Our sample runs have illustrated the importance of deciding starting point of integration and correlation of glue code and application development.
Integration with COTS software products requires adjustment and accommodations to the development approach and development process. Preparations must be made to start prototyping activities and integration activities immediately to use COTS product advantages and accelerate development. Additional resources must be allocated for late in the development cycle to provide maintenance and support to the software developers.
As future works, this simulation model can be enhanced for other COCOTS Sub-model such as Assessment, Tailoring, and Volatility. They include feedback to the COTS product selection process and feedback to the requirements definition for COTS products and re-evaluation of the COTS products.

27/28

8. References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]

http://sunset.usc.edu/COCOTS/cocots.html iThink Manual, High Performance Systems, Inc., Hanover, NH.
Brownsword, L., Carney D., Oberndorf, T., “The Oppurtunities and Complexities of Applying COTS Components,” SEI interactive, Vol 2, Issue 3, September 1999.
Fox, G., Marcom, S., Lantner, K., “A Software Development Process for COTSBased Information System Infrastructure,” CROSSTALK, March 1998.
Wallnau, K., Carney, D., Pollak, B., “How COTS Software Affects the Design of
COTS-Intensive Systems,” SEI interactive, Vol 1, Issue 1, June 1998.
Abts, C., Clark, B., “Project Level COTS Integration Experience Survey,” USCCenter for Software Engineering, November 1999.
Abts, C., Boehm, B., “USC-CSE COTS Integration Cost Calculator V2.0 User
Guide,” USC-Center for Software Engineering, September 1997.
Breierova, L., Choudhari, M., “An Introduction to Sensitivity Analysis,” MIT
System Dynamics in Education Project, September 1996.
Carney, D., “Assembling Large Systems from COTS Components: Opportunities,
Cautions, and Complexities,” Software Engineering Institute, June 1997.
Sha, L., Goodenough, J., Pollak, B., “Simple Architecture: Meeting the Challenges of Using COTS in High-Reliability Systems”, CROSSTALK, April 1998.
Ford, D., Sterman, J., “Dynamic Modeling of Product Development Processes,”
Massachusetts Institute of Technology, Cambridge, MA, January 1997.
Madachy, R., Boehm, B., Software Process Dynamics, IEEE Computer Society
Press, 2000
Madachy, R., “CS599 Software Process Modeling Course Notes”, USC-Center for
Software Engineering, November 1999.

28/28

Similar Documents

Premium Essay

Application.Servers.for.E-Business

...Contents Application Servers for E-Business - 2 Preface - 4 Chapter 1 - Introduction - 5 Chapter 2 - A Survey of Web Technologies - 22 Chapter 3 - Java - 44 Chapter 4 - CORBA - 65 Chapter 5 - Application Servers - 82 Chapter 6 - Design Issues for Enterprise Deployment of Application Servers - 114 Chapter 7 - Tying It All Together - 137 References - 160 For More Information - 163 page 1 Application Servers for E-Business Application Servers for E-Business Lisa M. Lindgren Auerbach Library of Congress Cataloging-in-Publication Data Lindgren, Lisa. Application servers for e-business / Lisa M. Lindgren. p.cm. Includes bibliographical references and index. ISBN 0-8493-0827-5 (alk. paper) 1. Electronic commerce. 2. Application software—Development. I. Title. HF5548.32 .L557 2001 658′.0553–dc21 00-050245 This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. Neither this book nor any part may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, microfilming, and recording, or by any information storage or retrieval system, without prior permission in writing from the publisher...

Words: 98260 - Pages: 394

Free Essay

Test

...great web applications. You can read a lot of articles on how it separates the concerns of the application, improves testability, and keeps to web app best practices, but I want to highlight a feature that is not shown off as regularly, extending the document object model API. Introduction to AngularJS Dylan Stamat You will learn about some of the core concepts that make AngularJS shine, including binding data to you views, built-in filtering, and some of the interesting architectural decisions behind this MVC framework. We will build a very simple application with local data that show some of these concepts. Diving into Angular Josh Kuhn In this tutorial we’re going to create a barebones Twitter-like application called Pipr. Pipr allows you to create “pips” which are short 100 character or less “pips” that show up on the page in reverse chronological order. You can add tags to your pips, and you can post them with any name you like. In addition, you can delete your pips. AngularJS 101: A Beginner’s Tutorial Karmen Blake This tutorial on AngularJS will guide you through the fundamentals of the framework. You will explore the exciting benefits of using a client-side JavaScript framework to create dynamic and modern web applications. JEDI SENATUS: an italian open source project aims towards the systematic software reuse in organizations Ciro D’Urso, Alberto Persello, David Visicchio JEDI is a J2EE application that provides a centralized service aiming at significantly...

Words: 22760 - Pages: 92

Premium Essay

Business Management

...scholars since the mid-1970s. However, owing to the evolving meaning of CSR and the huge number of scholars who have begun to analyze the issue in recent years fresh efforts are needed to understand new developments. Since there is a great heterogeneity of theories and approaches, the task remains a very hard one, mainly because heterogeneity derives from multi-disciplinary diversity. The criterion for selection is to consider the role that theorists confer to the firm. Following this idea, three groups of theories have been discerned: (1) the utilitarian group, in which the corporation is intended as a maximizing ‘black box’ where problems of externalities and social costs emerge; (2) the managerial category, where problems of responsibility are approached from inside the firm (internal perspective); (3) relational theories, or those in which the type of relations between the firm and the environment are at the center of the analysis. The three perspectives allow the reader to understand the most significant differences between the various theories of CSR. The objective is to classify the theories and to draw a map in which group specificities can be made available. This allows scholars to reach a better understanding of corporate–society relations, and enhances developments both in theoretical and empirical terms. Introduction The...

Words: 16348 - Pages: 66

Free Essay

Sehandbook

...SYSTEMS ENGINEERING HANDBOOK A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES INCOSE-TP-2003-002-03 June 2006 INCOSE Systems Engineering Handbook v. 3 SYSTEMS ENGINEERING HANDBOOK A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES INCOSE-TP-2003-002-03 INCOSE SYSTEMS ENGINEERING HANDBOOK, version 3 June 2006 Edited by: Cecilia Haskins Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. INCOSE-TP-2003-002-03 June 2006 INCOSE Systems Engineering Handbook v. 3 This INCOSE Technical Product was prepared by the Systems Engineering Handbook Development Team of the International Council on Systems Engineering (INCOSE). It is approved by INCOSE for release as an INCOSE Technical Product. Copyright © 2006 by INCOSE, subject to the following restrictions: Author use: Authors have full rights to use their contributions in a totally unfettered way with credit to this INCOSE Technical Product. Abstraction is permitted with credit to the source. INCOSE use: Permission to reproduce this document and use this document or parts thereof by members of INCOSE and to prepare derivative works from this document for INCOSE use is granted, with attribution to INCOSE and the original author(s) where practical, provided this copyright notice is included with all reproductions and derivative works. Content from ISO/IEC 15288:2002(E) are used by permission, and are not to be reproduced other than...

Words: 63595 - Pages: 255

Premium Essay

B2B Advantages and Disadvantages

...This page intentionally left blank Te n t h E d i t i o n MODERN DATABASE MANAGEMENT Editorial Director: Sally Yagan Editor in Chief: Eric Svendsen Executive Editor: Bob Horan Editorial Project Manager: Kelly Loftus Editorial Assistant: Jason Calcano Director of Marketing: Patrice Lumumba Jones Marketing Manager: Anne Fahlgren Marketing Assistant: Melinda Jensen Senior Managing Editor: Judy Leale Project Manager: Becca Richter Senior Operations Supervisor: Arnold Vila Operations Specialist: Ilene Kahn Senior Art Director: Jayne Conte Cover Designer: Suzanne Behnke Cover Art: Fotolia © vuifah Manager, Visual Research: Karen Sanatar Permissions Project Manager: Shannon Barbe Media Project Manager, Editorial: Denise Vaughn Media Project Manager, Production: Lisa Rinaldi Supplements Editor: Kelly Loftus Full-Service Project Management: PreMediaGlobal Composition: PreMediaGlobal Printer/Binder: Edwards Brothers Cover Printer: Lehigh-Phoenix Color/Hagerstown Text Font: Palatino Credits and acknowledgments borrowed from other sources and reproduced, with permission, in this textbook appear on appropriate page within text. Microsoft® and Windows® are registered trademarks of the Microsoft Corporation in the U.S.A. and other countries. Screen shots and icons reprinted with permission from the Microsoft Corporation. This book is not sponsored or endorsed by or affiliated with the Microsoft Corporation. Copyright © 2011, 2009, 2007, 2005, 2002...

Words: 193467 - Pages: 774

Premium Essay

Holly Farm

...Robert Johnston Stuart Chambers Christine Harland Alan Harrison Nigel Slack Cases in Operations Management third edition Cases in Operations Management We work with leading authors to develop the strongest educational materials in operations management, bringing cutting-edge thinking and best learning practice to a global market. Under a range of well-known imprints, including Financial Times Prentice Hall, we craft high quality print and electronic publications which help readers to understand and apply their content, whether studying or at work. To find out more about the complete range of our publishing, please visit us on the World Wide Web at: www.pearsoneduc.com THIRD EDITION Cases in Operations Management Robert Johnston Warwick Business School, University of Warwick Stuart Chambers Warwick Business School, University of Warwick Christine Harland School of Management, University of Bath Alan Harrison Cranfield School of Management, Cranfield University Nigel Slack Warwick Business School, University of Warwick Pearson Education Limited Edinburgh Gate Harlow Essex CM20 2JE United Kingdom and Associated Companies throughout the world Visit us on the World Wide Web at: www.pearsoned.co.uk First published 1993 Second published 1997 Third Edition 2003 © Robert Johnston, Stuart Chambers, Christine Harland, Alan Harrison and Nigel Slack 1993, 2003 The rights of Robert Johnston, Stuart Chambers, Christine Harland, Alan Harrison...

Words: 207956 - Pages: 832

Free Essay

Physics

...Introductory Physics I Elementary Mechanics by Robert G. Brown Duke University Physics Department Durham, NC 27708-0305 rgb@phy.duke.edu Copyright Notice Copyright Robert G. Brown 1993, 2007, 2013 Notice This physics textbook is designed to support my personal teaching activities at Duke University, in particular teaching its Physics 141/142, 151/152, or 161/162 series (Introductory Physics for life science majors, engineers, or potential physics majors, respectively). It is freely available in its entirety in a downloadable PDF form or to be read online at: http://www.phy.duke.edu/∼rgb/Class/intro physics 1.php It is also available in an inexpensive (really!) print version via Lulu press here: http://www.lulu.com/shop/product-21186588.html where readers/users can voluntarily help support or reward the author by purchasing either this paper copy or one of the even more inexpensive electronic copies. By making the book available in these various media at a cost ranging from free to cheap, I enable the text can be used by students all over the world where each student can pay (or not) according to their means. Nevertheless, I am hoping that students who truly find this work useful will purchase a copy through Lulu or a bookseller (when the latter option becomes available), if only to help subsidize me while I continue to write inexpensive textbooks in physics or other subjects. This textbook is organized for ease of presentation and ease of learning. In particular, they are...

Words: 224073 - Pages: 897

Premium Essay

Problem Solving for Manager

...Creative Problem Solving for Managers Second edition How can managers tackle complex problems? How do you encourage innovation? How do you implement new solutions? Is creativity the key to management success? This accessible text provides a lively introduction to the essential skills of creative problem solving. Using extensive case studies and examples from a variety of business situations, Creative Problem Solving for Managers explores a wide range of problem solving theories and techniques, illustrating how these can be used to solve a multitude of management problems. Thoroughly revised and redesigned, this new edition retains the accessible and imaginative approach to problem solving skills of the first edition. Features include: ■ ■ ■ ■ ■ Blocks to creativity and how to overcome them Key techniques including lateral thinking, morphological analysis and synectics Computer-assisted problem solving Increased coverage of group problem solving techniques New website containing in-depth cases and a PowerPoint presentation As creativity is increasingly being recognised as a key skill for successful managers, this book will be welcomed as a readable and comprehensive introduction for students and practising managers alike. Tony Proctor is Professor in Marketing at Chester University College Business School and was formerly Senior Lecturer in Marketing and Head of the Department of Management at Keele University. Creative Problem Solving for Managers Developing skills...

Words: 109777 - Pages: 440

Free Essay

Industrial Engineering

...McGraw-Hill Create™ Review Copy for Instructor Espinoza. Not for distribution. Course BBE 4505 Omar Espinoza University Of Minnesota NATURAL RESOURCES McGraw-Hill Create™ Review Copy for Instructor Espinoza. Not for distribution. http://create.mcgraw-hill.com Copyright 2012 by The McGraw-Hill Companies, Inc. All rights reserved. Printed in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without prior written permission of the publisher. This McGraw-Hill Create text may include materials submitted to McGraw-Hill for publication by the instructor of this course. The instructor is solely responsible for the editorial content of such materials. Instructors retain copyright of these additional materials. ISBN-10: 1121789048 ISBN-13: 9781121789043 McGraw-Hill Create™ Review Copy for Instructor Espinoza. Not for distribution. Contents 1. Preface 1 2. Methods, Standards, and Work Design: Introduction 7 Problem-Solving Tools 27 3. Tex 29 4. Operation Analysis 79 5. Manual Work Design 133 6. Workplace, Equipment, and Tool Design 185 7. Work Environment Design 239 8. Design of Cognitive Work 281 9. Workplace and Systems Safety 327 10. Proposed Method Implementation 379 11. Time Study 413 12. Performance Rating and Allowances 447 13. Standard Data and Formulas 485 14. Predetermined Time Systems 507...

Words: 294686 - Pages: 1179

Premium Essay

Tongue and Quill

...The Tongue and Quill AFH 33-337 1 AUGUST 2004 Communication is an essential tool for the twenty-first century Air Force BY ORDER OF THE SECRETARY OF THE AIR FORCE AIR FORCE HANDBOOK 33-337 1 AUGUST 2004 Communications and Information THE TONGUE AND QUILL COMMUNICATING IS A POWERFUL TOOL FOR THE TWENTY-FIRST CENTURY AIR FORCE The Tongue and Quill is dedicated to every man and woman in today’s Air Force who will ever sling ink at paper, pound a keyboard, give a briefing, or staff a package to support the mission. Currently, The Tongue and Quill is widely used by Air Force military and civilian members, professional military school educators and students, and civilian corporations around the United States. As United States Air Force employees, it is important we communicate clearly and effectively to carry out our mission. This handbook together with AFMAN 33-326, Preparing Official Communications, will provide the necessary information to ensure clear communications— written or spoken. The use of the name or mark of any specific manufacturer, commercial product, commodity, or service in this publication does not imply endorsement by the Air Force To all you enthusiastic users worldwide, keep up the good fight! SUMMARY OF REVISIONS This revision improved organization; rearranged layout; updated quotes, art and word lists; and added material on preparing to write and speak, writing with focus, communicating to persuade, research, meetings, briefings and listening;...

Words: 125419 - Pages: 502

Free Essay

Environmental Engineering

...CONVERSION FACTORS FROM ENGLISH TO SI UNITS Length: 1 ft 1 ft 1 ft 1 in. 1 in. 1 in. 1 ft2 1 ft2 1 ft2 1 in.2 1 in.2 1 in.2 1 ft3 1 ft3 1 in.3 1 in.3 1 in. 1 in.3 1 ft/min 1 ft/min 1 ft/min 1 ft/sec 1 ft/sec 1 in./min 1 in./sec 1 in./sec 3 0.3048 m 30.48 cm 304.8 mm 0.0254 m 2.54 cm 25.4 mm 929.03 10 4 m2 929.03 cm2 929.03 102 mm2 6.452 10 4 m2 6.452 cm2 645.16 mm2 28.317 10 3 m3 28.317 103 cm3 16.387 10 6 m3 16.387 cm3 0.16387 0.16387 10 mm 10 4 m3 5 3 Coefficient of consolidation: Force: 1 in.2/sec 1 in.2/sec 1 ft2/sec 1 lb 1 lb 1 lb 1 kip 1 U.S. ton 1 lb 1 lb/ft 1 lb/ft2 1 lb/ft2 1 U.S. ton/ft2 1 kip/ft2 1 lb/in.2 1 lb/ft3 1 lb/in.3 1 lb-ft 1 lb-in. 1 ft-lb 1 in.4 1 in.4 6.452 cm2/sec 20.346 103 m2/yr 929.03 cm2/sec 4.448 N 4.448 10 3 kN 0.4536 kgf 4.448 kN 8.896 kN 0.4536 10 3 metric ton 14.593 N/m 47.88 N/m2 0.04788 kN/m2 95.76 kN/m2 47.88 kN/m2 6.895 kN/m2 0.1572 kN/m3 271.43 kN/m3 1.3558 N · m 0.11298 N · m 1.3558 J 0.4162 0.4162 106 mm4 10 6 m4 Area: Stress: Volume: Unit weight: Moment: Energy: Moment of inertia: Section modulus: Hydraulic conductivity: 0.3048 m/min 30.48 cm/min 304.8 mm/min 0.3048 m/sec 304.8 mm/sec 0.0254 m/min 2.54 cm/sec 25.4 mm/sec CONVERSION FACTORS FROM SI TO ENGLISH UNITS Length: 1m 1 cm 1 mm 1m 1 cm 1 mm 1m 1 cm2 1 mm2 1 m2 1 cm2 1 mm2 1m 1 cm3 1 m3 1 cm3 1N 1 kN 1 kgf 1 kN 1 kN 1 metric ton 1 N/m 3 2 3.281 ft 3.281 10 3.281 10 39.37 in. 0.3937 in. 0.03937 in. 2 Stress: 2 3 ft ft 1 N/m2 1 kN/m2...

Words: 183832 - Pages: 736

Free Essay

Eqweqeqqe

...Praise for The Spirit Catches You and You Fall Down “Fadiman describes with extraordinary skill the colliding worlds of Western medicine and Hmong culture.” —The New Yorker “This fine book recounts a poignant tragedy…It has no heroes or villains, but it has an abundance of innocent suffering, and it most certainly does have a moral…[A] sad, excellent book.” —Melvin Konner, The New York Times Book Review “An intriguing, spirit-lifting, extraordinary exploration of two cultures in uneasy coexistence…A wonderful aspect of Fadiman’s book is her even-handed, detailed presentation of these disparate cultures and divergent views—not with cool, dispassionate fairness but rather with a warm, involved interest that sees and embraces both sides of each issue…Superb, informal cultural anthropology—eye-opening, readable, utterly engaging.” —Carole Horn, The Washington Post Book World “This is a book that should be deeply disturbing to anyone who has given so much as a moment’s thought to the state of American medicine. But it is much more…People are presented as [Fadiman] saw them, in their humility and their frailty—and their nobility.” —Sherwin B. Nuland, The New Republic 3/462 “Anne Fadiman’s phenomenal first book, The Spirit Catches You and You Fall Down, brings to life the enduring power of parental love in an impoverished refugee family struggling to protect their seriously ill infant daughter and ancient spiritual traditions from the tyranny of welfare bureaucrats and intolerant...

Words: 134140 - Pages: 537

Premium Essay

Mister

...Contents Title Page Dedication Prologue CHAPTER ONE: Republicans and Democrats CHAPTER TWO: Values CHAPTER THREE: Our Constitution CHAPTER FOUR: Politics CHAPTER FIVE: Opportunity CHAPTER SIX: Faith CHAPTER SEVEN: Race CHAPTER EIGHT: The World Beyond Our Borders CHAPTER NINE: Family Epilogue Acknowledgments About the Author Also by Barack Obama Copyright Prologue IT’S BEEN ALMOST ten years since I first ran for political office. I was thirty-five at the time, four years out of law school, recently married, and generally impatient with life. A seat in the Illinois legislature had opened up, and several friends suggested that I run, thinking that my work as a civil rights lawyer, and contacts from my days as a community organizer, would make me a viable candidate. After discussing it with my wife, I entered the race and proceeded to do what every first-time candidate does: I talked to anyone who would listen. I went to block club meetings and church socials, beauty shops and barbershops. If two guys were standing on a corner, I would cross the street to hand them campaign literature. And everywhere I went, I’d get some version of the same two questions. “Where’d you get that funny name?” And then: “You seem like a nice enough guy. Why do you want to go into something dirty and nasty like politics?” I was familiar with the question, a variant on the questions asked of me years earlier, when I’d first arrived in Chicago to work in low-income neighborhoods. It signaled a cynicism...

Words: 120305 - Pages: 482

Free Essay

The Hunger Games

...G. P. PUTNAM’S SONS An imprint of Penguin Young Readers Group. Published by The Penguin Group. Penguin Group (USA) Inc., 375 Hudson Street, New York, NY 10014, USA. Penguin Group (Canada), 90 Eglinton Avenue East, Suite 700, Toronto, Ontario M4P 2Y3, Canada (a division of Pearson Penguin Canada Inc.). Penguin Books Ltd, 80 Strand, London WC2R 0RL, England. Penguin Ireland, 25 St. Stephen’s Green, Dublin 2, Ireland (a division of Penguin Books Ltd). Penguin Group (Australia), 707 Collins Street, Melbourne, Victoria 3008, Australia (a division of Pearson Australia Group Pty Ltd). Penguin Books India Pvt Ltd, 11 Community Center, Panchsheel Park, New Delhi–110 017, India. Penguin Group (NZ), 67 Apollo Drive, Rosedale, Auckland 0632, New Zealand (a division of Pearson New Zealand Ltd). Penguin Books South Africa, Rosebank Office Park, 181 Jan Smuts Avenue, Parktown North 2193, South Africa. Penguin China, B7 Jiaming Center, 27 East Third Ring Road North, Chaoyang District, Beijing 100020, China. Penguin Books Ltd, Registered Offices: 80 Strand, London WC2R 0RL, England. Copyright © 2013 by Rick Yancey. All rights reserved. No part of this book may be reproduced, scanned, or distributed in any printed or electronic form without permission in writing from the publisher, G. P. Putnam’s Sons, an imprint of Penguin Young Readers Group, 345 Hudson Street, New York, NY 10014. G. P. Putnam’s Sons, Reg. U.S. Pat & Tm. Off. Please...

Words: 124032 - Pages: 497

Free Essay

The Satanic Verses

...Copyright Salman Rushdie, 1988 All rights reserved VIKING Published by the Penguin Group Viking Penguin Inc., 40 West 23rd Street, New York, New York 10010, U.S.A. Penguin Books Ltd, 27 Wrights Lane, London W8 5TZ, England Penguin Books Australia Ltd. Ringwood, Victoria, Australia Penguin Books Canada Ltd, 2801 John Street, Markham, Ontario, Canada L3R 1B4 Penguin Books (N.Z.) Ltd, 182-190, Wairau Road, Auckland ro, New Zealand Penguin Books Ltd, Registered Offices: Harmondsworth, Middlesex, England Published in 1989 by Viking Penguin Inc. For Marianne Contents I The Angel Gibreel II Mahound III Ellowen Deeowen IV Ayesha V A City Visible but Unseen VI Return to Jahilia VII The Angel Azraeel VIII The Parting of the Arabian Seas IX A Wonderful Lamp Satan, being thus confined to a vagabond, wandering, unsettled condition, is without any certain abode; for though he has, in consequence of his angelic nature, a kind of empire in the liquid waste or air, yet this is certainly part of his punishment, that he is . . . without any fixed place, or space, allowed him to rest the sole of his foot upon. Daniel Defoe, _The History of the Devil_ I The Angel Gibreel "To be born again," sang Gibreel Farishta tumbling from the heavens, "first you have to die. Hoji! Hoji! To land upon the bosomy earth, first one needs to fly. Tat-taa! Taka-thun! How to ever smile again, if first you won't cry? How to win the darling's love, mister, without a sigh? Baba, if you want to get born again...

Words: 195828 - Pages: 784