INTRODUCING INTEGRATED COMPONENT-BASED DEVELOPMENT (ICBD) LIFECYCLE AND MODEL

INTRODUCING INTEGRATED COMPONENT-BASED DEVELOPMENT (ICBD) LIFECYCLE AND MODEL Amr Rekaby 1 and Ayat Osama 1 1 Egyptian Research and Scientific Innvatin Lab (ERSIL), Cair, Egypt Rekaby@ersil.rg Ayat.mhamed@ersil.rg ABSTRACT Cmpnent-based develpment methdlgy is ne f the recent research windws in sftware engineering field. It investigates in hw t build a reusable cmpnent t be used later in anther applicatin/cntext/dmain. It targets the increase f sftware quality and the decrease f the prductin cst. Cmpnent-based develpment has many challenges t be applied in real wrld such as the impact n the running prject schedule and budget. In this paper, a survey f cmpnent-based develpment and reuse driven develpment life cycles is presented. We present ur prpsed mdel Integrated Cmpnent-Based develpment (ICBD) life cycle. ICBD cntains all the needed activities twards a cmplete cmpnent-based develpment lifecycle. Cmparisn between ICBD, nrmal cmpnent-based develpment, and nn-cmpnent based develpment is prvided in this research. The presented case study prves that ICBD culd decrease the effrt f the prjects by 40% after few mnths f applying. KEYWORDS Integrated Cmpnent-based Develpment (ICBD), Cmpnent -based Develpment, Cmpnent-based Develpment Lifecycle, Reusable Driven Develpment. 1. INTRODUCTION Cmpnent-based develpment methdlgy is a way f sftware develpment that targets building reusable cmpnents t be prbably ready fr further reuse in ther prjects/prducts [1]. This reusability decreases the cst f the fllwing prjects and increases the quality and the stability f the prduct [11]. The reusability in sftware develpment is nt a new term. It is existing starting frm structure prgramming languages thrugh develping a functin r methd and reusing its lgic in many prject areas by functin calling [10]. The imprtance f the reusable cmpnent develpment is extremely demnstrated in the market survey [2]. This survey mentins that Tshiba reduced the defects by 20-30% per line f cde when they have reusability by 60%. NASA reprts said that reusability reduced the verall develpment effrt and cst by 75%. 1.1. Sftware Reusability Levels There are many levels f reusability in sftware wrld, samples f these levels are [2]: DOI : 10.5121/ijsea.2012.3607 87

Cde-level cmpnent reusability Surce cde cnstructs a cmpnent ( fine-grained unit). This cmpnent is reusabilityenabled t be injected in anther cntext. The new prjects may be within the same business dmain r they may be in a different business dmain. Technlgy disciplines are a restricting cnstraint n such reusability level, fr example: Java cmpnent will nt be reused in.net prject even if they are in the same dmain and fulfil all the requirements needs. Cde-level cmpnents are always targeting technical functinal reusability, nt a business functinal prviding. Examples f technical functinality are: lgging, XML manipulatin, XSLT cnversin, java bjects mapping, etc. Business functinality examples are: student registratin, emplyees pay rll management. Reusability f bject riented classes affects the needed testing effrts psitively [12]. Functinal mdule reusability Functinal mdule level is the wider scpe f cde-level reusability. The mdule is a carse-grained cmpnent that cntains many cde-level cmpnents. On this level, the mdule culd be business functinal prvider, technical functinal prvider r bth. Design pattern reusability Design pattern is a cmmnly knwn way f reusability. Design pattern is a design (and might include implementatin) f already experienced slutins fr cmmn knwn prblems. These slutins are reused in any cntext which faces the same prblem. Library reusability Library is an encapsulated versin f functinal mdule reusability. It is a black bx which prvides cncrete services. Library is als technical dependant. It culd prvide a technical/business services. Service riented reusability Frm service riented architecture (SOA) pint f view, the system is built based n a set f independent services. These services are expsed t be used accrding t a cnsuming schema. Wh have the privilege, and use the schema prperly, culd cnsume these services. Framewrk reusability Framewrk is a huge reusable unit that cntains services and culd manage his wrk thrugh internal lifecycle. Framewrks always have a lt f cnfiguratin and custmizatin twards mre users satisfactin acquiring. Examples f java web develpment framewrks are JSF, hibernate, spring, etc. Cnfigurable applicatin reusability Prducts in specific dmain (clinical management fr example) are high cnfigurable applicatins. These prducts are highly custmized enabled t be able t be adapted with custmer needs t achieve the satisfactin. A big cnstraint in such level is the business dmain. Almst all these prducts are very cupled with specific business dmain and family f specific requirements. 88

