FREE ELECTRONIC LIBRARY - Dissertations, online materials

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 27 |

«Software Fault Reporting Processes in Business-Critical Systems Jon Arvid Børretzen Doctoral Thesis Submitted for the partial fulfilment of the ...»

-- [ Page 13 ] --

That a system is business-safe does not mean that the system is error free. What it means is that the system will have a low probability of causing losses for the users. In this respect, the system characteristic is close to the term “safe”. This term is, however, wider, since it is concerned with all activities that can cause damage to people, equipment or the environment or severe economic losses. Just as with general safety, business-safety is not a characteristic of the system alone – it is a characteristic of the system’s interactions with its environment.

BUCS is considering two groups of stakeholders and wants to help them both.

• The customers and their users. They need methods that enables them to:

o Understand the dangers that can occur when they start to use the system as part of their business.

o Write or state requirements to the developers so that they can take care of the risks incurred when operating the system – product risk.

• The developers. They need help to implement the system so that:

o It is business-safe.

o They can create confidence by supporting their claims with analysis and documentation.

o It is possible to change the systems so that when the environment changes, the systems are still business-safe.

This will not make it cheaper to develop the system. It will, however, help the developers to build a business-safe system without large increases in the development costs.

Why should developing companies do something that costs extra – is this a smart business proposition? We definitively mean that the answer is “Yes”, and for the

following reasons:

• The only solution most companies have to offer to customers with business-safety concerns today is that the developers will be more careful and test more – which is not a good enough solution.

• By building a business-safe system the developers will help the customer achieve efficient operation of their business and thus build an image of a company that have their customers’ interest in focus. Applying new methods to increase the products’ business-safety must thus be viewed as an investment. The return on the investment will come as more business from large, important customers.

2. The Rational Unified Process

The Rational Unified Process (RUP) is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.

RUP is developed and supported by Rational Software [Rational]. The framework is based on popular development methods used by leading actors in the software industry.

RUP consists of four phases; inception, elaboration, construction and transition. The BUCS project has identified the three first phases as most relevant to our work, and will make proposals for introduction of safety methods for these phases. In this paper, we will concentrate on the inception phase.

Figure 1 - Rational Unified Process; © IBM [Rational]

Figure 1 shows the overall architecture of the RUP, and its two dimensions:

• The horizontal axis which represents time and shows the lifecycle aspects of the process as it unfolds

• The vertical axis which represents disciplines and group activities to be performed in each phase.

The first dimension represents the dynamic aspect of the process as it is enacted, and is expressed in terms of phases, iterations, and milestones. The second dimension represents the static aspect of the process: how it is described in terms of process components, disciplines, activities, workflows, artefacts, and roles [Kroll03] [Krutchen00]. The graph shows how the emphasis varies over time. For example, in early iterations, we spend more time on requirements, and in later iterations we spend more time on implementation.

The ideas presented in this paper are valid even if the RUP process is not used. An iterative software development process will in most cases be quite similar to a RUP process in broad terms, with phases and where certain events, artefacts and actions exist.

Some companies also use other process frameworks that in principle differ from RUP mostly in name. Therefore, it is possible and beneficial to include and integrate the safety methods we propose into any iterative development process.

2.1 Inception

Early in a software development project, system requirements will always be on top of the agenda. In the same way as well thought-out plans are important for a system in general, well thought-out plans for system safety are important when trying to build a correctly functioning, safe system. Our goal is to introduce methods that are helpful for producing a safety requirements specification, which can largely be seen as one type of non-functional requirements. However, safety requirements also force us to include the system’s environment. In RUP, with its use-case driven approach, this process can be seen as analogous to the process of defining general non-functional requirements, since use-case driven processes are not well suited for non-functional requirements specification. Because the RUP process itself does not explicitly command safety requirements in the same way it does not command non-functional requirements, other methods have to be introduced for this purpose. On the other hand, the architecturecentric approach in RUP is helpful for producing non-functional requirements, as these requirements are strongly linked to a system’s architecture. Considerations about system architecture will therefore influence non-functional and safety requirements.

