Structural Interface for Automated Compliance Checking

This paper describes the benefits of cost reduction and improved schedule attainment by adding digitized regulatory structural rules and contract specification requirements to the 3D design model through Knowledge Provisioning.

Analysis Of Project Success Inhibition Factors

In the implementation of activities we often find what is called a project. The project is an activity that must be completed in accordance with the specified target and time, so that the project can be regarded as a success in project implementation. One of the projects in ques-tion is the construction project. Construction projects in their implementation we often encounter various kinds of problems that arise from the elements involved in them, so this can hamper the success of a project that is being implemented. One problem that arises from the contractor factor and contract specification. The purpose of this study is to find out one of the main inhibiting factors in the successful implementation of construction projects in Aceh Province. Classification of construction services for respondents is all construction ser-vices from the middle class (M) to large classes (B). The data obtained the total population of construction services as many as 508 con-tactors from observations of projects that have been completed from 2010-2015 with funds from the Aceh Budget (APBA). By using the Slovin formula a total sample of 84 contractors was found. The method used in this study is a combined method, namely qualitative and quantitative methods through questionnaires. The independent variables reviewed are the contractor factor and the contract specification factor while the dependent variable is the success of the project. For statistical analysis the data process is done by using validity and reliability tests, while analyzing the data is done by using multiple linear regression with the help of Product Solution and Service Statis-tics (SPSS) version 22. The results of the study indicate that the contractor factor is one of the main inhibiting factors in the successful implementation of the project in Aceh Province.

Determinants of Violations in the SET50 Index Options Pricing Relationships: Put-Call-Futures Parity and Box Spread Tests

Although SET50 Index Options, the only option product on Thailand Futures Exchange, has been traded since October 29, 2007, it has faced the liquidity problem. The SET50 Index Options market must offer a risk premium to compensate investors for liquidity risk. It may cause violations in options pricing relationships. This research therefore uses daily data from October 29, 2007 to December 30, 2016 to compare the violations in SET50 Index Options pricing relationships before and after change in contract specification on October 29, 2012 and investigate determinants of these violations using Tobit model. Two tests of SET50 Index Options pricing relationships, Put-Call-Futures Parity and Box Spread, are employed. The test results of Put-Call-Futures Parity show that the percentage and baht amount of violations in many cases are greater in the period before the modification of SET50 Index Options. Without transaction costs, we also see more Box Spread violations before contract adjustment. However, after taking transaction costs into account, there are more percentage and baht amount of Box Spread violations in the later time period. The estimation of Tobit model shows that the violation sizes of both Put-Call-Futures Parity and Box Spread, excluding transaction costs, depend on the liquidity of SET50 Index Options market measured by option moneyness and open interest. The SET50 Index Options contract specification, especially exercise price, also significantly affects the size of violations, though the direction of a relationship is not cleared.

NeoIDL: A Domain Specific Language for Specifying REST Contracts Detailed Design and Extended Evaluation

Service-oriented computing has emerged as an effective approach for integrating business (and systems) that might spread throughout different organizations. A service is a unit of logic modularization that hides implementation details using well-defined contracts. However, existing languages for contract specification in this domain present several limitations. For instance, both WSDL and Swagger use language-independent data formats (XML and JSON) that are not suitable for specifying contracts and often lead to heavyweight specifications. Interface description languages, such as CORBA IDL and Apache Thrift, solve this issue by providing specific languages for contract specifications. Nevertheless, these languages do not target to the REST architectural style and lack support for language extensibility. In this paper we present the design and implementation of NeoIDL, an extensible domain specific language and program generator for writing REST based contracts that are further translated into service’s implementations. In addition, we also present a systematic evaluation of our approach from different perspectives, which involved the implementation of different services using NeoIDL from the domain of Command & Control. In particular, we found initial evidences that shows that NeoIDL can contribute: (i) to bring return on investment with respect to the design and development of NeoIDL, after the implementation of 4 to 7 services; and (ii) to reduce significantly the number of lines of specification when compared to an existing service specification language such as Swagger.

Specification of Non-functional Requirements and Their Trade-offs in Service Contracts in the NGOSS Framework

The community of Operation Support Systems (OSS) for telecom applications defined a set of fundamental principles, processes, and architectures for developing the Next Generation OSS through the TeleManagement Forum TMF. At the heart of NGOSS lies the notion of a “Contract” which embodies the specification of services offered by an OSS component for quality management and product evaluation. However, TMF does not provide any method (or process) for specification of the non-functional part in the NGOSS contract specification. This chapter develops a systematic approach for specifying non-functional requirements of telecom OSS applications for contracts in the NGOSS framework for quality management and evaluation. Specifically, two categories of non-functional specification techniques are explored: qualitative and quantitative. Furthermore, two quantitative non-functional requirements specification methods are introduced: crisp and elastic to expand the capability of the current NGOSS contract specification method since only qualitative non-functional specification is currently available from TMF. In addition, a technique is developed for specification of trade-offs between non-functional requirements.