Cmmercial-O-The-Shelf reusability Cmmercial n the shelf integratin is the highest reusable cmpnents level. It integrates already develped and running cmmercials frm the shelf t get mre cmplicated functinality. Huge rganizatins like HP, IBM perfrm these integratins between their prducts twards mre business deals, sales and revenue generatin. This paper fcuses n a fine-grained and medium-grained reusability. It fcuses n levels frm cde-level t SOA reusability. 1.2. Cmpnent-based Develpment Mdel Intrductin The cst reductin cmes frm deleting part f the develpment effrt in the prject; uses already implemented stuff, and just integrate it int the new prject cde. Already dne cmpnents are theretically tested befre, s it wuld increase the prduct quality. Detailed life cycle f the reusable cmpnent develpment is discussed in sectin 2. White bx and Black bx cmpnents are prpsed in sectin 3 as part f the prpsed integrated cmpnent-based develpment life cycle (ICBD). Initially, there are tw rles in cmpnent-based develpment lifecycle [4]: Cmpnent prducer: This is the team that creates the reusable cmpnents and tests it t be ready fr future needs. This culd be dne in many ways like: A separate team activity. This team searches fr cmpnents that are needed, then design and develp them in advance. As pst prject activities, after the prject delivery, investigatrs wrk n the prject s artifacts t extract cmpnents which culd be reused later in ther prjects. Cmpnent cnsumer: This is the new prject teams wh get the cmpnents and integrate them int their new surce cde. The reusable cmpnent always stred in specific repsitry fr cmpnents. This repsitry is the surce fr cnsumer searching. ICBD mdel prpsed in this paper (presented in sectin3) will present a new visin in these rles. Budget and cst is the main driver in the sftware prjects. The prjects decide either they cnsume already existing cmpnents r develp their new wn accrding t cst calculatins. Mre details f the cst calculatins are presented in next sectins. The structure f the paper is as the fllwing: sectin 2 presents a survey n the cmpnent based develpment life cycle and guidelines, sectin 3 cntains the prpsed Integrated cmpnent based develpment mdel, and evaluatin and assessment are presented in sectin 4. At the end f the paper, the cnclusin is prvided. 89

2. COMPONENT-BASE DEVELOPMENT The Cmpnent-Base develpment (CBD) is based n the integratin f already develped reusable cmpnents that are picked frm the rganizatin reusable cmpnents repsitry [5]. CBD is divided int tw parts. The first ne is fr develping/prducing the reusable cmpnent, the ther part is fr using/cnsuming the reusable cmpnent. Mst f the researches handle these tw parts f lifecycle separately. In the next subsectins, descriptin f the cmpnent develpment and cnsuming lifecycles are presented. Afterwards guidelines f the cmpnentbased develpment verall will be mentined [4]. 2.1. CBD Lifecycle phases This sectin is describing the Cmpnent-based develpment lifecycle [5] and a cmpare between it and the nn-cmpnent based develpment lifecycle. Figure 1. V develpment prcess fr CBD [5] As presented in the figure 1, the cmpnent prductin phases are shwn in cmpnent develpment sectin. The prducing life cycle is the same as any nrmal sftware develpment lifecycle (analysis, design...etc). The cmpnent develpment lifecycle is cmpletely separated frm the cmpnent-based develpment prjects lifecycle (prjects that cnsume the reusable cmpnents). The cmpnent develpment lifecycle is an rganizatinal scpe activity, where the rganizatin dedicates a develpment team t create these cmpnents. The system develpment sectin as shwn in figure 1, is related t the cmpnents cnsuming. It shws the difference between the develpments lifecycle fr cmpnent based prject and nncmpnent based prject. As cmmnly knwn, in the requirements phase the system/prject requirements is cllected. In the system design phase the whle system design is prpsed based n the requirements cllected in the previus step. Here a questin may be raised regarding whether the design shuld 90

