An Evaluation of Design Rule Spaces as Risk Containers

It is well understood that software development can be a risky enterprise and industrial projects often overrun budget and schedule. Effective risk management is, therefore, vital for a successful project outcome. Design Rule Spaces (DRSpaces) have been used by other researchers to understand why implemented software is error-prone. This industrial case study evaluates whether such spaces are durable, meaningful, and isolating risk containers. DRSpaces were created from UML class diagrams of architectural design artefacts. In our study, object orientated metrics were calculated from the UML diagrams, and compared to the error-proneness of the DRSpace implementation, to determine whether architectural coupling translated into implementation difficulties. A correlation between architectural coupling and error-proneness of DRSpaces was observed in the case study. Software developers were asked to identify DRSpaces they found difficult to implement, in order to understand which factors, other than architectural coupling, were also important. The qualitative results show agreement between the code areas developers found difficult to implement and the error-prone DRSpaces. However, the results also show that architectural coupling is just one risk factor of many. The case study suggests that architectural DRSpaces can be used to facilitate a targeted risk review prior to implementation and manage risk

Correlations between cancellous bone architecture and its dynamic behaviour

Previous studies showed that in vivo evaluation of the fracture risk of cancellous bone can be assessed by identifying the relationships between its microarchitecture description extracted from clinical imaging and its mechanical properties. The mechanical properties under dynamic loadings (with and without confinement) were obtained and compared to quasi-static ones. The architectural parameters of each specimen were extracted from pQCT images and split into four groups: geometry, topology, connectivity and anisotropy. Results show that architectural parameters are strong determinants of mechanical behaviour for the different applied boundary conditions.http://icills2014.org/wp-content/uploads/2014/01/Marrianne-Prot.pd

Architectural level risk assessment

Many companies develop and maintain large-scale software systems for public and financial institutions. Should a failure occur in one of these systems, the impact would be enormous. It is therefore essential, in maintaining a system\u27s quality, to identify any defects early on in the development process in order to prevent the occurrence of failures. However, testing all modules of these systems to identify defects can be very expensive. There is therefore a need for methodologies and tools that support software engineers in identifying the defected and complex software components early on in the development process.;Risk assessment is an essential process for ensuring high quality software products. By performing risk assessment during the early software development phases we can identify complex modules, thus enables us to enhance resource allocation decisions.;To assess the risk of software systems early on in the software\u27s life cycle, we propose an architectural level risk assessment methodology. It uses UML specifications of software systems which are available early on in the software life cycle. It combines the probability of software failures and the severity associated with these failures to estimate software risk factors of software architectural elements (components/connectors), the scenarios, the use cases and systems. As a result, remedial actions to control and improve the quality of the software product can be taken.;We build a risk assessment model which will enable us to identify complex and noncomplex software components. We will be able to estimate programming and service effort, and estimate testing effort. This model will enable us also to identify components with high risk factor which would require the development of effective fault tolerant mechanisms.;To estimate the probability of software failure we introduced and developed a set of dynamic metrics which are used to measure dynamic of software architectural elements from UML static models.;To estimate severity of software failure we propose UML based severity methodology. Also we propose a validation process for both risk and severity methodologies. Finally we propose prototype tool support for the automation of the risk assessment methodology

Software architectural risk assessment

Risk assessment is an essential part of the software development life cycle. Performing risk analysis early in the life cycle enhances resource allocation decisions, enables us to compare alternative software architectural designs and helps in identifying high-risk components in the system. As a result, remedial actions to control and optimize the process and improve the quality of the software product can be taken. In this thesis we investigate two types of risk---reliability-based and performance-based risk. The reliability-based risk assessment takes into account the probability of the failures and the severity of failures. For the reliability-based risk analysis we use UML models of the software system, available early in the life cycle to come up with the risk factors of the scenarios and use cases. For each scenario we construct a Markov model to assess the risk factors of the scenarios and its risk distribution among the various classes of severity. Then we investigate both independent use cases and use cases with relationships, while obtaining the system-level risk factors. (Abstract shortened by UMI.)

Towards Realizability Checking of Contracts using Theories

