Proper software engineering process in developing an integrated telehealth system

Software development project becomes difficult because of the complexity in the business requirements, rigid framework and unpredictable performance. These cause difficulties to deliver the software on time, to maintain it and to adapt to new requirements. These scenarios had been faced in developing the healthcare information system which typically complex and comprehensive. Due to its complexities, the development of healthcare information system and other related healthcare applications typically disparate and less integrated. This led to maintenance and system integration issues that recently struggling by most healthcare providers around the world to resolve it by putting effort to link all existing disparate system into integrated one. This was due to the fact that a proper software engineering process was given less attention at the beginning of the health ICT project. This paper proposed, a systematic software engineering process based on customized Rational Unified Process for managing the development of integrated telehealth system. This paper also proposed literate modeling approach for performing system analysis and design model for users‟ accessibility and comprehensibility

Applying System Families Concepts to Requirements Engineering Process Definition

In this paper, some experiences gained during the definition of a unified, common software development process for several companies in Telvent are presented. Last year, Telvent made the decision of developing a unique software development process which was flexible enough to be adapted to specific practices and needs of the different companies. In this paper we focus mainly on the experiences gained during the definition of the requirements engineering process, al-though many of them are also applicable to other software development processes. One of the most interesting experiences from our point of view is that, al-though the definition process was started using a top-down approach and well-know techniques like data flow diagrams, we eventually end up applying requirements engineering techniques like glossaries, scenarios or conflict resolu-tion for the definition of the requirements engineering process itself. On the other hand, the need of having adaptable processes for the different companies in Tel-vent made us adopt a process family approach, i.e. adopting an approach similar to the system families development, thus defining a core process that could be adapted to specific needs of specific companies in a predefined, controlled man-ner. The experiences gained in the definition of the process family were applied to the definition of requirements engineering process for product line development, which is briefly presented in this paper.Comisión Interministerial de Ciencia y Tecnología TIC 2000–1106–C02–01Ministerio de Energía, Turismo y Agenda Digital ITEA ip00004Ministerio de Economía y Competitividad Eureka Σ! 202

Using Web services choreography to support an extensible and flexible system development process

Systems Engineering (SE) controls a complex environment consisting of various collaborative subsystems. Each subsystem demands different kind of requirements and follows a specific strategy for its development process. Unifying and harmonizing the development process of all collaborative subsystems towards achieving the ultimate integrated system is one of the main challenges of SE. This work introduces a new approach towards having a generic SE unified process applicable to various environments. We suggest a service-oriented framework for SE process implemented using Web Services, and describe the process scenario in a machine-friendly abstract layer over the Development Process. This description layer choreographs collaborative subsystems and is implemented by a Web Services Choreography Description Language (WSCDL). It also covers Interface Management concerns of SE. In such an environment, as long as all services follow a unique framework for the SE process such as the one specified by the International Council on Systems Engineering (INCOSE), each phase of the process would then be an anonymous service implemented by a different vendor. As the result, an organization could easily customize its own specific development environment by editing this choreography layer according to its specific development policies, and then tailor its own desired development environment by choosing and integrating various services available on the Web. Source: Masters Abstracts International, Volume: 45-01, page: 0351. Thesis (M.Sc.)--University of Windsor (Canada), 2006

Development of a human factors hazard model for use in system safety analysis

2021 Fall.Includes bibliographical references.Traditional methods for Human Reliability Analysis (HRA) have been developed with specific applications or industries in mind. Additionally, these methods are often complicated, time consuming, costly to apply, and are not suitable for direct comparison amongst themselves. The proposed Human Factors Hazard Model (HFHM) utilizes the established and time-tested probabilistic analysis tools of Fault Tree Analysis (FTA) and Event Tree Analysis (ETA), and integrates them with a newly developed Human Error Probability (HEP) predictive tool. This new approach is developed around Performance Shaping Factors (PSFs) relevant to human behavior, as well as specific characteristics unique to a system architecture and its corresponding operational behavior. This updated approach is intended to standardize, simplify, and automate the approach to modeling the likelihood of a mishap due to a human-system interaction during a hazard event. The HFHM is exemplified and automated within a commercial software tool such that trade and sensitivity studies can be conducted and validated easily. The analysis results generated by the HFHM can be used as a standardized guide to SE analysts as a well as design engineers with regards to risk assessment, safety requirements, design options, and needed safety controls within the system architecture. Verification and evaluation of the HFHM indicate that it is an effective tool for HRA and system safety with results that accurately predict HEP values that can guide design efforts with respect to human factors. In addition to the development and automation of the HFHM, application within commonly used system safety Hazard Analysis Techniques (HATs) is established. Specific utilization of the HFHM within system or subsystem level FTA and Failure Mode and Effects Analysis (FMEA) is established such that human related hazards can more accurately be accounted for in system design safety analysis and lifecycle management. Lastly, integration of the HFHM within Model-Based System Engineering (MBSE) emphasizing an implementation into the System Modeling Language (SysML) is established using a combination of existing hazard analysis libraries and custom designed libraries within the Unified Modeling Language (UML). The FTA / ETA components of the hazard model are developed within SysML partially utilizing the RAAML (Risk Analysis and Assessment Modeling Language) currently under development by the Object Management Group (OMG), as well as a unique recursive analysis library. The SysML model successfully replicates the probabilistic calculation results of the HFHM as generated by the native analytical model. The SysML profiles developed to implement HFHM have application in integration of conventional system safety analysis as well as requirements engineering within lifecycle management