be twinkled based n the cmpnents in the repsitry r shuld the designer ignre this pint and subsequently design withut lking at the repsitry. The grey blck in figure 1 shws the lifecycle phases related t nn-cmpnent based lifecycle. These phases are the difference between cmpnent based life cycle and nn-cmpnent based lifecycle. Here in the grey blck, there will be unit design phase f the systems cmpnents. Then unit implementatin based n the unit design in the previus step. Afterwards, there will be a unit test fr the implemented sftware pieces. Figure 1 als shws the phases f select/adapt/test. These three phases are different frm the nncmpnent based develpment lifecycle phases. In the select phase, the develper will lk in the repsitry t find the cmpnent that will mstly match the system design. As in figure 1, the develper will lk in the repsitry fr all pssible cmpnents t match the system design. Then the develper will evaluate the retrieved cmpnents t decide which cmpnents will be used. Many researches fcus n the evaluatin and cmpnent validatin techniques [3]. In the adapt phase the develper will have t mdify in the cmpnent if it desn t cmpletely fit the design. Hwever if the cmpnent matches the design perfectly then this phase will be skipped alng with the test phase as the cmpnent will be ready fr system integratin. The test phase will take place after the cmpnent mdificatin in the previus phase. The test will be unit testing fr the mdified functinalities f the cmpnent. In the system integratin phase the different cmpnents implemented r reused frm the previus phase will be integrated tgether. Integratin test will take place in this phase t. In the system test phase the whle functinality f the system will be tested against the system requirement and design. By the final phase peratin & maintenance, the system will g live in prductin and maintenance n it will take place whenever needed. 2.2. Cmpnent-based Develpment Guidelines In this sectin we will talk abut the guidelines fr cmpnent develpment and the selectin criteria fr the cmpnents frm the repsitry [4]. There are sme guidelines t help the prducer while designing and develping the cmpnents, these guidelines will help him fcusing n the abstractin path and verifying the cmpnents against the bjective f reusability. There are many categries fr the guidelines sme f them are [7]: Language-riented reuse guidelines Reusability is supprted in mst prgramming languages and specially the Object Oriented prgramming language. It s up t the develper t use these functinalities prvided by the prgramming language t generate a reusable cmpnent. But the develper shuld be aware f the language capabilities which culd help in the reusability develpment (packaging, encapsulatin, infrmatin hiding...etc). 91

Dmain-riented reuse guidelines The reuse cmpnent develpment will be based n a given applicatin dmain. Each business dmain has a cmmn lgic which makes the generalizatin inside this dmain much easier than ding it within different dmains. General high-level guidelines [8] Cnducting sftware reuse assessment. Perfrming cst-benefit analysis fr reuse. Adptin f standards fr cmpnents. Selecting pilt prject fr wide deplyment f reuse. Identify reuse metrics. On the ther hand, selecting the cmpnents frm the repsitry is nt easy. Many techniques are used in classifying the cmpnents in the repsitry [9]. The develper has t select the mst suitable cmpnent t fit with the new prject s requirements. The selectin decisin will be very hard when there is a pr dcumentatin f the cmpnents. The adaptatin f the cmpnent might be t cmplex, that it will be easier t implement the cmpnent frm scratch. The decisin f implementing the cmpnent frm scratch r adapt an existing cmpnent depends n many factrs. The mst imprtant factr is the cst, whether implementing frm scratch cst mre than adapting an existing cmpnent r nt. The cst difference can be calculated by the given frmula [8]: C save = C s - C r C d Where C s represents the cst fr implementing the cmpnent frm scratch, C r represents cst f adpting a reusable cmpnent, and C d represents the actual cst f delivering the cmpnent. 3. INTEGRATED COMPONENT-BASED DEVELOPMENT MODEL In this sectin the prpsed integrated cmpnent-based develpment (ICBD) mdel and lifecycle are presented. First, ICBD life cycle details are discussed. Then prpsed guidelines and templates are prvided. 3.1. ICBD Life Cycle ICBD main bjective is the integratin f the tw separated activities: reusable cmpnent prducing and reusable cmpnent cnsuming. While ther researchers studied either prducing r cnsuming, ICBD mdel utilizes the daily prjects activities in prducing the reusable cmpnents. ICBD is cnstructed frm nrmal prject activities/life cycle phases plus new phases and respnsibilities f already existing nes. As presented in figure 2, blue blcks present nrmal nn-cmpnent develpment phases. Green blcks are the cmpnent prducing prpsed phases, while red are the prpsed cmpnent cnsuming phases. The gray repsitry represents reusable cmpnent strage repsitry. As presented in ICBD lifecycle, the prject activities start nrmally accrding t iterative lifecycle (r Agile). After putting the high level design, the team ges int cmpnent searching activity, the team lks up the needs frm the reusable cmpnent repsitry. Either the team culd find a cmpnent and cnsume it (red cnsuming part wuld be described later), r th e team wuld implement the requirements frm scratch. 92