Although designing safety into the system from the beginning (upstream protection) may incur some design trade-offs, eliminating or controlling hazards may result in lower costs during both development and overall system lifetime, due to fewer delays and less need for redesign [Leveson95]. Working in the opposite direction, adding protection features to a completed design (downstream protection) may cut costs early in the design process, but will increase system costs, delays and risk to a much greater extent than the costs owing to early safety design.

The main goal of the inception phase is to achieve a common understanding among the stakeholders on the lifecycle objectives for the development project [Krutchen00]. You should decide exactly what to build, and from a financial perspective, whether you should start building it at all. Key functionality should be identified early. The inception phase is important, primarily for new development efforts, in which there are significant project risks which must be addressed before the project can proceed. The primary

objectives of the inception phase include (from [Kroll03] [Krutchen00]):

• Establishing the project's software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be included in the product and what is not.

• Identifying the critical use cases of the system, the primary scenarios of operation that will drive the major design trade-offs. This also includes deciding which use cases that are the most critical ones.

• Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios.

• Estimating the overall cost and schedule for the entire project (and more detailed estimates for the elaboration phase that will immediately follow).

• Assessing risks and the sources of unpredictability.

• Preparing the supporting environment for the project.

3. Safety methods introduced by BUCS

Early in a project’s life-cycle, many decisions have not yet been made, and we have to deal with a conceptual view or even just ideas for the forthcoming system. Therefore, much of the information we have to base our safety-related work on is at a conceptual level. The methods we can use will therefore be those that can use this kind of highlevel information, and the ones that are suited to the early phases of software development projects.

We have identified five safety methods that are suitable for the inception phase of a development project. Two of them, Safety Case and Intent Specification, are methods that are well suited for use throughout the development project [Adelard98] [Leveson00], as they focus on storing and combining information relevant to safety through the product’s life-cycle. The other three, Preliminary Hazard Analysis, Hazards and Operability Analysis and Event Tree Analysis are focused methods [Rausand91] [Leveson95], well suited for use in the inception phase, as they can be used on a project where many details are yet to be defined. In this paper, the Safety Case, Preliminary Hazard Analysis and Hazard and Operability Analysis methods are used as examples of how such methods can be used in a RUP context.

When introducing safety related development methods into an environment where the aim is to build a business-safe system, but not necessarily error-free and completely safe, we have to accept that usage of these methods will not be as stringent and effort demanding as in a safety-critical system. This entails that the safety methods used in business-critical system development will be adapted and simplified versions, in order to save time and resources.

3.1 Safety Case

A safety case is a documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment [Adelard98] [Bishop98]. The safety case method is a tool for managing safety claims, containing a reasoned argument that a system is or will be safe. It is manifested as a collection of data, metadata and logical arguments. The main elements of a safety case

are shown in Figure 2:

• Claims about a property of the system or a subsystem (Usually about safety requirements for the system)

• Evidence which is used as basis for the safety argument (Facts, assumptions, subclaims)

• Arguments linking the evidence to the claim

• Inference rules for the argument

–  –  –

The arguments can be:

• Deterministic: Application of predetermined rules to derive a true/false claim, or demonstration of a safety requirement.

• Probabilistic: Quantitative statistical reasoning, to establish a numerical level.

• Qualitative: Compliance with rules that have an indirect link to the desired attributes.

The safety case method can be used throughout a system’s life-cycle, and divides a project into four phases: Preliminary, Architectural, Implementation, and Operation and Installation. This is similar to the phases of RUP, and makes it reasonable to tie a preliminary safety case to the inception phase of a development project. The development of a safety case does not follow a simple step by step process. The main activities interact with each other and iterate as the design proceeds and as the level of detail in the system design increases. This also fits well with the RUP process.

