final pres.ppt

7/28/2019 Final Pres.ppt

1/39

LOGO


2/39

Summary, Critical Analysis,Proposed Methodology

An efficient method for

developing requirementspecifications for plantcontrol software using a

component-based softwareprototype


3/39

Summary

Presenter

FARYAL GOHAR


4/39


5/39

Critical Analysis

Presenter

SAADIA HAFEEZ


6/39

According to Brooke

The hardest single part of building a softwaresystem is deciding precisely what to build.


7/39

Critical Analysis

Critical analysis of research studies is one ofthe most important steps towardsincorporation of evidence into practice.

The research paper is written by Masakazuet.al as a journal publication in Sciencedirect International Journal of Scholars.


8/39

Intended Audience

The authors have addressed the audience ofPlant Control Systems, where requirementspecification is a major issue.

This research is conducted as a part ofBasic Technology for Next GenerationTransportation System Design, which is adelegation from the New Energy andIndustrial Technology DevelopmentOrganization (NEDO).


9/39

Intended Purpose

The purpose of this research study is toexplore the problems in conventionalmethods used to specify the requirements ofan embedded system specifically plantcontrol system. This paper proposed anefficient method to develop requirement

specifications for Plant Control Softwareusing software component based prototypes


10/39

The Research Rationale

There is no fault in the logic of thetheoretical rationale for the research, sincethe more efficiently requirements are

gathered and specified there are fewerchances of disputes and developmentissues. The success of the system lies inclear, unambiguous requirements.


11/39

Analysis Objective Reasoning The authors specified component based prototype for

requirement specification that is an effective way ofgathering and specifying the requirements withoutdisputes and confusions. These component basedprototypes made for the purpose of requirementspecification can be transformed into design anddevelopment phases of software development as well as

during the testing phase since the system is crossedchecked against the requirements.

The information in the research paper appeared to be validand well-researched and is supported by evidence. Theresults of proposed method are applied to fivedevelopment cases of plant control software.

The authors point of view is objective not impartial. Thelanguage is free of emotion-arousing words and biasness.


12/39

Research Methodology

The authors explanation of why solutionsprovided by the prior research are inadequate? isprovided in detail. According to authors view theconventional requirement review meeting does notfully clarify the clients requirements for the PCSW.

Since the clients are not PCSW experts, anoperational example of the PCSW is required tosimulate the actual behavior of the PCSW. This iswhy the prototyping method is effective fordeveloping well-defined requirement specifications.

However, developing prototypes places a burdenon the development team; therefore an efficientmethod for developing prototypes is desired.


13/39


14/39

Data collection and analysis

The data was collected by researchersthemselves, with listed related publications,showing they have research experience in

the field.


15/39

Quantitative

Data analysis is clearly described, includingmeasures taken to validate data entry. Datawas assumed to be at ordinal level, but

justification was given for this. However,assuming this, the appropriate paired non-parametric test was used.


16/39

Qualitative

The researchers dont provide reflexivecomment about their roles in the research,though the approach to data preparationand analysis is clear. The researcherfollowed a recognized published approach todata reduction, display and verification,which on a positive note includedindependent researcher and respondentverification, thus improving trust

worthiness of the data.


17/39

Findings

The researchers determined that the business managementsolution systems have the same analogy as the PCSWsystems, and the following conclusions can be surmised:

The software in the target domain has the same functionalarchitecture in every target domain.

The functional architecture software can be classified intosimilar and individual functions.

In the target domain, the rate of similar functions is of ahigh percentage, and the rate of individual function is of alow percentage.

Requirement specification in the target domain can bedeveloped by combining the same, similar and individualfunctions, if required


18/39

Conclusion

The results derived from data analysis are clearly statedand explained with reference to the research question andhypothesis.

The findings are stated and the authors have related theirfindings with the research purpose and its underlyingassumptions 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 efficientdevelopment of more adequate requirement specifications.