All the implementatins that are dne in the prject g int cmpnent prducing part (green blcks). Details f each blck are presented later. ICBD is always targeting enriching the reusable cmpnent repsitry, s the repsitry is the centre pint f the life cycle that the prducer ends with and the cnsumer starts frm. Figure 2. Prpsed ICBD lifecycle As presented earlier, the cmpnent develpment is either separate rganizatinal activity r pst prject activity. In ICBD, the cmpnent prducing is run thrugh n the nrmal prject activities. The nrmal prject daily effrt is used twards enriching the reusable cmpnents repsitry fr the future needs. The blue blcks are nt discussed in details here due t their ppularity. The cmpnent cnsuming blcks (red) are: Search/Select Cmpnent: In this activity, a senir experienced technical persn searches in the repsitry fr cmpnents that fit the prject needs and the high level design disciplines. Searching in 93

the repsitry with a huge number f available cmpnents is very tugh task. ICBD prpses dcumentatin meta-data infrmatin f each reusable cmpnent in the repsitry. This dcumentatin shuld be dne as a part f cmpnent prducing. The selectin phase uses an autmatin search accrding t this dcumentatin factrs. The dcumentatin template ICBD cmpnent meta-data template is presented in details in the next sectin. Cmpnent Validatin Check: After retrieving the search results there are three scenaris applicable here: N cmpnent available with needed requirements: the prject life cycle cntinue as if it is nrmal nn-cmpnent develpment prject. The prject starts in lw level cmpnent design. ICBD requests that, the lw level designers always d their best in making the design as much general as pssible. This is nly ICBD recmmendatin that shuld run withut actual ding any prject budget/plan vilatin. If the lw level design, implementatin and unit test is general, it wuld be perfect. If they are nt as general as needed, it wuld be handled later in cmpnent prducing phases as described later in this sectin. Fetched cmpnent is 100% matching the requirements (black bx cmpnent): the cmpnent is integrated directly int the prject as described later. Fetched cmpnent is NOT 100% matching the requirements (white bx cmpnent): the cmpnent is adapted then integrated int the prject as described later. Integrate Cmpnent: If the cmpnent is entirely matching the needs, it is cnsidered as a black bx cmpnent. The cmpnent is integrated with n extra unit test effrt (the cmpnent is already tested during the cmpnent prductin phases). Meanwhile, functinal testing will run after the integratin t validate the functinality and the integratin efficiency. Mdify Cmpnent: If the cmpnent is nt cmpletely matching the needs, it is handled as a white bx cmpnent. The cmpnent needs sme enhancements r changes t fulfil the prject needs. It is mandatry befre the integratin within the prject. This enhanced versin f the cmpnent wuld be a candidate fr new reusable cmpnent r new versin f already existing cmpnent. Unit Test Enhancement: Extra unit test effrt is needed accrding t the cmpnent changes. Meanwhile, functinal testing will run after the integratin t validate the functinality and the integratin efficiency. Nw we will discuss the cmpnent prducing blcks (green): 94

