The 12th edition of Software Reliability, organized by the Committee on Reliability for the Spanish Association for Quality (AEC) will be held on 24, 25 and November 26, 2010 in Cadiz. GTD will attend as a speaker and will present a paper named: "The analysis process integration RAMS (Reliability, Availability, maintainability & Safety) in an Integrated Management System." What is RAMS? RAMS is the abbreviation for Reliability, Availability, Maintainability and Safety. RAMS Analyses are a set of techniques by which demonstrates conformity of RAMS requirements. As you know, many of the GTD projects must meet customer requirements RAMS. Why the client imposes these requirements? Then there are mainly two reasons: Legal requirements / regulations (the client demands it because it is a restriction on the product.) For example, "The failure of a system component may not yield a mortal danger to an operator." By the will of its own (the customer requires it, 'naive of him', believes the RAMS analysis will add value to the product). For example, a requirement such as "keeping operations should be able to make the system operational." How Gtd shows that their products meet these requirements? The traditional approach of RAMS analysis is to verify the compliance of these requirements to post the completion of product design, before entering the Review. The risks to this approach are obvious since the demonstration of compliance of these requirements is too late. This raises several issues. Knowing that the time required for a RAMS analysis is by no means negligible, there will be a lower limit for completion of the design. Experience tells us that the industry demands ever more tight deadlines, and design teams have almost no margin for their work, so the design phase extends over budget and analysis have less time RAMS initially anticipated, resulting in a shorter range and lower total confidence in their results. Conclusion: Late, bad and drag. If the analysis demonstrates that the design does not comply, will require a new iteration in the cycle changes to the design / analysis RAMS. Conclusion: More delay and more cost. Other approaches are also possible. For example, in many industries where culture has not been established RAMS practice is that after the design to be launched at the same time building and RAMS analysis. Then pray that the results of these are favorable when they arrive several months later. Proponents argue that the positive cases (the faith has worked and tests show that the design conforms), planning is reduced to parallelize tasks. What I failed to mention that in the case (the analysis shows that design is not compliant), costs (€ and time) associated with the modification of a system under construction are much larger than the changes in phase design. Here again make an appearance faith, and then there are those who are entrusted with San Deroguer, patron of lost causes. Of course this protocol is unacceptable in aeronautics and space industry. What does the new process of GTD RAMS? The GTD approach we wanted all along was to be useful not only to demonstrate that the product complies with a lower risk for the project (early detection of problems), but also to provide added value differentiator. Since the know before how good is a design, more time to do a better design. A feature of RAMS analysis is that they are worth the license, "highly non-linear." This means that the numerical results vary widely depending on small changes in any of the input variables. For example, a change in value of a MTBF of a component is having to update all calculations of reliability, fault trees and associated spare tables, so the cost in hours of small modifications is almost as high as of a complete analysis. For this very reason, rather than wait to have a completed design for a validation of the RAMS aspects, we propose a parallel task RAMS analysis integrated into the design process itself, taking as inputs the layers of the designs that are stable and frozen, and thereafter work on deltas (changes) between the different versions of design work. This is so easy to write, is that it is not easy to implement. The paper reflects the problems that traditionally we have found (configuration management working versions and identification, information, traceability and impact on RAMS analysis of the design changes). The critical part of the definition of the process has been to define the necessary information and the flow of the same order to make a parallelization of activities, enabling the development team to work in a conventional manner, and the RAMS team working in a incremental and iterative. In this way we have defined the process works incrementally, using as inputs "safe" higher-level layers (specifications) and providing more depth in the analysis as they are consolidating the lower layers (architecture and detailed design) coming to embed its own test within the framework of project test plans. Formally, it is within the framework of the Integrated Management of GTD which provides this type of work, defining the associated procedures (as well as tools and templates) and its interaction with other processes, taking into account the fact that the RAMS analysis constitute a addendum in the new development process. We hope that the fruits of this work of definition is starting to pick up soon and that the methodology of RAMS analysis of Gtd this specified and implemented later this year. All this and more from 24 to 26 November in Cadiz.