In addition, the proposed method will be applied to newdomains, and the results will be evaluated collaterally. Inthis way, the generality of the proposed method will beconfirmed. However, the authors also appreciate that it isnot easy to introduce such big structural changes.


19/39

Relation with other Research papers

The introduction of software based instrumentationand plant control systems has raised many issues of

safety and economics.

Matthew S. Jatte et.al is focused on application-independent criteria which can be evaluated bylooking at the software requirement specificationalone comparatively much better than the researchapproach followed by the authors that is applicationdependent.

Rajeev Alur et.al also utilized the interim researchidea of the authors and designed a prototype

implementation for scheduling of control systems.


20/39

Fenton N et.al have used the appropriatemethods for automation requirements inplant control system.

T. Bultan have used Action Language for

model checkingMethew S.Jafee et.al provided details for

fortification and safety.

Research studies embedded software must

provide ample information tracy et.alprovided supporting tables for faultprediction in software engineering study


21/39

Strengths and limitations of Research

paper


22/39

Strengths

The abstract accurately described theobjectives and results obtained and the aimsof the study were clearly described, theabstract included material that can besubstantiated.

The research design provided a satisfactorytest of the research hypotheses.

Measures of the independent and dependentvariables been shown to be a reliable in thepresent research and in previous research(e.g., test-retest reliability, internalreliability)?


23/39

All conclusions were supported by thestudys findings.

The authors discussed their results inrelation to available information.

The results obtained were statisticallysignificant.

The authors adequately interpreted theirdata.

The authors discussed data presented withreference to unpublished work.

The authors indicated the reasons whyparticular procedures were used.


24/39

The experiments were done appropriatelywith respect to objectives of the study.

There is no fault in the logic of thetheoretical rationale for the research

The legends to the figures describe clearlythe data obtained.

The authors have cited appropriate papersfor comments made.


25/39

Weaknesses

The researchers choose the most

appropriate research method for theparticular research question that they wereinvestigating.

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 missingdata.

The authors did not discuss the limitationsof the methods used.


26/39

If methods were modified, the modificationswere not described carefully.

The authors have not indicated clearly thepotential problems with the methods used.

Inadequate details provided by authorsregarding the implementation of Proposedmethod in plants

Researchers mostly focused on functional

requirements and didnt propose method forgathering non-functional requirements forembedded systems.

Authors did not mention the time framerequired for implementing this methodology


27/39

No proper methods were listed by theauthors for verification and model checkingof embedded control systems.

Automation requirements as well as

maintainability requirements are missed inthis research paper. Authors have notprovided the details regarding themaintainability and automation.


28/39

Critical Analysis at a glance withthe help of research questions


29/39


30/39


31/39


32/39

MethodologyCriticism &

Proposed SolutionPresenter

KASHIF ULLAH KHAN


33/39

Prototyping is an expensive activityPrototyping is an time intensive activity

Prototyping may cause schedule over slip

Developers does not favor too much user

involvementToo many changes may disturb the Dev

Team.


34/39

Client may assume that product will bedeveloped quickly

Prototype may cause Absence of Viewbetween client and prototype

Developer may make implementationcompromises.

Prototype is not converted in end product,waste of effort

Client may measure/map the effort requiredfor product by prototype.


35/39

Prototype is a low quality code that maycause higher customer expectations.

Prototype is only for functionalrequirements , Client have no idea aboutquality attributes of the end product.

Performance may degrade from prototype toend product.

Developer may try to convert prototype intoactual product.


36/39

What to use if not prototype ?


37/39

I would suggest use Rapid ApplicationDevelopment.

RAD is similar like prototyping but as itsname sounds, its rapid.

RAD focuses on building applications in avery short amount of time(Weeks/Months).

Client is involved with the developmentteam.


38/39

Critical features go first.Non-Critical are achieved in later releases.

Client collaboration make Dev teamsynchronize with the needs.


39/39

final pres.ppt

Documents