Evaluation of Safety-Critical Software - Essay Example

Evaluation of Safety-Critical Software Article Summary Could we trust equipment controlled by software? This article generally talks about the reliability of safety-critical software. Traditionally, engineers used software as a component of equipment and often viewed as an art form. It has had no standard. Notwithstanding, manufacturers of a wide range of equipment have resorted to using software as the brain of the many conventional products nowadays. Thus, software could not be viewed as trivial anymore. Put it another way, safety-critical software, as it is used today, must have an analogous standard to conform to ensure safety and reliability. To that end, there were several attempts to measure the dependability of safety-critical software. Similarly, Harlan Mills and his colleagues had developed a process called “clean room” that utilized independent testing groups to act as end users of programmable devices and were said to generate reliable results than the common practice of software professionals who performed a series of carefully planned tests to measure the reliability of their owned inventions. All things considered, an exhaustive mathematical test, not only based on intuitive reasoning, must be conducted to ensure the trustworthiness of safety-critical software. Article Analysis Programmable computers are tools that provide convenience to the end users, however, devices that are controlled by safety-critical software can threaten lives of people, as well. To that end, an extreme discipline in design in the making is needed. Data and related information should be laid out in a way that it could be easily comprehended by an independent group of testers. That is to say that “clean room” as developed by Harlan Mills and company must be applied to prevent unbiased results. Human errors often occurred, especially when software professionals would try to self-assist their own works. With this in mind, why engineers had chosen software instead of hardware? In the first place, software components were less expensive than hard-wired logic. These components were massed produced. Secondly, logic, in theory, that was implemented on software could be easily changed than of the one implemented on hard-wired device. Lastly, software is more flexible than of non-computerized system. For instance, the modern computer technology could provide more information to the end users in a more convenient manner. Less space and power were needed to produce this information. With the reasons in mind, safety was traded off with availability and flexibility. Despite that apparent risk, software professionals had resorted to using software provided that careful scrutiny will be required at all times for the safety of the end users. Then again, the lack of professional standards has been a severe problem in the field of engineering. There were no sets of skills and knowledge required for software engineers. One may be called as a software engineer after coming up with a software system even he had no post secondary training. In other words, we should not consider software as safety-critical system without precise and proper documentation and mathematical notation. We should bear in mind – safety first. Article Critique Upon careful analysis with all the arguments presented in this article, I believed that the authors had presented well-thought ideas that were helpful in the evaluation of safety-critical software. Despite availability, flexibility and convenience – software engineers must conform to a standard since software engineering is relatively new. That is to say that a strict discipline must be observed in the presentation of data and analysis of the series of reliability tests with a use of mathematical procedures. Notwithstanding the fact that there is no corresponding authority in software engineering, involved parties and concerned institutions must develop an appropriate educational program so that a standard will be formulated to test the trustworthiness of safety-critical software we may become dependent. Title A Systems-Theoretic Approach to Safety in Software-Intensive Systems Articles Summary Leveson talked about more sophisticated accident models based on systems theory. It was being conveyed that the use of traditional accident models were less effective in preventing future accidents from happening. System related accidents must be viewed as a failure in interaction among components, rather than of the individual units. The Event-chain model has had limitations, in other words, it would give a vague analysis of the accidents rather than a clear understanding of the series of events that lead to the loss of Milstar satellite launched by Titan, as an example. In systems-theoretic accident model, accidents is viewed as a result of a flawed process. In other words, system components that include people in the operation, the organization structure of an institution, the physical system of a device or equipment, and the safety-critical software that made up a device could be contributing factors of a particular accident. That is to say, all these must be analyzed. For instance, the third launched of the Milstar satellite was said to be the most expensive loss in Cape Canaveral launch history that amounted to $800 million not to mention the cost of the launcher. The accident investigation board had failed to answer the crucial questions that might lead to an answer that would prevent similar accidents from happening again – instead, it was summed up as human error. Nevertheless, the accidental entry of the filter constant might not be caused by a single component of the systems alone. Hence, the system-theoretic accident model would give a structure that would determine what role each part of the component contributed to the said accident. Hence, this model would provide more information to prevent future accidents from happening. Article Analysis Indeed, Leveson presented a clear viewpoint, why the system-theoretic accident model is recommended to analyze software related problems and to prevent such problems from happening again in the future. Engineers must be aware of such model to know the underlying reasons of system malfunctions and other errors, in order to formulate a safer procedure and system to prevent similar accidents from happening. The accuracy and completeness of the model of the type of system used is crucial and since engineering approaches were mainly based on the data provided by the accident investigation team – this must be taken with a sense of urgency and great importance. Furthermore, the author discussed the two reasons why an accident investigation must be conducted. Firstly, an investigation must be conducted to assign the blame of the accident. Secondly, a scrutiny must be made in order to understand the underlying reasons why an accident happens to solve similar failures from happening. The first reason is not an engineering concept rather than a legal or moral one. Having said that, the investigation must be shifted to knowing the reasons than getting to know the cause in order to engineer a safer system. Why such events occurred? The question is not just focused on knowing “who” to blame, but the several reasons that might have contributed by all the components of the system. Article Critique The author had presented an unbiased idea of presenting a model that would help engineers to come up with a safer system that is not vulnerable to system malfunctions and errors. Unmanned equipment used in major operations would entail great losses, not just on resources, but it could cost lives, as well. I believe that we have to conduct a legal action in order to put appropriate sanction to people or party who were responsible for particular system failure. Notwithstanding, the investigation must focus on determining the underlying reasons of the said errors. As mentioned in the article, finding the person to blame is not a part a part of the field of engineering, rather than a field of law and ethics. In line with engineering, the investigation team must follow a system-theoretic accident model, or similar models that could scrutinize each component of the system that contributed to the system failures and accidents. Title Software Requirements: A Tutorial* Article Summary This article discussed about the difficulties faced in building a software system. The difficulties in terms of understanding the requirements in the building process have lots of factors. Generally, the requirements phase deals about the specification of the function of the software without a description on how doing it. In other words, it focuses on the end results rather than the detailed analysis of its building process. One of the underlying causes of the problem is essential difficulties. For example, people could not precisely draw in detail what the software is for unless a system requested is an enhanced version of an old one. Likewise, the conceptual structure of a software is hard to visualize. There is no comprehensive physical analogue that will act as a visual aide to have a better glimpse of the overall function of a new software system. What’s more, even developers and software engineers tried their best to baseline and freeze the requirements before the designing would begin, however, it was proven impractical because the customer might not know what he wanted before he had seen the actual output. The problem did not end there, the next one entailed cost and could be expensive. The failure to follow the proper requirements in building a software system is called accidental difficulties. Often times, the requirements documentation took its place after the implementation of the software system. As a result, the documentation is written as an afterthought. In other words, it is not created to guide the developers and testers in the first place. Similarly, there are many debatable approaches presented in the article because of their own weaknesses, they all have important contributions in the attempt to make the requirement analysis and specification as controlled and effective process notwithstanding. Above all, system requirements is a crucial part of the building process and developers must only employ the brightest software engineers in the making to prevent spending a large sum of money in correcting errors otherwise. Article Analysis I could not agree more on the presentation of this article. Faulk presented both problems and approaches to solve the underlying problems of building system software. Ad hoc still is being used up to date, however, the better understanding of the results of the major flaws during the building process of a system software could save a large sum of money. According to a study presented in his article, requirements failures were costly. For example, if an error occurs during the development process and if it is not noticed until the implementation of the software system – it would entail more money to correct it. Put it another way, an error that is detected and fixed during the requirements phase may cause a dollar. Having said that, a developer would spend around 100 to 200 dollars if the error was detected after the system had been implemented. The requirements phase is the hardest part in the creation of a software system. The article covers in detail both essential and accidental difficulties, both of which developers and customers had been contributing factors. Firstly, during the requirements phase, the customer cannot precisely detailed out what he really wants, as a result, whilst the developer does not exactly know in detail what his costumer wants, he would create software lacking in purpose and is not designed to be helpful. Oftentimes, the requirements are not written as to become a technical reference. In other words, it is mainly an English prose that follows the author's consciousness. Significantly, Faulk had tackled different approaches to solve the underlying difficulties present in the requirement phase. One of the approaches is Structed Analysis. This particular approach is primarily designed to address and solve accidental difficulties. We have to bear in mind that accidental difficulties entails a big sum of money if not solved. In conclusion, the presentation of both underlying causes of software engineering during the requirements phase and the several approaches that attempt to create a systematic approach in the creation process are more than enough as a tutorial to help developers come up with an effective approach that would boost the productivity of the software industry at large. Article Critique The article is precise on its very purpose – to educate developers on what to do during the difficulties of the system software creation process. I imagined the dilemma trying to figure out a vague description given by a customer. Notwithstanding the effort to over deliver an order, the lack of description may lead to building a software that may lack in purpose. Looking at the customers’ viewpoint, they must have assumed that the developers know what to do in simply describing the whole picture of a software need to perform business transactions, for example. Here comes Faulk’s presentation of the approaches. Despite the difficulties faced during the requirements phase, the developers must bear in mind to structure the entire process effectively before starting it to avoid cost directly related to fixing errors after its implementation. Title Writing High Quality Requirements Article Summary Writing a high quality requirement is hard and there is no formulaic approach to software specification. That being said, software engineers must learn to write precisely. Reading the best book published in technical writing will not help developers to write better without doing a constant practice. For instance, the presence of distinctive keyword is crucial in conveying the right message to customers. For example, the use of “shall” in the sentence signals a discrete requirement. On the one hand, Wiegers was not a fan of arbitrary rules such as the use of “and” in a sentence. Some people said that a requirement must not use “and” because it signifies two requirements in the sentence. What’s more, he believed that a developer can either write a requirement based on system’s perspective or customer’s perfective. His notion was in contrast with some people who believed that requirements should be written only to describe the system’s behavior. The author further talked about the ambiguity of system requirements. Ambiguity was said to show in two forms: Firstly, a sentence that can be interpreted more than one way. In the second place, a requirement is ambiguous in the sentence when two reviewers understood it differently. The difference between the two forms is how the intended party discovered the ambiguous meaning of a particular requirement. The latter is less obvious that the two reviewers report back and said “The requirement is fine.” In conclusion, the author suggested that one should practice. Reading is not enough in order to learn how to write a precise and high-quality software requirements. Article Analysis Wiegers had intended to write the article as easy and friendly as possible. Software engineering is one of the difficult field of studies not to mention the difficulties during the requirements phase. In light of the technicalities, one should write software requirements that are less technical in nature. Put it another way, engineering jargons are likely to be set aside in writing high-quality requirements. Reviewers and end users may not know software engineering jargons unless they will consult a book related to the subject. One should use a keyword that would signal a discrete requirement such as using the word “shall”. Likewise, the use of the active voice in writing requirements would help to convey the message clearly and precisely. As per grammar rule, active voice and passive voice are both correct, however, in terms of preciseness and clarity the former wins. The sentence structure of the passive voice is simpler and the subject is the doer of the action – hence the developer talks to the intended party directly. What’s more, the author clearly identified two common forms of ambiguity presence in software specifications. It is not new, the absence of standards in the beginning of software engineering might be a contributing factor. I have encountered several confusing requirements, as well, along with the quest to learn more how to write system requirements precisely. Likewise, adverbs, in some way, also appears to be ambiguous. For the understanding of the readers, they may sound desirable quality of the products, but in the first place, what was exactly desired what was left with the readers’ comprehension. In conclusion, all these needs practice. Article Critique I could not agree more with the presentation of the ideas, but I have something to say about the format of the article, especially in the beginning of the material. The keywords used in the article as an example to signal distinct requirement is not formatted as it should to make them easy to read. In other words, these keywords must be enclosed with quotations such as how I emphasize “shall” in the Article Analysis above. The sentences were not clear in my first reading. I am referring to the last two sentences found in the first sub-heading. Notwithstanding, the entire article had given a clear explanation on different ways to write system requirements precisely. I must agree that reading without practice may not work as intended. One should get a piece of paper and perform the exercises as often as possible. References Parnas, D.L., Schouwen, A.J., & Kwan, S. P. (1990). Evaluation of Safety-Critical Software. Communications of the ACM. Retrieved from http://www.cs.unm.edu/~cris/591/parnas1990evaluation.pdf Leveson, N.G. (n.d.) A Systems-Theoretic Approach to Safety in Software-Intensive Systems. Nancy Leveson. Retrieved from http://sunnyday.mit.edu/papers/tdsc.pdf Faulk, S.R. (2004). Software Requirements: A Tutorial. Computer Science University of Maryland. Retrieved from https://www.cs.umd.edu/class/spring2004/cmsc838p/Requirements/Faulk_Req_Tut.pdf Wiegers, K. (n.d.) Writing High Quality Requirements. Jama Software. Retrieved from http://www.jamasoftware.com/wp-content/uploads/documents/wiegers-writing-high-quality-requirements.pdf Read More