The question the safety case documents will answer is in our case “How will we argue that this system can be trusted?” The safety case shows how safety requirements are decomposed and addressed, and will provide an appropriate answer to the question. The

characteristics of the safety case elements in the inception phase are:

1. Establish the system context, whether the safety case is for a complete system or a component within a system.

2. Establish safety requirements and attributes for the current level of the design, and how these requirements and attributes are related to the system’s safety analysis.

3. Define important operational requirements and constraints such as maintenance levels, time to repair and issues related to the operating environment.

3.2 Preliminary Hazard Analysis and Hazard and Operability Analysis

Preliminary Hazard Analysis (PHA) is used in the early life cycle stages to identify critical system functions and broad system hazards. The identified hazards are assessed and prioritized, and safety design criteria and requirements are identified. A PHA is started early in the concept exploration phase so that safety considerations are included in tradeoff studies and design alternatives. This process is iterative, with the PHA being updated as more information about the design is obtained and as changes are being made. The results serve as a baseline for later analysis and are used in developing system safety requirements and in the preparation of performance and design specifications. Since PHA starts at the concept formation stage of a project, little detail is available, and the assessments of hazard and risk levels are therefore qualitative. A PHA should be performed by a small group with good knowledge about the system specifications.

Both Preliminary Hazard Analysis and Hazard and Operability Analysis (HazOp) are performed to identify hazards and potential problems that the stakeholders see at the conceptual stage, and that could be created by the system after being put into operation.

A HazOp study is a more systematic analysis of how deviations from the design specifications in a system can arise, and whether these deviations can result in hazards.

Both analysis methods build on information that is available at an early stage of the project. This information can be used to reduce the severity or build safeguards against the effects of the identified hazards.

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 27 |

Similar works:

«Improving the use of medicines for better outcomes and reduced waste An Action Plan Report and Action Plan of the Steering Group on Improving the Use of Medicines (for better outcomes and reduced waste) October 2012 Contents Letter from the co-chairs to the Parliamentary Under-Secretary of State for Quality, Lord Howe Chapter 1 Introduction and scope Chapter 2 Targeted support for patients in primary care Chapter 3 Effective use of patients’ medicines in hospitals Chapter 4 Use of medicines...»

«WHY DOES BANK SCREENING MATTER? PRIVATE INFORMATION AND PUBLICLY TRADED SECURITIES* Edwin H. Neave Queen’s University School of Business 100 Clergy Street East Kingston, Ontario K7L 3J4 Phone: 1 613 533 2348 Fax: 1 613 533 6847 eneave@business.queensu.ca May 17, 2014 Abstract This paper develops a general equilibrium model of information processing in order to trace the effects of bank screening from original loans to securitization instruments. We show both that bank screening capabilities...»

«A. E. (George W. Russell) & Plotinus Wikipedia: George William Russell (10 April 1867 – 17 July 1935) who wrote with the pseudonym Æ (sometimes written AE or A.E.), was an Irish writer, editor, critic, poet, artistic painter and Irish nationalist. He was also a mysticism writer, and a personage of a group of devotees of theosophy in Dublin for many years. He used the pseudonym “AE”, or more properly, “Æ”. This derived from an earlier Æon signifying the lifelong quest of man,...»

«262 Int. J. Accounting and Finance, Vol. 5, No. 3, 2015 Firm value, investment and monetary policy Marcelo Bianconi* Department of Economics, Tufts University, 111 Braker Hall, Medford, MA 02155, USA Fax: (617) 627-3917 Email: marcelo.bianconi@tufts.edu *Corresponding author Joe Akira Yoshino FEA, Department of Economics, University of Sao Paulo, Sao Paulo, 05508-900, Brazil Fax: (55) (11) 30-91-60-13 Email: pyoshino@usp.br Abstract: This paper presents empirical evidence supporting the view...»