Cmpnent Generalizatin Enabling: Cming frm scratch cmpnent develpment r frm mdified reusable cmpnent activity, the generalizatin enabling is the next phase. In ICBD, a team shuld be structured t be respnsible fr the cmpnents prducing. This team is crss rganizatin team, that cntains a member f each prject. In this phase, the design and implementatin f the cmpnent is revisited t be very generic and cnfigurable t be applicable fr reuse in ther prjects. What we mentined abve is that, if the design and implementatin exert an effrt in ding the wrk in a prper reuse way, it wuld minimize the needed effrt here. Abslutely, may be the team f the generalizatin decide that, this stuff is very cupled t a specific prject and n use in enabling it fr reuse. If s, the lifecycle f the prducing is stpped here fr this cmpnent. The level f the cmpnent size vary frm very fine-grained cmpnent till functinal mdule r cmplete service, s the cmpnent X culd be generalized and after that it is generalized again beside cmpnent Y under a bigger cmpnent Z. This pint is very tricky, when a cmpnent shuld be generalized and when nt. The main rule f this pint is will this encapsulated item needed as it is in the future?. If the answer is yes even if the subcmpnents f it are already available but there is a need fr the subcmpnent and als fr the cmplete bigger ne. Reusability Unit Test / Verificatin: Here a unit test fr the cmpnent is dne. In ICBD, unit testing is a mandated deliverable part in each reusable cmpnent. It wuld be enhanced in further prjects if the cmpnent is selected and mdified. The designer f the unit test shuld nly care abut the reusability purpse. Cmpnent Dcumentatin: Dcumenting the cmpnent is mandatry in ICBD. The prpsed template is described in the next sectin. 3.2. ICBD Dcumentatin Templates In this sectin the prpsed cmpnent dcumentatin template is prvided. As presented in figure 3, each cmpnent in the repsitry shuld be tagged with these meta-data. The autmated search fr the cmpnent uses these meta-data fields as search criteria. 95

Figure 3. Prpsed ICBD reusable cmpnent dcumentatin template As presented in figure 3, each cmpnent has unique identificatin. Versin f each cmpnent is very critical during cntinues cmpnent mdificatins and imprvements. Functinal descriptin is very imprtant fr the cnsumer. Als ICBD requires a shrt descriptin f the real prject that creates this cmpnent t give the feel fr the cnsumer where that cmpnent was needed t fulfil the needs. Technical implementatin details are listed in this template, als any technical cmpatibility r restrictins f using the cmpnent. Presenting technical high level infrmatin is very critical twards cnsumer time saving. The input and the utput schema is needed fr the cmpnent integratin. ICBD tries t be technlgy independent, s it gives the flexibility f dcumenting that in whatever the way. It culd be XML, XML schema, UML class diagram... etc. Integratin descriptin dcument is mandatry item in the template. This dcumentatin is frm user (cnsumer) perspective, it describes hw yu culd cnfigure and use this cmpnent withut ging int any internal details f the cmpnent itself. Technical descriptin dcument is nt mandatry item in the template, while we expect that it shuld be filled dwn in all the cases. It is nt mandatry just t avid making the template t cmplex. Missing this part makes the cmpnent drift t be black bx cmpnent, it culd be integrated as is, and therwise it culd nt be adpted due t missing technical infrmatin. The prpsed ICBD technical descriptin dcument template is nt presented in this paper, while any technical descriptin dcument cntaining UML diagram fits here. 96

