LOGO

Summary, Critical Analysis, Proposed Methodology

An efficient method for developing requirement specifications for plant control software using a component-based software prototype

Summary
Presenter FARYAL GOHAR

Critical Analysis
Presenter SAADIA HAFEEZ

According to Brooke The hardest single part of building a software system is deciding precisely what to build.

Critical Analysis
Critical analysis of research studies is one of the most important steps towards incorporation of evidence into practice. The research paper is written by Masakazu et.al as a journal publication in Science direct International Journal of Scholars.

Intended Audience
The authors have addressed the audience of Plant Control Systems, where requirement specification is a major issue. This research is conducted as a part of Basic Technology for Next Generation Transportation System Design, which is a delegation from the New Energy and Industrial Technology Development Organization (NEDO).

Intended Purpose
The purpose of this research study is to explore the problems in conventional methods used to specify the requirements of an embedded system specifically plant control system. This paper proposed an efficient method to develop requirement specifications for Plant Control Software using software component based prototypes

The Research Rationale

There is no fault in the logic of the theoretical rationale for the research, since the more efficiently requirements are gathered and specified there are fewer chances of disputes and development issues. The success of the system lies in clear, unambiguous requirements.

Analysis Objective Reasoning

The authors specified component based prototype for requirement specification that is an effective way of gathering and specifying the requirements without disputes and confusions. These component based prototypes made for the purpose of requirement specification can be transformed into design and development phases of software development as well as during the testing phase since the system is crossed checked against the requirements. The information in the research paper appeared to be valid and well-researched and is supported by evidence. The results of proposed method are applied to five development cases of plant control software. The authors point of view is objective not impartial. The language is free of emotion-arousing words and biasness.

Research Methodology

The authors explanation of why solutions provided by the prior research are inadequate? is provided in detail. According to authors view the conventional requirement review meeting does not fully clarify the clients requirements for the PCSW. Since the clients are not PCSW experts, an operational example of the PCSW is required to simulate the actual behavior of the PCSW. This is why the prototyping method is effective for developing well-defined requirement specifications. However, developing prototypes places a burden on the development team; therefore an efficient method for developing prototypes is desired.

Critique
Every research method has its advantages and disadvantages. The researchers choose the most appropriate research method for the particular research question that they are investigating but they didnt deal with the disadvantages of that method because of which if the research method fails at any stage that failure will be sudden and the results will get affected.

Data collection and analysis

The data was collected by researchers themselves, with listed related publications, showing they have research experience in the field.

Quantitative
Data analysis is clearly described, including measures taken to validate data entry. Data was assumed to be at ordinal level, but justification was given for this. However, assuming this, the appropriate paired nonparametric test was used.

Qualitative
The researchers dont provide reflexive comment about their roles in the research, though the approach to data preparation and analysis is clear. The researcher followed a recognized published approach to data reduction, display and verification, which on a positive note included independent researcher and respondent verification, thus improving trust worthiness of the data.

Findings
The researchers determined that the business management solution systems have the same analogy as the PCSW systems, and the following conclusions can be surmised: The software in the target domain has the same functional architecture in every target domain. The functional architecture software can be classified into similar and individual functions. In the target domain, the rate of similar functions is of a high percentage, and the rate of individual function is of a low percentage. Requirement specification in the target domain can be developed by combining the same, similar and individual functions, if required

Conclusion
The results derived from data analysis are clearly stated and explained with reference to the research question and hypothesis. The findings are stated and the authors have related their findings with the research purpose and its underlying assumptions have discussed that the findings can be generalized. The authors have also recommended that further research needs to be done for the goal to achieve efficient development of more adequate requirement specifications. In addition, the proposed method will be applied to new domains, and the results will be evaluated collaterally. In this way, the generality of the proposed method will be confirmed. However, the authors also appreciate that it is not easy to introduce such big structural changes.

Relation with other Research papers

The introduction of software based instrumentation and plant control systems has raised many issues of safety and economics. Matthew S. Jatte et.al is focused on applicationindependent criteria which can be evaluated by looking at the software requirement specification alone comparatively much better than the research approach followed by the authors that is application dependent. Rajeev Alur et.al also utilized the interim research idea of the authors and designed a prototype implementation for scheduling of control systems.

 Fenton N et.al have used the appropriate methods for automation requirements in plant control system. T. Bultan have used Action Language for model checking Methew S.Jafee et.al provided details for fortification and safety. Research studies embedded software must provide ample information tracy et.al provided supporting tables for fault prediction in software engineering study

Strengths and limitations of Research paper

Strengths
The abstract accurately described the objectives and results obtained and the aims of the study were clearly described, the abstract included material that can be substantiated. The research design provided a satisfactory test of the research hypotheses. Measures of the independent and dependent variables been shown to be a reliable in the present research and in previous research (e.g., test-retest reliability, internal reliability)?

 All conclusions were supported by the studys findings. The authors discussed their results in relation to available information. The results obtained were statistically significant. The authors adequately interpreted their data. The authors discussed data presented with reference to unpublished work. The authors indicated the reasons why particular procedures were used.

 The experiments were done appropriately with respect to objectives of the study. There is no fault in the logic of the theoretical rationale for the research The legends to the figures describe clearly the data obtained. The authors have cited appropriate papers for comments made.

Weaknesses
The researchers choose the most appropriate research method for the particular research question that they were investigating. Inappropriate statistical analysis been performed on the data. The researchers did not justify any exclusion appropriately. The researchers did not choose an appropriate method to deal with missing data. The authors did not discuss the limitations of the methods used.

 If methods were modified, the modifications were not described carefully. The authors have not indicated clearly the potential problems with the methods used. Inadequate details provided by authors regarding the implementation of Proposed method in plants Researchers mostly focused on functional requirements and didnt propose method for gathering non-functional requirements for embedded systems. Authors did not mention the time frame required for implementing this methodology

 No proper methods were listed by the authors for verification and model checking of embedded control systems. Automation requirements as well as maintainability requirements are missed in this research paper. Authors have not provided the details regarding the maintainability and automation.

Critical Analysis at a glance with the help of research questions

Methodology Criticism & Proposed Solution

Presenter KASHIF ULLAH KHAN

 Prototyping is an expensive activity Prototyping is an time intensive activity Prototyping may cause schedule over slip Developers does not favor too much user involvement Too many changes may disturb the Dev Team.

 Client may assume that product will be developed quickly Prototype may cause Absence of View between client and prototype Developer may make implementation compromises. Prototype is not converted in end product, waste of effort Client may measure/map the effort required for product by prototype.

 Prototype is a low quality code that may cause higher customer expectations. Prototype is only for functional requirements , Client have no idea about quality attributes of the end product. Performance may degrade from prototype to end product. Developer may try to convert prototype into actual product.

What to use if not prototype ?

 I would suggest use Rapid Application Development. RAD is similar like prototyping but as its name sounds, its rapid. RAD focuses on building applications in a very short amount of time(Weeks/Months). Client is involved with the development team.

 Critical features go first. Non-Critical are achieved in later releases. Client collaboration make Dev team synchronize with the needs.