«Volume 24( 1) UNSW Law Journal PRIVACY AS A MEANS OF ENGENDERING TRUST IN CYBERSPACE COMMERCE ROGER CLARKE* I INTRODUCTION Electronic relationships are only effective, and electronic transactions are only conducted, if the requisite degree of trust exists among the parties. The focus of this article is on the role of privacy in generating trust in cyberspace, and primarily on economic relationships in cyberspace rather than those of a familial or social nature. For inter-personal communications...»

«ISSN 1471-0498 DEPARTMENT OF ECONOMICS DISCUSSION PAPER SERIES HOW HOUSING SLUMPS END Agustin S. Benetrix, Barry Eichengreen and Kevin H. O’Rourke Number 577 October 2011 Manor Road Building, Oxford OX1 3UQ How Housing Slumps End1 Agustín S. Bénétrixa, Barry Eichengreenb and Kevin H. O’Rourkec a Trinity College Dublin and IIIS b University of California, Berkeley cUniversity of Oxford and IIIS SUMMARY We construct a simple probit model of the determinants of real house price slump...»

«Feature article • 45 • De facto v/s de jure Home Ownership: Women’s Everyday Negotiations in Lusaka and Cape Town Sian Butcher and Sophie Oldfield Introduction Across the Southern African region, low-income housing policies almost exclusively prioritise an “ownership model”, which sees progress and development as intrinsically bound up in the production of individual, legally-sanctioned, supposedly secure and economically empowered, property owners (Blomley, 2004: xiv). Evident in its...»

«International Master in Business Science Administration H3 Hambúrguer Gourmet – Main Drivers for Internationalization and Faced Challenges “h3 Hambúrguer Gourmet Case Study” Olga Diana da Silva Saraiva 152111047 Advisor: Pedro Celeste Dissertation submitted in partial fulfillment of requirements for the degree of MSc in Business Administration, at Universidade Católica Portuguesa, January 2014. H3, Hambúrguer Gourmet: Main Drivers for Internationalization and Faced Challenges Abstract...»

«Finance and Economics Discussion Series Divisions of Research & Statistics and Monetary Affairs Federal Reserve Board, Washington, D.C. Gauging the Ability of the FOMC to Respond to Future Recessions David Reifschneider 2016-068 Please cite this paper as: Reifschneider, David (2016). “Gauging the Ability of the FOMC to Respond to Future Recessions,” Finance and Economics Discussion Series 2016-068. Washington: Board of Governors of the Federal Reserve System,...»

«Diversity of Cultural Expressions Impacts and Implications of the UNESCO Convention Ten Years After and Ten Years Ahead: Views from BC Program February 25, 2015 Simon Fraser University • 515W.Hasting St. • Labatt Hall • Vancouver Organized by 1 Context The UNESCO Convention on the Protection and Promotion of the Diversity of Cultural Expressions was championed by Canada and passed in 2005 with support from an exceptional majority of nations. Ten years later, how may we evaluate the impact...»

«Taxation and Corporate Financial Policy Alan J. Auerbach University of California, Berkeley and NBER February 2001 This paper has been prepared for a forthcoming volume of the Handbook of Public Economics, edited by Alan Auerbach and Martin Feldstein. I am grateful to Kevin Cole for research assistance, to the Burch Center for Tax Policy and Public Finance for research support, and to Doug Bernheim, John Graham, Jim Hines, Vesa Kanniainen, Hans-Werner Sinn and Jan Södersten for comments on an...»

«Public Disclosure Authorized WPS3856 Creating an Efficient Financial System: Challenges in a Global Economy Public Disclosure Authorized Thorsten Beck Abstract: Financial sector development fosters economic growth and reduces poverty by Public Disclosure Authorized widening and broadening access to finance and allocating society’s savings more efficiently. This paper first discusses three pillars on which sound and efficient financial systems are built: macroeconomic stability and an...»

<<  HOME   |    CONTACTS
2016 www.dissertation.xlibx.info - Dissertations, online materials

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.