An Ameliorated Methodology for the Design of Project Data Flow Diagram

Transcription

1 An Amelioated Methodology fo the Design of Poject Data Flow Diagam Shivanand M. Handigund 1, Kavitha H. B 2 Dept of M. Tech. CS&E Pogamme, Bangaloe Institute of Technology, Bangaloe , India 1 smhandigund@gmail.com; 2 kavitha672@gmail.com Abstact- The success ate of the softwae development pojects is pathetically vey low. The main causes of low success ate ae attibuted to i) Lack of knowledge of the poject management activities; ii) Non availability of automated tools fo most of the poject activities; iii) Ignoance of undestanding the diffeences between softwae poject management and othe poject management activities. Thus, thee is a geat need to steamline the softwae poject management activities [1]. In this pape an attempt has been made to abstact the needy components though automated methodology fo the design of Poject Data Flow Diagam (PJDFD). This avoids the use of abitay human skills in the component abstaction pocess. The Data Flow Diagam (DFD) components ae abstacted though the design of Poject wok beak stuctue (PJWBS). PJWBS is designed though the decomposition of the poject wok. The entie wok of the poject is epesented as a single node and then a tee stuctue is geneated using the designed node as the oot node and then decomposing the entie wok of the poject andomly in thee consecutive levels based on Knowledge aeas (KA), Poject life cycle (PLC), Softwae development life cycle (SDLC). The leaf nodes obtained afte thee tie decomposition contain the activities, both quantitatively and qualitatively. The output of these activities (the attibutes defined in these activities) foms the deliveables / milestones. Some of these deliveables / milestones may have been efeenced (input) to othe activities. Each of these deliveables thus fom the data stoe between the pedecesso and ancesto activities. The est of the deliveables which ae not efeenced in any of the activities may fom intemediate o final poducts, esults o sevices. Anothe level of datastoes is identified duing the pipelining pocess of activities. The identified activities ae to be timmed as pe the semiotics of DFD [2]. Duing this pocess if the data flows in a pipelining way, then the activities ae meged to fom a pocess. Similaly if the flow of data fom an activity is stacked (set of data is pocessed) and then flowed, we conside the stacking point as the data stoe and the taget activities themselves as the pocesses. This pape discusses ou poposed 22 steps methodologies. In ou poposed PJDFD, we consideed softwae equiements specification (SRS) as input and the poducts, esults o sevices as output and efeenced / defined attibute set as data flows. Keywods- Softwae Requiements Specification (SRS); Entepise Envionmental Factos (EEF); Oganizational Pocess Assets (OPA); Knowledge Aeas (KA); Poject Life Cycle (PLC); Softwae Development Life Cycle (SDLC) I. INTRODUCTION Vision: To develop an automated methodology fo the design of poject data flow diagam. Mission: To abstact the needy components of the PJDFD viz., Acto, Data stoe, Data flow and Pocess. Objectives: 1. To design PJWBS fom softwae equiements specification [1]. 2. To abstact the components of PJDFD fom model elements of PJWBS. A. Motivation Though DFD is one of the thee majo system design diagams, the lack of existence of any automated methodology makes the design, develope dependent as the design pocess is to be caied manually. Since the manual pocedue uses the abitay human skills, the coectness and completeness of the design is always at stake. This has ipple effect on the ensuing softwae. Since the DFD is the unique tool that tansfoms, the numbe of activities into a single activity, it vitually clustes the {7±2} synecdoche activities in to a single activity. PJWBS is an intemediate poduct in ou attempt to develop PJDFD. The PJWBS is useful in authenticating coectness & completeness. The manual pocess the coectness & completeness is authenticated though the manual design of PJDFD and then consulting the client oganization fo its scope. The automated methodology eliminates the need to authenticate the scope though client s oganization. PJWBS is a tee stuctue initially without intedependencies between the same hieachical level nodes that epesent activities (siblings). Hee each hieachical level node epesents activities of Softwae Development Activities o Poject Life Cycle Phases o Knowledge Aeas o any combination of the above. The efeence and defined noun phases identifies espectively the input and output. This can be used to inteconnect o inte-elate the activities. Accoding to [10], pecent of all softwae and pecent of all systems pojects fail. Moeove, ove half of all systems pojects oveun thei budgets and schedules by up to 200 pecent o moe. Of the pojects that fail, appoximately half of that ae estated fail again. The poject is success only if it delives the poduct o sevice on time, on budget, to the customes pescibed equiements. This needs delinking of pojects fom the abitay human skills. This is possible only

2 when the activities involved ae automated. B. Liteatue Suvey In [3] Handigund et al have developed a methodology to abstact the components like data stoe, acto, data flows. But thei abstaction is fom the Cobol pogamming system in which the conventional data pocessing is used. They failed to identify dataflows in a clea cut way. Howeve, the pocess povides some guidelines fo developing the methodology. In [1] the autho has discussed the PJWBS without exemplifying the automated technique. Howeve, the autho has identified the metic of activity though the intesection of KA, SDLC, PLC [4]. This paves the way fo decomposition of the wok in a systematic automated ode. We have developed automated methodology fo the design of activity quantitatively and qualitatively. The components abstacted fom PJWBS may not follow the pagmatics defined in [2]. To incopoate this pagmatics, we have efined the abstacted model elements based on sound logic of data flows pipelining and stacking activities. In [5, 6, 7] the authos have identified synonyms fo the attibutes used though thee methodologies viz., the logical DFD, state chat diagam, and efinement of DFD. We have used the same methodologies to esolve synonyms and homonyms. C. Taxonomy Contol Flow Gaph (CFG) [2]: The contol flow between the statements of SRS in the ealization pocess [1]. Coectness and Completeness: The injection & bijection of functionalities ae used to authenticate the esult. Below Figue 1 shows the coectness & completeness veification though sujection. Data Flow Diagam (DFD): It identifies the behavio of the infomation system identifying the data flows fom input acto to output actos though vaious pocesses, data stoes/ data bases. Abstaction Result * * * * * * * * * Fig. 1 Injection & Bijection Defined Items: The nouns o ad-nouns whose values ae modified duing the ealization of the statement. Defined Items/ Attibutes: The nouns o ad-nouns whose values ae modified duing the pesumed implementation of the statement ae the defined items. Domain Knowledge: Knowledge that is specific fo the paticula infomation system which is application dependant and it mainly focuses on the application to be ealized. Geneal Knowledge: The knowledge possessed by any softwae enginee independent of domain knowledge. Automated methodologies needs only geneal knowledge and do not equie any specific domain knowledge. Refeenced Items: The nouns o ad-nouns which ae used in a statement that may define othe nouns o noun phases without undegoing any modification of thei own values duing the pesumed implementation of the statement ae temed as efeenced items. SRS: It is a document pepaed by the client oganization involving the detailed equiements of thei infomation system which includes the oveview of the system, the functional & nonfunctional equiements of the system, the acto intefaces, the constaints & the pototypes etc [3]. This document is a pat of the poject chate which leads to the fomal commencement of the softwae development. Model Elements: The view element that has got a specific syntax in the semiotic of the language. Hee, model elements include the object class, object state, inteelationship, visibility, package, activity, action state, acto, event, message, use case, guad condition and signal. Entepise Envionmental Factos: The envionmental constaints that affect the poject developments. Oganizational Pocess Assets: The esouces those ae available within the oganization to cay out the poject

3 ------Softwae Development Phases----- Initiating Phase Planning Phase Executing Phase Monitoing & Contolling Phase Closing Phase Global Pespective on Engineeing Management Nov. 2013, Vol. 2 Iss. 4, PP II. PROPOSED METHODOLOGY The input, output and tools & techniques of this poposed methodology ae as follows: Objective: To develop an automated methodology fo the abstaction model, fo the abstaction model elements fom SRS. Input: Softwae equiements specification (SRS) of an infomation system, Softwae poject management activities as defined by [1], Knowledge aea, Softwae development life cycle stages, Poject life cycle phases. Output: Poject data flow diagam Tools: Softwae Poject Management concepts developed by [1], Synonyms and homonyms tools [3, 5, 6], ou poposed Data Pocess Activity Table (DPAT) technique and ou poposed PJWBS technique Techniques: Nowadays, PJDFD is designed by manually abstacting the needy model elements viz., pocess, acto, data stoe and dataflow fom the SRS. Thee ae some constaints on these model elements in the absence of clea cut definitions fo these model elements, manual abstaction depends on the abitay human skills used. Moeove, thee does not exist any standad metics fo these model elements. As a esult, the design of PJDFD is designe dependent. This violates the uniqueness citeion, thus making the design an at. Now it is the time to develop an automated methodology (science) and then optimize with espect to model elements (engineeing). In [1] autho has identified the activities and eticulated them in thee dimensional space fomed by KA, PLC and SDLC. The poject manages ae not awae of the standad PMBOK [4] taxonomy. Moeove, thei does not exist any unique taxonomy fo the poject activities. Thus diffeent poject manages named the activities with diffeent tansitive vebs. Diffeent vebs fo the same activity fom a synonymy so, in using ou automated methodology the uses (poject manages) need to efe the synonymy fo each activity. Hee, as in Figue 2 the entie activities of the Softwae Poject Management (SPM) ae classified into numbe of ealms, based on thei poximity to the specific management pespective Knowledge Phases Requiements Analysis Design Coding Testing Implementing Deliveing Fig. Poject Pocesses Fig. 2 Poject Pocesses We have classified the activities in 10 diffeent ealms called Knowledge Aeas viz.: 1) Poject Integation Management, 2) Poject Scope Management, 3) Poject Time Management, 4) Poject Cost Management, 5) Poject Quality Management, 6) Poject Human Resouce Management, 7) Poject Communication Management, 8) Poject Risk Management, 9) Poject Pocuement Management, 10) Poject Configuation Management. The PMBOK [4] has categoized the poject elated activities into five diffeent phases PLC on the pogess ladde of the poject. The Poject Management Institute (PMI) has consideed the following PLC s in thei PMBOK:

4 1) Initiating Phase, 2) Planning Phase, 3) Executing Phase, 4) Monitoing & Contolling Phase, 5) Closing Phase. Since the softwae poject is invisible, complex, confom to logical laws, in need highly of skilled human esouce fo compaatively smalle amount of time, with poo budgetay & schedule estimate and flexible [8, 9], it needs diffeent tools & techniques than othe pojects. To ovecome these lacunae, the activities need to incopoate cetain additional opeations like stengthening the documentation & design diagams, deleting & coecting eos in activates and authenticating the coectness & completeness. These have been well defined in softwae engineeing as SDLC stages. Theefoe, the poject needs to conside defacto standad life cycle stages: 1) Requiements, 2) Analysis, 3) Design, 4) Coding, 5) Testing, 6) Implementation, 7) Deliveing. Incopoating these activities, we popose to conside the activities as a common facto fo all the thee ealms. Activity = (((Poject wok {KA}) {PLC}) {SDLC}) Hee we have used the compute science meta language. The poject wok contains the functional and non functional equiements efeenced in SRS. Theefoe, in ou poposed methodology, we attempt to identify the poject activities fom the poject wok fomed by functional & non functional equiements of SRS. The softwae poject compises of numbe of activities, if the activity is defined as commonality between KA, PLC, and SDLC. It is wise to decompose the activity at a tie based on once each of the following KA, PLC, and SDLC. Theefoe, we fist conside the design of poject wok beak down stuctue whee decomposition is made on the thee types of ealms. The National Aeonautics and Space Administation (NASA) has defined a systems achitectue [9] as:.how functions ae gouped togethe and inteact with each othe. The achitectue applies to the mission and to inte- and inta-system, segment, element and subsystem. The PJWBS can also be used fo designing softwae achitectue fo the entie poject. The PJWBS is designed by consideing the entie poject task at the oot node. This oot node is decomposed into sub systems in subsequent levels based on KA, PLC and SDLC. In each hieachy of the subtee of PJWBS the decomposition though each of KA, PLC and SDLC should be only once. The decomposition may continue maximum upto level 4. The leaf nodes may not be in the same level. Hee PJWBS levels efe to successive ties of activities with lowest tie epesenting activity qualitatively and quantitatively. The intedependencies between diffeent activities can be identified though efeenced and defined attibutes. These attibutes may epesent attibutes of a ecod o the entie file (document) o any of the design diagams o any technique. These activities ae clusteed based on the pipelining of defined attibutes of an activity with the efeenced attibutes of the subsequent activity. In such case the activities ae clubbed togethe to design a pocess fo the DFD. If the defined attibutes of an activity ae stacked and then efeenced to the next adjacent activity indicating the pesence of data stoe o database. If the defined attibutes of an activity ae not futhe efeenced in any othe activities such activities fom the output and ae clusteed togethe based on the functional dependencies to fom the output acto in the DFD. Of couse the input acto is SRS. Splitting is possible if input fo diffeent output of the activity othewise it may not be possible. In DFD, we nomally conside the following notations as de facto standads. Acto Data file/data stoe Pocess Data flow

5 Acto: File o peson which is outside the scope of the system and which inteacts with the system eithe poviding o consuming the infomation fom the system. The infomation system does not have any contol ove the system i.e. the acto s inteface attibutes ae not modifies within the behavioal tansfomation of the infomation system. Dataflow: It is denoted in the fom of the aow mak that epesents the infomation flow between the components. Data stoe: It may contain data file/database these ae the stoage aea that ae modified within the behavioal tansfomation of the system. Hee, the stack of data that has to be stoed between pocesses and/o actos Pocess: A pocess may compise single o multiple activities with pipelining of dataflows between them. We use siblings technique to cluste the sibling activities using the following noms based on sound logic: 1) Consecutive activities with common data flow, as outflow of the fist activity and inflow of the subsequent activity can be meged into a single activity which late on can paticipate as a pocess in the data flow diagam. 2) Siblings can be combined when one file can give data to two diffeent activities. 3) Input and output fo two o moe activities emanate fom same acto and/o the output flow is also joining same acto o data stoe then thee is possibility of combining all thee. At least one can be combined. The poposed automated methodology fo Poject DFD: 1) Teat the entie poject wok as a single node and design PJWBS. 2) Decompose the node accoding to any of the thee poject space components such as KA, PLC and SDLC [1, 9]. Each level node needs to be divided successively with espect to one of the above thee KA, PLC, SDLC at a time to ensue the unique use of each one of them. The ode of decomposition is immateial and also all nodes of the same level need not be decomposed with espect to same poject space components. 3) Each leaf node is the intesection of KA, PLC and SDLC. 4) Identify the efeence and defined attibute of each activity. 5) Let R i denote the ef attibutes and D i denote the defined attibute of the pocess P i. Hee the efeenced attibute set R i can be obtained by the input o the values of the input of the standad pocess of SPM that matches with P i. Similaly the defined attibute set D i can be obtained by the output o the values of the output of that pocess of softwae poject management that matches with P i. In the wost case, if any of the softwae poject management does not match, then the input/output of the activity is obtained by the oganization pocess assets. 6) Now fom Abstact view elements activity we obtain two data dictionaies containing: a) Acto A i, its coesponding efeence inteface attibute A i and defined inteface attibute A d i; b) Class name C i, its efeence attibute C i and defined attibute C d i. 7) Fo each P i, compute R i A d j fo j= 1 to n. Compute R i C d j fo j = 1 to n and R i C d j fo j 1 vaies fom 1 to n. Fo each P i, compute D i A j fo j = 1 to n. Compute D i C j fo j = 1 to n and D i R j whee j i vaies fom 1 to n. 8) Stoe the above computation in sepaate data dictoies in the descending ode of the numbe of elements. 9) Read the data dictionay enties fom k = 1 to n. R i - R i A d k, R i = R i - R i A d k. Acto=A k, Inflow = A d k. Repeat the pocess till R i φ. 10) Read the data dictionay enties fom k=1 to n R i R i C d k, R i = R i - R i C d k Class =C k, Inflow= C d k. Repeat the pocess till Ri φ. 11) Read the data dictionay enties fom k=1 to n R i - R i D k, R i = R i - R i D k, Pocess= P k, Inflow = D k. Repeat the pocess till R i = φ. 12) Read the data dictionay enties fom k=1 to n Repeat the pocess till R i = φ 13) Read the data dictionay enties fom k=1 to n D i - D i A k, D i = D i - D i A k Acto = A k, Outflow= A k

6 D i - D i C k, D i = D i - D i C k, Class= C k, Inflow= C k 14) Read the data dictionay enties fom k=1 to n. Repeat the pocess till R i = φ D i - D i R k, D i = D i - D i R k, Pocess= P k, Inflow= P k. Repeat the pocess till D i = φ. 15) Design fist cut DFD with espect to P i. 16) Repeat steps 1 to 15 fo i=1 to n. 17) (Repesent each fist cut DFD as an enty in the following table). Combine all the fist cut DFD s using the following table. A A d C C d P R P P d D C C A A A- Input fom acto A d - Input data flow fom acto C- Input fom data stoe to pocess C d - Input data flow fom data stoe to pocess P - Input fom Pocess to cuent pocess R- Input dataflow fom pocess to cuent pocess P- cuent pocess name P d - Connection fom cuent pocess to othe D- Output dataflow fom cuent pocess to othe pocess C- Output fom cuent pocess to data stoe C - Output data flow fom cuent pocess to data stoe A- Output fom cuent pocess to othe A - Output data flow fom cuent pocess to acto 18) Conside the enty P = p i. If R φ fo = 1 ; then seach fo enty P = p 1, in P = p 1 if R and D ae null. Then update P i = p i U p 1 ; p = p - p 1. 19) Conside the enty P= p i. If D φ fo d = d 1 then seach fo enty P = p d1, in P = p d1 if R and D ae null. Then update P i = p i U p d1 ; p d = p d p d1. 20 ) Conside the enty P= p i. If C = c i, c j fo i j then C 1 d C 2 d 21) Conside the enty P = p i. If C = c k, c l fo k l then C 1 C 2 22) Daw DFD fo the above updated table. then c i = c i U c j. then c k,= c k U c l. A B C D E F G H I J K L M A- Input fom acto B- Input data flow fom acto C- Input fom data stoe to pocess D- Input data flow fom data stoe to pocess E- Input fom Pocess to cuent pocess F- Input dataflow fom pocess to cuent pocess G- Cuent pocess name H- Connection fom cuent pocess to othe pocess I- Output dataflow fom cuent pocess to othe pocess J- Output fom cuent pocess to data stoe K- Output data flow fom cuent pocess to data stoe L- Output fom cuent pocess to othe M- Output data flow fom cuent pocess to acto III. CONCLUSION In this pape we made an attempt to abstact the needy components fo the design of the poject data flow diagam fom the concepts of KA, PLC & SDLC. An intemediate PJWBS is developed which is anothe poweful tool to develop othe design

7 diagams like softwae achitectue and PJDFD. An attempt is also made to incopoate synonymies of activities. Howeve due to the limitation we yet to develop methodology fo the abstaction of type of data stoe. Poject pocess has not been standadized, but pototype has been developed by [1]. The coectness & completeness of abstaction depends on the coectness & completeness of Softwae Poject Management. Autho of the SPM named the activities on pa with Poject Management Institute [9], which is still not standadized theefoe giving the scope fo individual developes, we have to identify some of the Synonyms and Homonyms. We have achieved woking dataflow model but still challenges like accessing data to and fom data stoe has not be identified. Poject Data Flow Diagam is limited to fist cut components, we have not automated fo eal time, indexed and hash file oganization. ACKNOWLEDGEMENT Wods ae insufficient to expess ou deep sense of gatitude to D. D. B. Phatak, Pofesso Dept. of Compute Science & Engineeing IIT Bombay, fo his inspiation and encouagement in caying out this eseach poject. REFERENCES [1] S. M. Handigund: A tutoial pesented at Intenational confeence on Advance confeence on netwoks and secuity-2011 ADCONS 2011 held at National Institute of Techonolgy, Suathkal, Mangaloe, India duing16th 18th Dec, [2] Roge S. Pessman, Softwae Engineeing A Pactitione's. Appoach, 6th Edition, McGaw-Hill, [3] S. M. Handigund, Revese engineeing of legacy cobol systems, Ph.D. Thesis, Indian Institute of Technology Bombay, [4] A pape entitled Poject management body of knowledge PMBOK 4th edition 2008, published by Poject Management Institute. [5] A pape entitled Automated Methodologies fo the Design of Flow Diagams fo Development and Maintenance Activities authoed by D. Shivanand M. Handigund and Swetha has been accepted fo the intenational Confeence on E-Business, Technology and Stategy to be held at Ottowa, Canada duing 29, 30th of Septembe' [6] A pape entitled Automated Methodologies fo the Design of Flow Diagam fo Development and Maintenance Activities (pape no. ICETS-SI ) has been published in E-business Technology and Stategy Communications in Compute and Infomation Science, 2010, Volume 113, , DOI: / _8, D. SM Handigund and Swetha Bhat. [7] A pape entitled Automated Methodologies fo the Design of Flow Diagams fo Development and Maintenance Activities (pape no. ICETS-SI ) in poceedings of Joint Confeence of Intenational Confeence on e-business Stategy and Technology, Ottawa, Ontaio, Canada along with Canada-China e-business foum to be held at Ottawa, Ontaio, Canada duing Sept. 29th & 30th, 2010, D. SM Handigund and Swetha Bhat. [8] A pape entitled Softwae Poject Management by Bob Hughes and Mike Cotteell, 5th edition, [9] A pape entitled Managing infomation technology poject by James Taylo in Easten Economy Edition, PHI publication D. Shivanand M. Handigund, is woking as pofesso of compute science & engineeing in Bangaloe Institute of Technology, Bangaloe, India. He has obtained M. Tech CSE and Ph. D degees espectively fom IIT Delhi and IIT Bombay. He has ove 38 yeas of teaching and eseach expeience. He has published 47 papes in intenational jounals and confeences and deliveed seveal tutoials and key note addesses at vaious intenational confeences. Few of his pominent publications ae as follows: 1. In poceedings of Reengineeing Methodology fo Legacy COBOL Systems has been published in poceedings of Intenational confeence on Infomation Technology held duing August 01-04, 2000 at Bangkok, Thailand. 2. A pape entitled Automated Methodologies fo the Design of Flow Diagams fo Development and Maintenance Activities authoed by D. Shivanand M. Handigund and Swetha has been accepted fo the intenational Confeence on E-Business, Technology and Stategy to be held at Ottowa, Canada duing 29, 30th of Septembe' On an invitation by the oganizing committee, a tutoial entitled Softwae Poject Management has been pesented in the Advanced Intenational Confeence on Netwoking and Secuity, National Institute of Technology, Suathkal, Mangaloe, India, Decembe,16-18, S.M.Handigund and shweta, An Amelioated Methodology fo the submitted of object class stuctue fo an Infomation System, Communicated to the 2010 Intenational confeence on Compute Applications and Industial electonics to be held at Kuala Lumpu, Malaysia Decembe

8 Kum. Kavitha H. B. is pusuing he M. Tech degee in CSE, at Bangaloe Institute of Technology, Bangaloe, India. She has published 3 papes in national and intenational confeences unde the guidance of D. Shivanand M. Handigund, Pof. & Head, Dept. M. Tech, CSE. Bangaloe Institute of Technology, Bangaloe, India. Few of he publications ae as follows: 1. A pape entitled An Amelioated Methodology fo the design on Poject Data Flow Diagam authoed by D. Shivanand M. Handigund and Kavitha H. B. has been published at the National Confeence on Advance in Infomation Technology held at Indo Asian Academy goup of institutions, Bangaloe on 2 nd Apil Paticipated in IBM Technology Web Contest 2011 conducted all ove India, by submitting the pape on Hidden Teasues of UML diagams and got selected within 100 paticipants