Virtual integration techniques focus on building architectural models of systems that can be analyzed early in the design cycle to try to lower cost, reduce risk, and improve quality of complex embedded systems. Given appropriate architectural descriptions and compositional reasoning rules, these techniques can be used to prove important safety properties about the architecture prior to system construction. Such proofs build from "leaf-level" assume/guarantee component contracts through architectural layers towards top-level safety properties. The proofs are built upon the premise that each leaf-level component contract is realizable; i.e., it is possible to construct a component such that for any input allowed by the contract assumptions, there is some output value that the component can produce that satisfies the contract guarantees. Without engineering support it is all too easy to write leaf-level components that can't be realized. Realizability checking for propositional contracts has been well-studied for many years, both for component synthesis and checking correctness of temporal logic requirements. However, checking realizability for contracts involving infinite theories is still an open problem. In this paper, we describe a new approach for checking realizability of contracts involving theories and demonstrate its usefulness on several examples.Comment: 15 pages, to appear in NASA Formal Methods (NFM) 201

Towards better protection of modern twentieth century architecture in Malta

This paper attempts to highlight the need to promote more awareness of the value of twentieth century buildings in Malta and to intensify their protection. What to keep and maintain is debatable and depends on which philosophies of restoration are adopted. Heritage protection institutions, such as ICONOMOS, UNESCO and the Council of Europe intend to afford the same protection to modern architecture previously reserved for much older buildings. In Malta the legal framework has long been set up to protect the architectural heritage that has been classified and scheduled according to the guidelines of these institutions but the emphasis is on pre-1920’s buildings. Unless the list is updated regularly to include examples of architecture of later periods there is the risk of losing these in the frenzy of the rapid development occurring at present. Educating citizens to value these buildings and even any architectural features and interior décor inspired by this period, should hopefully lead to a higher level of protection. As an example, the lens will be focused on the Gian Frangisk Abela Junior College.peer-reviewe

Tigger paper : integration

The process of architecture will always be holistic. As long as it is taught in segments, its educational structure will always run the risk of failing to meet this primary educational aim, and be continually shooting itself in the foot. The pedagogical and professional advantage to breaking the perceived lack of integration between studio and subject classes is I believe a fundamental imperative, to recognise that every part of the architectural process is not in contradiction but has equal value, and to realise the added value that integration would bring to all parts of the educational process, to staff and student alike

New architectural design of delivery room reduces morbidity in preterm neonates: a prospective cohort study

Background: A multidisciplinary committee composed of a panel of experts, including a member of the American Academy of Pediatrics and American Institute of Architects, has suggested that the delivery room (DR) and the neonatal intensive care units (NICU) room should be directly interconnected. We aimed to investigate the impact of the architectural design of the DR and the NICU on neonatal outcome. Methods: Two cohorts of preterm neonates born at < 32weeks of gestational age, consecutively observed during 2years, were compared prospectively before (Cohort 1: "conventional DR") and after architectural renovation of the DR realized in accordance with specific standards (Cohort 2: "new concept of DR"). In Cohort 1, neonates were initially cared for a conventional resuscitation area, situated in the DR, and then transferred to the NICU, located on a separate floor of the same hospital. In Cohort 2 neonates were assisted at birth directly in the NICU room, which was directly connected to the DR via a pass-through door. The primary outcome of the study was morbidity, defined by the proportion of neonates with at least one complication of prematurity (i.e., late-onset sepsis, patent ductus arteriosus, intraventricular hemorrhage, periventricular leukomalacia, bronchopulmonary dysplasia, retinopathy of prematurity and necrotizing enterocolitis). Secondary outcomes were mortality and duration of hospitalization. Statistical analysis was performed using standard methods by SPSS software. Results: We enrolled 106 neonates (56 in Cohort 1 and 50 in Cohort 2). The main clinical and demographic characteristics of the 2cohorts were similar. Moderate hypothermia (body temperature ≤ 35.9° C) was more frequent in Cohort 1 (57%) compared with Cohort 2 (24%, p = 0.001). Morbidity was increased in Cohort 1 (73%) compared with Cohort 2 (44%, p = 0.002). No statistically significant differences in mortality and median duration of hospitalization were observed between the 2 cohorts of the study. Conclusions: If realized according to the proposed architectural standards, renovation of DR and NICU may represent an opportunity to reduce morbidity in preterm neonates

ArchOptions: A Real Options-Based Model for Predicting the Stability of Software Architectures

Architectural stability refers to the extent an architecture is flexible to endure evolutionary changes in stakeholders\' requirements and the environment. We assume that the primary goal of software architecture is to guide the system\'s evolution. We contribute to a novel model that exploits options theory to predict architectural stability. The model is predictive: it provides \"insights\" on the evolution of the software system based on valuing the extent an architecture can endure a set of likely evolutionary changes. The model builds on Black and Scholes financial options theory (Noble Prize wining) to value such extent. We show how we have derived the model: the analogy and assumptions made to reach the model, its formulation, and possible interpretations. We refer to this model as ArchOptions