Gamma Rays from Compton Scattering in the Jets of Microquasars: Application to LS 5039

Recent HESS observations show that microquasars in high-mass systems are sources of VHE gamma-rays. A leptonic jet model for microquasar gamma-ray emission is developed. Using the head-on approximation for the Compton cross section and taking into account angular effects from the star's orbital motion, we derive expressions to calculate the spectrum of gamma rays when nonthermal jet electrons Compton-scatter photons of the stellar radiation field. Calculations are presented for power-law distributions of nonthermal electrons that are assumed to be isotropically distributed in the comoving jet frame, and applied to $\gamma$-ray observations of LS 5039. We conclude that (1) the TeV emission measured with HESS cannot result only from Compton-scattered stellar radiation (CSSR), but could be synchrotron self-Compton (SSC) emission or a combination of CSSR and SSC; (2) fitting both the HESS data and the EGRET data associated with LS 5039 requires a very improbable leptonic model with a very hard electron spectrum. Because the gamma rays would be variable in a leptonic jet model, the data sets are unlikely to be representative of a simultaneously measured gamma-ray spectrum. We therefore attribute EGRET gamma rays primarily to CSSR emission, and HESS gamma rays to SSC emission. Detection of periodic modulation of the TeV emission from LS 5039 would favor a leptonic SSC or cascade hadron origin of the emission in the inner jet, whereas stochastic variability alone would support a more extended leptonic model. The puzzle of the EGRET gamma rays from LS 5039 will be quickly solved with GLAST. (Abridged)Comment: 17 pages, 11 figures, ApJ, in press, June 1, 2006, corrected eq.

From Offshore Operation to Onshore Simulator: Using Visualized Ethnographic Outcomes to Work with Systems Developers

This paper focuses on the process of translating insights from a Computer Supported Cooperative Work (CSCW)-based study, conducted on a vessel at sea, into a model that can assist systems developers working with simulators, which are used by vessel operators for training purposes on land. That is, the empirical study at sea brought about rich insights into cooperation, which is important for systems developers to know about and consider in their designs. In the paper, we establish a model that primarily consists of a ‘computational artifact’. The model is designed to support researchers working with systems developers. Drawing on marine examples, we focus on the translation process and investigate how the model serves to visualize work activities; how it addresses relations between technical and computational artifacts, as well as between functions in technical systems and functionalities in cooperative systems. In turn, we link design back to fieldwork studies

Use, potential, and showstoppers of models in automotive requirements engineering

Several studies report that the use of model-centric methods in the automotive domain is widespread and offers several benefits. However, existing work indicates that few modelling frameworks explicitly include requirements engineering (RE), and that natural language descriptions are still the status quo in RE. Therefore, we aim to increase the understanding of current and potential future use of models in RE, with respect to the automotive domain. In this paper, we report our findings from a multiple-case study with two automotive companies, collecting interview data from 14 practitioners. Our results show that models are used for a variety of different purposes during RE in the automotive domain, e.g. to improve communication and to handle complexity. However, these models are often used in an unsystematic fashion and restricted to few experts. A more widespread use of models is prevented by various challenges, most of which align with existing work on model use in a general sense. Furthermore, our results indicate that there are many potential benefits associated with future use of models during RE. Interestingly, existing research does not align well with several of the proposed use cases, e.g. restricting the use of models to informal notations for communication purposes. Based on our findings, we recommend a stronger focus on informal modelling and on using models for multi-disciplinary environments. Additionally, we see the need for future work in the area of model use, i.e. information extraction from models by non-expert modellers

Strategy and Factors Affecting the Supply Chain of Manufacturing Industries in Saudi Arabia

Supply chain management is becoming very important in the agile manufacturing industries of nowadays. It is imperative to study the strategy and factors affecting the integration of supply chain management in company’s operating divisions. Forecasting and quality functions should be integrated in supply chains. It is assumed that SCM can improve the efficiency and effectiveness of company’s transformation process. Hence it is important for companies in Saudi Arabia to follow this trend and began implementing SCM to squeeze the excessive fat out of their operations. The paper will start by general introduction with an overview about supply chain management. Then, it will summarize the theoretical background for strategy. In next section method and research methodology will be discussed with analysis of results. Finally, the paper will close with a conclusion Keywords: Supply Chain Management, Strategy, Factors, Manufacturing industries, Lean and Agile Supply Chain

The General Data Protection Regulation: Requirements, Architectures, and Constraints

The General Data Protection Regulation (GDPR) in the European Union is the most famous recently enacted privacy regulation. Despite of the regulation's legal, political, and technological ramifications, relatively little research has been carried out for better understanding the GDPR's practical implications for requirements engineering and software architectures. Building on a grounded theory approach with close ties to the Finnish software industry, this paper contributes to the sealing of this gap in previous research. Three questions are asked and answered in the context of software development organizations. First, the paper elaborates nine practical constraints under which many small and medium-sized enterprises (SMEs) often operate when implementing solutions that address the new regulatory demands. Second, the paper elicits nine regulatory requirements from the GDPR for software architectures. Third, the paper presents an implementation for a software architecture that complies both with the requirements elicited and the constraints elaborated.Comment: Forthcoming in the 27th IEEE International Requirements Engineering Conference (RE'19), Jeju Island, IEE

Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort