New Process Model: Yes Confident Software Development Process Model

Transcription

1 S.Thulasi Krishna et al IJCSET March 2012 Vl 2, Issue 3, New Prcess Mdel: Yes Cnfident Sftware Develpment Prcess Mdel S.Thulasi Krishna, K. Rajesh Kumar Reddy Dept f CSE Kuppam Engineering Cllege, Kuppam, Chittr (Dt), AP. thulasi_krishna2001@yah.cm, rajeshk535@gmail.cm Abstract- An verview f the mre cmmn system develpment prcess mdels used t guide the system analysis, design develpment and maintenance f infrmatin. Generally we have many different techniques and methds used t sftware develpment life cycle. Prject and mst real wrd mdels are custmized adaptatins f the generic mdels while each is designed fr a specific purpse r reasn, mst have similar gals and share many cmmn tasks. This paper will explre the similarities and difference amng these varius mdels and als discvery new prcess mdels. Index Terms- prcess mdel, Rup, and v prcess mdel, B&F mdel, F-mdel. I.INTRODUCTION Sftware prcess mdel is an abstract representatin f a sftware prcess [1].Each prcess mdel represents a prcess frm particular prspective, and thus prvides nly partial infrmatin abut that prcess [1].The develpment life cycle f sftware cmprises f fur majr stages namely Requirement Elicitatin, Designing, Cding, Testing. A sftware prcess mdel is the basic frame wrk which gives a wrkflw frm ne stage t the next. This wrkflw is a guideline fr successful planning, rganizatin and final executin f the sftware prject. A prject mdel is chses by keeping in view the nature f prject, tls t be used and discvered by that are required [2].A sftware prcess is a sequence f tasks intended t prduce a high quality sftware prduct n time and with in budget [3].A sftware develpment prcess is structure impsed n the develpment f a sftware prduct. Similar terms include sftware life cycle and sftware prcess. There are several mdels fr each prcess, each describing appraches t a variety f tasks r activities that task place during the prcess, sme peple cnsider a life cycle mdel a mre general terms and a sftware develpment prcess a mre specific term. II.EXISTING SOFTWARE PROCESS MODELS Listed belw are sme traditinal and mst cmmnly used sftware prcess mdels: A. Cncurrent Engineering Mdel: The cncurrent develpment mdel smetimes called cncurrent engineering mdel can be represented schematically as a series f frame wrk activities, sftware engineering actin and task, and their assciated status [4]. Prvide a schematic representatin f ne sftware engineering task with in the mdeling activities fr the cncurrent prcess mdel. The activity-mdeling may be in any ne f the states nted at any given time. Similarly, ther activities r task can be represented in an analgus manner. All activities exist cncurrently but reside in different states.its first iteratin and exist in the waiting changes state. The mdeling activities which existed in the nne state while initial cmmunicatin was cmpleted, nw makes a transitin int the under develpment state. if, hwever, the custmer indicates that changes in requirements must be made, the mdeling activities mves frm the under develpment states int the awaiting changes states. The cncurrent prcess mdel defines a series f events that will trigger transitin frm state t state fr each f the sftware engineering activities, actins, r tasks. The cncurrent mdel is applicable t all types f sftware develpment and prvides an accurate picture f the current state f a prject. Rather than cnfining sftware engineering activities, actins, r task n the netwrk exists simultaneusly with ther activities, actins, r tasks. Events generated at ne pint in the prcess netwrk trigger transitins amng the states. The identified drawbacks f the prcess are: The SRS must be cntinually updated t reflect changes. It requires discipline t avid adding t many new features t late in the prject. B. The V-Mdel: The V-Mdel [5] is an extensin t the water mdel in that it des nt fllw a sequence mdel f executin rather it bends up wrd after the cding phase t frm v-shape it bends upward after the cding phase t frm v-shape. It has the fllwing drawbacks: It addresses sftware develpment within a prject rather than a whle rganizatin. The v-mdel is nt cmplete as it argues t be as it cvers all activities at t an abstract level. C. Build and Fix Mdel: The evlutin f sftware prcess mdels began its jurney frm the mst primeval prcess mdel namely the Build and Fix mdel [8]. This mdel cnstitutes tw basic steps: 1. Writing the Cde 2. Fixing Prblems in the cde. 978

2 T give a clearer picture f its flaws, sme imprtant pints are listed belw: Des nt fllw any prven methd. Its wrking included, first cding then mving twards ther stages. Due t which the resulting prduct had a structure which ften did nt meet the requirements f the user cnsequently ending up in either Prject terminatin redevelpment which was highly expensive [7]. Due t a number f fixes, the resulting cde had a pr structure als these fixes were highly expensive when addressed late in the develpment prcess. This was due t the absence f a detailed design phase befre the cding phase [8]. Nt suitable fr envirnment where changes are dynamic in nature [4]. The mdel handled lightly the testing phase after cding the basic requirements. This eventually led slipping f numerus undiscvered errrs in the cde; weakening its utput [3]. D. Rapid Applicatin Develpment Mdel: The RAD mdel [9] is an adaptatin f the classical mdel fr achieving rapid develpment using cmpnent based cnstructin. If requirements are well understd with a well cnstrained prject scpe, the RAD prcess enables delivery f the fully functin system. The mdel is cnsidered t be incremental develpment mdel and that have emphasis n shrt develpment cycle. Rapid Applicatin Develpment has fllwing drawbacks: Reduced features ccur due t time bxing, where features are delayed t later versins in rder t deliver basic functinality within abbreviated time. Reduced scalability ccurs because a RAD develped applicatin starts as a prttype and evlves int a finished applicatin using existing cmpnent and their integratin. RAD, fr large prjects, requires a sufficient number f human resurces als requiring existence f cmpnents fr reuse. Als RAD is nt suitable fr all types f applicatin develpment [9]. High technical risks discurage RAD use. This is because use f new technlgy in sftware is difficult in a changing glbal sftware market [9]. E. Waterfall Prcess Mdel: The Classical Life Cycle r the Waterfall Prcess Mdel [4] was the first prcess mdel t present a sequential framewrk, describing basic stages that are mandatry fr a successful sftware develpment mdel. It frmed the basis fr mst sftware develpment standards and cnsists f the fllwing phases: Requirements elicitatin, Designing, Implementatin and Testing. The mdel restricted sftware engineers t fllw a Sequential rder mving frm ne stage t the next nly after the cmpletin f the frmer. Listed belw are sme flaws: Rigid design and inflexible prcedure. Restricting back & frth mvement frm a later stage t a frmer ne. When new requirements surface accmmdating thse with existing nes becme difficult due t restrictins in lping back t prir stages. Waterfall Mdel faced inflexible pint slutins which meant that even small amendments in the design were difficult t incrprate later in design phase. As the requirements were frzen befre mving t the design phase, using the incmplete set f requirement, a cmplete design was wrked n. Such an apprach wrked nrmally well fr a small prject requiring average amendments. In case f a large prject, cmpleting a phase and then mving back t recnstruct the same phase, incurred a large verhead. Once a phase is dne, it is nt repeated again that is mvement in the waterfall ges ne t the next and the vice versa is nt supprted. Deadlines are difficult t me in case f large prjects [7]. F. Ratinal Unified Prcess: The RUP [1] prvides dynamic, static and practice perspectives f a prduct. The RUP prvides each team member with the guidelines, templates and tl mentrs necessary fr the entire team t take full advantage f the best practices. The sftware lifecycle is brken int cycles, each cycle wrking n a new generatin f the prduct. This phased mdel identifies fur discrete phases: Inceptin phase Elabratin phase Cnstructin phase Transitin phase The identified drawbacks f the prcess are: Each phase has a milestne which needs t be satisfied fr the next particular phase t start. If the respective milestne f the particular phase is nt satisfied the entire prject might get cancelled r reengineered befre prceeding further. The satisfactin criteria f a particular milestne has its wn cnstraints and are nt listed specifically [6]. G. The Frmal mdel: The frmal methds mdel encmpasses a set f activities that leads t frmal mathematical specificatin f cmputer sftware frmal methds enable a sftware engineer t specify, develp, and verify a cmputer-based system by applying a rigrus. When frmal methds are used during develpment, they prvide a mechanism fr eliminating many f the prblem that are difficult t vercme using ther sftware engineering cardigram These identified drawbacks f the prcess are: The develpment f frmal mdels is currently quite time cnsuming and expensive It is difficult t use the mdels as a cmmunicatin mechanism fr technically unsphisticated custmers. 979

3 III. CONFIDENT SOFTWARE DEVELOPMENT PROCESS MODEL The Cnfident prcess mdel which we have prpsed has seven phases, namely; Feasibility study/requirement, Requirement Based Analysis, Lgical Design, Cnfident Cde, Lgical Testing, Implementatin & Deplyment, and Maintenance. It is a flexible mdel nt restricting the develpers enabling them t mve bth Frnt and back frm any given stage t any ther stage during its lifecycle. Each phase is further divided int sub phases, each specifying a criterin which has t be met t mve t the next phase. This criterin als pints ut which phase t back track in case f failure. The mdel starts with the Feasibility Study/ Requirement and Analysis phase in which requirements are gathered as well as validated by the user. Next phase inline is the Lgical Design, We will design ur sftware.next phase Cnfident Cde, we will write cde cnfident manner. Next phase Lgical Testing phase in which we will testing sftware after cding. Next phase, Deplyment,it s last phase,ur sftware and later n it is tested and is validated by the user. But meanwhile if sme f the requirements changes r new requirements surface during this phase, then we can lp back t requirement phase t accmmdate new requirements with the existing ne. Fllwing this phase is the Implementatin and Deplyment phase which ultimately leads t Maintenance Phase. have requirement are thse which have lesser pririty wing t trivial implementatin their they are delayed till later versins. Shuld have requirements are equally imprtant and must nt be left ut in later versins. We have divided requirements t have mre and mre fcus n the Must have requirements, and als t make ur wrk simple and easier t carry ut. The requirements are then initially Verificatin and validated by the user and we are left with the refined requirements nly. Initial Verificatin and Validatin by the user will ensure whether r nt the develper is ging in the right directin and that all the cncerned parties are cmmitted with the requirements being gathered. The refined requirements are als revalidated again by the user in the Final Validatin step t get the clear and bvius picture f the user requirements. Then all the requirements i.e. Must have and Shuld have are integrated t have the verall scenari f requirements fr the sftware. Figure 1: A. Identify Requirements & Requirement Based Analysis(IR&RBA): First, Feasibility study, System Based Requirement and Mdel Based Requirement, Identify requirements and are divided int Must have and Shuld have requirements as shwn in fig. 2. The Must have requirements are thse which are mst imprtant t the system and must be the part f the system. These mandatry requirements are expected t be implemented in the first versin itself. While Shuld Figure 2: Identify Requirement &Requirement Based Analysis B. Lgical Design with Validatin: Beginning f Design phase is marked by the existence f an Initial Architectural Mdel. Architecture Mdel cnsists f all basic mdules that ur system will have. The next step is the Risk Analysis and Risk Reslutin f the Architectural 980

4 Mdel in the Designing phase. A risk [10] is a ptential fr lss r damage t develpment f the sftware frm materialized threats. Risk Analysis attempts t identify all the risks and then quantify the severity f the risks. If it ccurs, it explits vulnerability in the security f a cmputer based system. Here, different risks invlved are identified and reslved ensuring secure develpment and advancement f the design twards its deliverable versin. This step leads t achievement f a Design. Fllwing this step is the Mdel Validatin step. Here the identified Architectural Mdel is validated ensuring all basic mdules have been cvered. The validatin s majr bjective is t ensure that all cncerned parties are equally satisfied by the utput. Once the design is validated and is fund t be up t the mark, next step is t give a mre detailed cmplete Design Fig 3. Each Validatin sub phase in Design phase cmmands fulfillment f a certain criteria. Criteria fulfillment allws mving dwnward/ frward in the flw twards the next phase whereas criteria nn-fulfillment restricts mving frward and lps back t the phase decided by the criteria. The flw wrks its way all the way back twards the phase it lped back frm. The criteria fulfillment is tested again and next decisin is taken accrdingly. bx testing, and as such, shuld require n knwledge f the inner design f the cde r lgic. [16] Nw, the sftware is validated and verified by the cncerned authrity. After which the system is deplyed. Deplyment shuld be interpreted as a general prcess that has t be custmized accrding t specific requirements r characteristics. Cnfident Cde Risk Analysis and Reslutin Lgical Testing Verificatin Validatin Initial Architectural Mdel Deplyment Requirement Based Analysis Lgical Design Validatin Cmplete Design Figure 3: Lgical Design & Testing C. Cde &Deplyment: The first sub phase f cde & Deplyment is Cding. Next this cding is analyzed fr Risks (if any) and their Reslutin. Risk Analysis and Reslutin (if any) like technlgy risk, platfrm risk, prgramming language risk, and last but nt least the cst risk. Then, whle system is tested; here the System Testing is invlved. System testing f sftware is testing cnducted n a cmplete, integrated system t evaluate the system's cmpliance with its specified requirements. System testing falls within the scpe f black Figure 4: Cnfident Cde & Deplyment D. Maintenance: Maintenance refers t mdificatin in the prduct after delivery, t crrect errrs r t imprve the perfrmance. Maintenance phase in ur mdel may include many activities like creatin f management plan, analysis f the prblem prcess. It includes ther activities like cding f mdificatin, checking whether the sftware cnfrms t particular envirnment r nt whatever is needed. IV.CONCLUSION Waterfall assumes all upcming requirements t be frzen and t be accmmdated in later versins f the prduct. In Cnfident Mdel, we haven t frzen requirement phase, ne can mve easily frm design phase t requirement phase if a new requirement(s) surfaces. We can easily incrprate small t large changes in any phase. Unlike Evlutinary Mdel, Cnfident Mdel des nt include users invlvement at every step rather users are invlved nly when there are critical assessments t be made. In prttype mdel, the user is prvided with the dem f the system. The user suggestins and feedback are used t incrprate new requirements and crrect existing nes. This ultimately ends up in nt knwing in advance hw lng it will take t cmplete a prject. 981

5 REFERENCES [1] Ian Smerville, Sftware Engineering, 8th Editin, 2006, pp. 89. [2] R.S. Pressman, Sftware Engineering, A Practitiner s Apprach,5 th ed. New Yrk: McGraw-Hill, 2001, pp. 26. [3] Sftware prject management a Real Wrd Guide t success persn Educatin, pp.25 [4] Rger S.Pressman Sftware Engineering, a practitiner s Apprch 6 th Ed New Yrk: McGraw-hill 2005 pp 88. [5] Jeff Tian, Suthern Methdist University, Dallas, Sftware Quality Engineering, IEEE, Cmputer Sciety Publicatin, Willy Inter Science, [6] P. Kruchten, Ratinal Unified Prcess Best Practices fr Sftware Develpment Teams, Canada: ratinal Sftware, 2001 [7] B.W. Behm, Anchring the Sftware Prcess, IEEE, IEEE Sftware, vl. 13, Issue 4, July 1996, pp [8] E. Carmel, S. Becker, A Prcess Mdel Fr Packaged Sftware Develpment, IEEE, IEEE Transactin n Engineering Management, vl. 42, Feb 1995, pp [9] R.S. Pressman, Sftware Engineering, A Practitiner s Apprach, 5th ed. NewYrk: McGraw-Hill, 2001, pp. 34. [10] Analysis/, accessed n 25, Nv [11]" Testing" accessed n 26, Nv AUTHORS: S.THULASI KRISHNA received the B.Tech. Degree in Cmputer Science and Engineering frm Jawaharlal Nehru University,Hyderbad,India in 2005, M.E frm Sathyabama University Chennai,and Ph.D pursing frm Rayalaseema University,Kurnl. He jined as Asst.prfessr in VIST Engineering Cllege in august 2005,Hyderabad. He was wrked as Ass.Prfessr in Vidyanikethan Engineering Cllege Tirupathi. and currently wrking as Ass.Prfessr in Kuppam Engineering Cllege. He is member f Internatinal Assciatin f Engineering. K. Rajesh Kumar Reddy received the B.Tech. Degree in Cmputer Science and Engineering frm Jawaharlal Nehru University, Anantapur in 2009, M.Tech frm Jawaharlal Nehru University, Anantapur in 2011 and currently wrking as Assistant Prfessr in Kuppam Engineering Cllege. He is member f Internatinal Assciatin f Engineering. 982