The last item in the template is the test cases scenaris. This field just describe the expected behaviur f this cmpnent. Withut this dcument, the cnsumer nly expects the behaviur frm the functinal descriptin part. S it is needed fr cnsumer decisin either use this cmpnent r nt. The unit test itself is part f the reusable cmpnent delivery, descriptin f this unit test is expected t be allcated here. 4. ICBD ASSESSMENT AND EVALUATION This sectin presents the evaluatin f the ICBD and its prs and cns against cmpnent-based develpment and nn-cmpnent based develpment The prs f the ICBD mdel are: - ICBD increases the quality against the nn-cmpnent based mdel due t the reusability f the cmpnents. The same prject will act as a cnsumer and prducer, this will increase number f reusable cmpnents added t the repsitry. The repsitry is expected t expand faster than what it des in the cmpnent based mdel ICBD increases the quality against the cmpnent based mdel. The cunt f the reusable cmpnent in the repsitry is mre than what created frm CBD mdel. This increase cmes frm injecting the reusability activities in daily prject implementatin activities which was nt the case in CBD. Mre reusable cmpnents mean mre reusability percentage, which impact the quality psitively. The reuse will be a daily activity as it s invlved in many phases f the ICBD. The dcumentatin prcess and templates prpsed in ICBD mdel makes the selectin phase easier than the CBD mdel and takes less time, autmating the selectin phase grantee better results accuracy. The structure f the team which is respnsible fr the generalizatin phase will minimize the duplicatin f cmpnents in the repsitry. This will decrease the time spent in the selectin phase against the cmpnent based mdel and save any waste f unneeded generalizatin. The generalizatin f the cmpnents will be easier than in CBD, because it will be cnsidered when designing the cmpnent, plus taking the reusability int cnsideratin in all the prjects nrmal activities (it is a subject f the real prjects teams cllabratin and understanding). The cns f the ICBD mdel are: - The intense f the reusable cmpnent prductin depends n the willingness f the develpers; hwever it culd be encuraged by the rganizatin accrding t the rganizatin directin. The cmpnent s prductin team is very critical part f the cycle, it culd cnduct a very rich generalizatin, r it culd harm the prcess accrding t their perfrmance, unit test, dcumentatin...etc. Cmpnent selectin and adaptatin culd be cmplex task in early rganizatin transfrmatin perid frm nn-cmpnent t ICBD, but this cmplexity is decreased by time and becmes a part f the technical team culture. Applying the mdel depends n the existence f qualified and experienced technical persns wh are able t perfrm the generalizatin phase and smetimes cmplex mdificatin f the selected cmpnents. 97

ICBD is currently under validatin in real use case, a use case descriptin is presented in the next sectin while it is still a running case study. 4.2. ICBD Case Study Sftware develpment centre that cntains arund 200 technical (Architects, designer, and develpers) was running n nn-cmpnent based mdel. All this centre prjects are in ne dmain with different custmers (5 custmers in same business dmain). It tries t swi tch t cmpnent-based mdel t minimize the effrt in the prjects and utilized the cmmn effrt. It applied the pst prjects mdel. After the prject delivery, the centre tries t find what culd be extracted t be used in further prjects. The really extracted cmpnents were arund 5 finegrained and medium-grained cmpnents ( fr example, reprting cmpnent fr web applicatins) per quarter. The usage f these cmpnents was almst zer that cmes frm nt encuraging the prjects t select reusable cmpnents fr using beside pr dcumentatin f the cmpnent. Als the little number f cmpnents makes the ptins very pr, s the selectin percentage is very lw. Using ICBD increases the number f reusable cmpnents t mre than 70 cmpnents per quarter. This huge number f cmpnents beside the autmatin f selectin indicates that, the reusability (cnsuming) in the next quarter wuld decrease the prjects effrt by 40%. We estimate that this percentage might increase t 70% after 2 quarters due t repsitry enrichment. 5. CONCLUSION Cmpnent-based develpment is a trend fr cst cutting and quality imprvement in the sftware prductin wrld thrugh reusing f already develped cmpnents. The cmpnent term is varying frm very small scale cmpnent till a whle cnfigurable prject. The cmpnent sizes start frm just a class in bject riented prgramming language (r even a methd in a class) till a cmplete cnfigurable prduct. This paper discussed the reusability cncept in cmpnent-based develpment (CBD). It mentined the rles and respnsibilities. It studies CBD mdel, its lifecycle, cmpnent based develpment guidelines. Afterwards, it presents Integrated Cmpnent-based Develpment (ICBD) mdel. It is an integrated life cycle that cnducts mre prductive sftware prcess by integrating the cmpnents prducing and cnsuming phases int 1 cmplete lifecycle. ICBD is enriched by dcumentatin templates, recmmendatins and mindset changes. This paper demnstrates ICBD phases and supplementary details and templates. The theretical cmparisn presents ICBD s efficiency versus nn-cmpnent and CBD mdels. Running case study shws very prmising results that are mentined in this paper. Using ICBD in applicatin develpment centre that have arund 200 technical guy and wrks in ne business dmain culd decrease the effrt f the new prjects by 40% after 3 mnths f applying. This percentage estimated t be increased t 70% after 6 mnths as lng as it is applied prperly. This percentage f effrts cutting wuld decrease the cst f the new prjects and bviusly increase the quality f the new prduct, parts f this new prduct have been integrated and tested successfully in previus prjects. 98

6. FUTURE WORKS By time, mre précised results f cst cutting are presented. The quality measurements and enhancements are nt studied yet, it shuld be in the ICBD future verificatins factrs. Mre enrichment dcumentatin templates (like integratin and technical descriptin dcuments) are under cnstructin. Setting up these templates as standard within ICBD mdel wuld increase its prductivity and make the cmpnent selectin autmatin Mre efficient. REFERENCES [1] Alan Camern Wills, (1999) Cmpnent Based Develpmen t, TriReme Internatinal Ltd, http://www.trireme.cm [2] B.Jalender, Dr A.Gvardhan & Dr P.Premchand, (2012) Designing cde level reusable sftware cmpnents, Internatinal Jurnal f Sftware Engineering & Applicatins (IJSEA), Vl. 3, N. 1, pp219-229 [3] Basem Y. Alkazemi, (2012) On Verificatin f Sftware Cmpnents, Internatinal Jurnal f Sftware Engineering & Applicatins (IJSEA), Vl.3, N.5 [4] Carma McClure, (1997) Sftware Reuse Techniques, Prentice Hall PTR, ISBN 0-13-6610000-5 [5] Ivica Crnkvic, Stig Larrsn & Michel Chaudrn, (2006) Cmpnent -based Develpment Prcess and Cmpnent Lifecycle, Internatinal Cnference n Sftware Engineering Advances (ICSEA'06), pp.44 [6] J Paul Gibsn, (2009) Sftware Reuse and Plagiarism: A Cde f Practice, ITiCSE '09 Prceedings f the 14th annual ACM SIGCSE cnference n Innvatin and technlgy in cmputer science educatin, pp 55-59 [7] Muthu Ramachandran, (2005) Sftware Reuse Guidlines, ACM SIGSOFT Sftware Engineering Ntes, Vl. 3, N. 3 [8] Nasib Singh Gill, (2003) Reusability Issues in Cmpnent -based Develpment, ACM SIGSOFT SEN. Vl. 28 N. 6, pp. 30-33. [9] P.Niranjan & Dr. C.V.Guru Ra, (2010) A Mck -up Tl fr Sftware Cmpnent Reuse Repsitry, Internatinal Jurnal f Sftware Engineering & Applicatins (IJSEA), Vl.1, N.2 [10] P.Shireesha & Dr.S.S.V.N.Sharma, (2010) Building Reusable Sftware Cmpnent Fr Optimizatin Check in ABAP Cding, Internatinal Jurnal f Sftware Engineering & Applicatins (IJSEA), Vl.1, N.3 [11] Parast Mhagheghi, Reidar Cnradi, Ole M. Killi & Henrik Schwarz, (2004) An Empirical Study f Sftware Reuse vs. Defect-Density and Stability, Prceeding f the 26th Internatinal Cnference n Sftware Engineering (ICSE 04), pp 282-292 [12] Sanjeev Patwa & Anil Kumar Malviya, (2012) Reusability Metrics and Effect f Reusability n Testing f Object Oriented Systems, ACM SIGSOFT Sftware Engineering Ntes, Vl. 37 Issue 5 Authrs Amr Rekaby is MSc in cmputer science (Grid Cmput ing specializatin) in 2012, wrked as a technical cach / leader fr 8 years in multinatinal cmpanies like IBM and HP. He is nw a funder f Egyptian Research and Scientific Innvatin Lab (ERSIL), where he is wrking as a researcher in AI, sftware engineering and parallel cmputing fields. Ayat graduated frm the faculty f engineering Ain Shams University; wrked in EDS/HP fr 5 years as a sftware develper. She is part f the ERSIL research lab. 99