Compare and Contrast Software Analysis Techniques - Essay Example

? Full Paper Introduction There was a story that tells us of a computer that generated a bill of $0.00 for a he laughed at the bill and threw it away. Likewise, a month later, the same replica of the bill arrived with a small amendment of ‘bill for thirty days’. Similarly, the third bill followed with the fourth that stated ‘a legal action will be taken if the bill of $0.00’ were not paid ASAP. Adding up more to the story, the fifth bill came up with all the harsh statements of paying off the bill at once. With that story, the credit rating of that the organization was in the hand of that wrongly programmed computer that was doing wrong calculations. After the detection of that fault in the fifth month, a software programmer was contacted and briefed with the entire story. Even a small miscalculation can lead to a bad reputation and penalties from regulatory authorities that may lead to business loss. Similarly, a software malfunction was detected in November 1979, where the strategic air commander receives an alert scramble. The scramble alarm indicated that the Worldwide military Command and Control System (WWMCCS) reported that the Soviet Union has launched missiles that are moving towards the United States of America (Software engineering (sie) 7E). Likewise, later it was found that the simulated attack was considered as a real attack, however, the U.S department of defense has not provided the details of that incident as it was marked as confidential. Conclusively, it was also a software fault that may have intimated U.S to launch a counter attack. With these two examples of billing a customer or getting false alarms in air defense, the completion time of software is always late, over budgeted or with many faults and may not cope with clients requirements. To overcome, these issues, software engineering methods are invented. Likewise, it is an attempt to provide a solution of these problems. In this brief, we will discuss two software engineering techniques i.e. formal software engineering and semi-formal software engineering. 2 Formal Software Engineering Techniques There are various formal software engineering techniques available; however, they are exceedingly diverse. For instance, Anna is considered to be a formal specification language pertaining to Ada (Luckham, von Henke, Krieg-Brueckner, & Owe, 1987). Likewise, some of the formal techniques are based on knowledge such as Gist, as it was designed for describing processes aligned with user friendliness i.e. the closest alignment of describing the process. Likewise, this is only achievable by formulating the constructs that are utilized in natural languages. The Gist specifications are very difficult to read in practice, a separate paraphrasing tool has been deployed from Gist to English. Moreover, one more formal software engineering technique known as (Schach, 1993) Vienna definition method (VDM) is also invented. Likewise, this technique is based on DE notational semantics (Fitzgerald & Larsen, 2009). Moreover, one remarkable factor of this technique encompasses not only on the application but the design and deployment, as well. The VDM technique has been successfully applied in many projects, most amazingly on the ‘Datamatik Center development’ that was integrated with DDC AdaCompiler System (Diaz & Orejas, 1989). A unique perspective of reviewing specifications is to analyze them in the context of sequences of events. Likewise, an event can be an ordinary action or a communication signal that transmits data inward or outward of the system. For instance, a case study related to an elevator, where one event comprises of pressing the button of the elevator for floor f on elevator e along with its consequential illumination. Similarly, another event comprises of elevator e that is leaving the floor f downwards along with cancellation of illumination that is associated with conforming floor button. The CSP language abbreviated as the Communication Sequential Processes (CSP) is invented by Hoare in 1985 and it is also categorized as formal software engineering technique (Welch, Roebbers, Broenink, Barnes, & Ritson, 2009). Likewise, the language is constructed on an idea that describes the system behavior related to such events. Likewise, the process in CSP is defined in sequences of events occurred, and the process involves itself with the environment. The communication of processes between each other is operational by sending messages. The CSP authorizes the processes to integrate in various ways. For example, they can integrate in a parallel way or sequentially way, and they can be interleaved with each other. Likewise, the core strength for CSP is its ability to provide execution for CSP specifications as they can be reviewed for internal reliability (Abdallah, Jones, & Sanders, 2005). Furthermore, CSP also delivers a framework that guides the way from specification to design and deployment in the form of sequential steps that show internal consistency. 3 Semi-Formal Software Engineering Techniques The technique of ‘Gane’ and ‘Sarsen’ is formal instead of writing requirement specification documentation in terms of natural language. However, at the same period, it is considered to be reduced in terms of formality when compared to Dart and related coworkers. The coworkers categorize design and analysis methods in terms of formal, semi-formal and informal (Laplante, 2004). Moreover, structured system analysis technique is widely adopted, and there is a high probability that one can be employed in an organization that has implemented structured system analysis technique. Although, there are various semi-formal software engineering techniques, for instance, the proceedings of software specification and software design pertaining to international workshops. We will discuss a comprehensive description of widely adopted semi-formal software engineering techniques. One of the semi-formal software engineering techniques is PSL/PSA (Software engg concepts2001) that is based on computer aid. Likewise, it facilitates the specification of products based on information processing. As the name is divided in to two separate parts, it is derived from two different components i.e. the Problem Statement language (PSL) that is used for describing Problem State Analyzer (PSA) along with the products as it incorporates itself in the PSL description in line with the database and generates a report on request. Today, PSL/PSA is still operational, and it is specifically used for product documentation. Adding one more to a semi-formal software engineering technique, SADT (Software engineering (sie) 7E) comprises of two components that are interrelated to each other i.e. diagramming language consisting of a box and an arrow called as structure analysis (SA) and for designing purpose, design technique is used (DT). Likewise, SADT encompasses refinement step by step that is equivalent to an excessive degree comparatively with Gane and Sarsen’s technique that is a mindful for addressing Miller’s Law. As Ross says “Everything worth saying, about anything worth saying something about, must be expressed in six or fewer pieces.” (Software engineering (sie) 7E). SADT is able to portray a wide variety of successful products, specifically difficult and projects on a large scale. Likewise, similar to much other semi-formal software engineering technique, the implementation or appropriateness to the system working in real state is not 100% clear. In contrast, SREM (the software requirements engineering method) that is pronounced as ‘shrem’ is also categorized as one of the semi-formal software engineering technique that is designed to aim explicitly for certain conditions requiring certain actions need to happen (Birrell & Ould, 1988). Due to its characteristics and functionality, SREM principally facilitates for stipulating real-time systems that are expanded to a distributed system environment. There are a number of components in SREM i.e. for specification language RSL is used, and a set of tools called as REVS is utilized for performing tasks related to specifications such as translation of RSL based specification in to an automatic database, checking the consistency of data flow automatically (for verifying that before assigning a value to it, data has not been utilized), producing simulants that are derived from the specifications that can be utilized for ensuring that these specifications are valid. Moreover, for designing SREM utilizes a design technique called as DCDS (distributed computing design system). The strength of SREM is derived from the fundamental model possessing the technique i.e. a machine in finite state. Consequently, derived from the fundamental model possessing the technique, it is likely to verify and review the consistency along with verifying the performance limitations for a product can be met completely. Furthermore, SREM can also be utilized by the U.S Air Force for specifying two C31 software i.e. (command, control, communications, and intelligence) systems [Scheffer,Stone, and Rzepka, 1985]. In addition, SREM has proved to be efficient in the stage called as classical analysis, it was observed that the REVS tools that were deployed in the later stages of the Software Development Cycle were not too much handful. 4 Conclusion The brief started with some real life examples associated with error in software that may lead to disastrous situations leading to a war and business reputation loss. Even a tiniest of mistakes or wrong calculation coming out from a software program designed to calculate deep sea level in a submarine may become a threat to all human lives on the ship. As we have already discussed the advantages of software engineering techniques, we have divided the paper into two sections i.e. Formal Software Engineering Techniques and Semi-Formal Software Engineering Techniques with many examples. In formal techniques, we discussed Gist as its specifications are very difficult to read in practice and a separate paraphrase tool has been deployed from Gist to English. Secondly, Vienna definition method (VDM) is also discussed as this technique is based on DE notational semantics. Moreover, the VDM technique is also discussed as it has been successfully applied in many projects, most amazingly on the Datamatik Center development that was integrated with DDC AdaCompiler System. Furthermore, the CSP language abbreviated as the Communication Sequential Processes (CSP) is also discussed in detail In semi-formal techniques, we discussed PSL/PSA based on computer aid the Problem Statement language (PSL). We also discussed in detail, SADT structure analysis (SA) and for designing purpose, design technique is used (DT). Moreover, some light has been thrown on structured system analysis technique. Furthermore, in the end, SREM (the software requirements engineering method) was also discussed in details. References Abdallah, A. E., Jones, C. B., & Sanders, J. W. (2005). Communicating sequential processes. the first 25 years: Symposium on the occasion of 25 years of CSP, london, UK, july 7-8, 2004. revised invited papers Springer. Birrell, N. D., & Ould, A. (1988). A practical handbook for software development Cambridge University Press. Diaz, J., & Orejas, F. (1989). TAPSOFT '89. proceedings of the international joint conference on theory and practice of software development barcelona, spain, march 13-17, 1989: Volume 2: Advanced seminar on foundations of innovative software development II and colloquium on current issues in programming languages (CCIPL) Springer. Fitzgerald, J., & Larsen, P. G. (2009). Modelling systems: Practical tools and techniques in software development Cambridge University Press. Laplante, P. A. (2004). Real-time systems design and analysis Wiley. Luckham, D. C., von Henke, F. W., Krieg-Brueckner, B., & Owe, O. (1987). ANNA A language for annotating ada programs: Reference manual Springer. Software engg concepts (2001). McGraw-Hill Education (India) Pvt Limited. Software engineering (sie) 7E McGraw-Hill Education (India) Pvt Limited. Schach, S. R. (1993). Software engineering Aksen Associates. Welch, P. H., Roebbers, H. W., Broenink, J. F., Barnes, F. R. M., & Ritson, C. G. (2009). Communicating process architectures 2009: WoTUG-32 IOS Press Read More