Goal-Function Tree Modeling for Systems Engineering and Fault Management

The draft NASA Fault Management (FM) Handbook (2012) states that Fault Management (FM) is a "part of systems engineering", and that it "demands a system-level perspective" (NASAHDBK- 1002, 7). What, exactly, is the relationship between systems engineering and FM? To NASA, systems engineering (SE) is "the art and science of developing an operable system capable of meeting requirements within often opposed constraints" (NASA/SP-2007-6105, 3). Systems engineering starts with the elucidation and development of requirements, which set the goals that the system is to achieve. To achieve these goals, the systems engineer typically defines functions, and the functions in turn are the basis for design trades to determine the best means to perform the functions. System Health Management (SHM), by contrast, defines "the capabilities of a system that preserve the system's ability to function as intended" (Johnson et al., 2011, 3). Fault Management, in turn, is the operational subset of SHM, which detects current or future failures, and takes operational measures to prevent or respond to these failures. Failure, in turn, is the "unacceptable performance of intended function." (Johnson 2011, 605) Thus the relationship of SE to FM is that SE defines the functions and the design to perform those functions to meet system goals and requirements, while FM detects the inability to perform those functions and takes action. SHM and FM are in essence "the dark side" of SE. For every function to be performed (SE), there is the possibility that it is not successfully performed (SHM); FM defines the means to operationally detect and respond to this lack of success. We can also describe this in terms of goals: for every goal to be achieved, there is the possibility that it is not achieved; FM defines the means to operationally detect and respond to this inability to achieve the goal. This brief description of relationships between SE, SHM, and FM provide hints to a modeling approach to provide formal connectivity between the nominal (SE), and off-nominal (SHM and FM) aspects of functions and designs. This paper describes a formal modeling approach to the initial phases of the development process that integrates the nominal and off-nominal perspectives in a model that unites SE goals and functions of with the failure to achieve goals and functions (SHM/FM). This methodology and corresponding model, known as a Goal-Function Tree (GFT), provides a means to represent, decompose, and elaborate system goals and functions in a rigorous manner that connects directly to design through use of state variables that translate natural language requirements and goals into logical-physical state language. The state variable-based approach also provides the means to directly connect FM to the design, by specifying the range in which state variables must be controlled to achieve goals, and conversely, the failures that exist if system behavior go out-of-range. This in turn allows for the systems engineers and SHM/FM engineers to determine which state variables to monitor, and what action(s) to take should the system fail to achieve that goal. In sum, the GFT representation provides a unified approach to early-phase SE and FM development. This representation and methodology has been successfully developed and implemented using Systems Modeling Language (SysML) on the NASA Space Launch System (SLS) Program. It enabled early design trade studies of failure detection coverage to ensure complete detection coverage of all crew-threatening failures. The representation maps directly both to FM algorithm designs, and to failure scenario definitions needed for design analysis and testing. The GFT representation provided the basis for mapping of abort triggers into scenarios, both needed for initial, and successful quantitative analyses of abort effectiveness (detection and response to crew-threatening events)

Designing a consulting services architecture model

textDuring my years of experience in the technology industry, it has become obvious that standard processes and methodologies within the engineering discipline are at a mature state. The realization though is that software engineering specifically lags behind. Most software engineering methodologies that I have studied focus on the mission of software development. It is this realization and the need for structure that led me to review existing methodologies used within my company's software services organization. The definition of what a successful software services methodology entails is rather limited. This report will provide a history of existing software engineering methodologies that I have studied, describe an initial services method that was being developed within my organization, develop a new model that addresses previous shortcomings and identify additional components required to further define a strong software services-oriented delivery methodology.Electrical and Computer Engineerin