• No results found

An Ant Colony Optimization Approach to the Software Release Planning Problem with Dependent Requirements

N/A
N/A
Protected

Academic year: 2021

Share "An Ant Colony Optimization Approach to the Software Release Planning Problem with Dependent Requirements"

Copied!
35
0
0

Loading.... (view fulltext now)

Full text

(1)

Op#miza#on  in  So,ware  Engineering  Group  (GOES.UECE)  

State  University  of  Ceará,  Brazil

 

Jerffeson  Teixeira  de  Souza,  Camila  Loiola  Brito  Maia,     Thiago  do  Nascimento  Ferreira,  Rafael  Augusto  Ferreira  do  

Carmo  and  Márcia  Maria  Albuquerque  Brasil    

3rd  InternaIonal  Symposium  on  Search  Based  SoKware  Engineering    

September  10  –  12,     Szeged,  Hungary  

Approach to the

Software

 

Release Planning Problem

 

with

Dependent Requirements

 

(2)

       MoIvaIon  

The  

Search  Based  SoKware  Engineering  (SBSE)  

field  

has  been  benefited  from  a  number  of  general  

search  methods.  

Surprisingly,  even  with  the  large  applicability  and  

the  significant  results  obtained  by  the

 Ant  Colony  

OpImizaIon  (ACO)  metaheurisIc

,  very  liXle  has  

been  done  regarding  the  employment  of  this  

strategy  to  tackle  soKware  engineering  problems  

modeled  as  opImizaIon  problems.  

 
(3)

óri  

swarm  intelligence  framework

,  inspired  by  

the  behavior  of  ants  during    

food  search  in  nature.”  

 

Ant  Colony  OpImizaIon  

“ACO  mimics  the  

indirect  

communica#on  strategy    

employed  by  real  ants  mediated    

by  

pheromone

 trails,  allowing  

individual  ants  to  adapt  their  

behavior  to  reflect  the  colony´s  

search  experience.”  

(4)

The  

so'ware  release  planning  

problem  

addresses  the  selec5on  

and  assignment  of  requirements  

to  a  sequence  of  releases,  such  

that  the  

most  important  

and  

riskier

 requirements  are  

an5cipated,  and  both  

cost

 and  

precedence  constraints

 are  met.

 

(5)

 

The  

so'ware  release  planning  problem  

addresses  

the  selec5on  and  assignment  of  requirements  to  a  

sequence  of  releases,  such  that  the  

most  important  

and  

riskier

 requirements  are  an5cipated,  and  both  

(6)

 

(7)

 

(8)

 How  can  the  

ACO  framework  

be  adapted  to    

solve  the  

So'ware  Release  Planning  problem  

in  the  presence  of  dependent  requirements?    

(9)

 How  can  the  ACO  frameworkbe  adapted  to    

solve  the  So'ware  Release  Planning  problem  

in  the  presence  of  dependent  requirements?    

 

 ACO  for  the  So,ware  Release  Planning  problem

?  

 

How  does  the  proposed  ACO  adapta5on

 

compare  

to  other  metaheuris5cs  

in  solving  the  

So'ware  

Release  Planning  problem

 in  the  presence  of  

dependent  requirements?  

 

(10)

How  can  the  ACO  algorithm  be  adapted  to    

solve  the  So'ware  Release  Planning  

problem  in  the  presence  of  dependent  

requirements?    

(11)

PROBLEM ENCONDING

                           The  problem  will  be  encoded  as  a  

directed  graph

,    

                                                                                               ,  where                                                ,  with            

                                                                                       represenIng    mandatory  moves,        

                                                                             and              represenIng  opIonal  ones.  

i.  each  vertex  in                represents  a  requirement                ;  

ii.  a  directed  mandatory  edge                                                  ,  if                                        ;    

(12)

PROBLEM ENCONDING

                                                                                             if  requirement                has  no  precedent                                      requirements  

and                                                                                                                                                                ,                                          for  all  

unvisited  requirements                where  

(13)

OVERALL  INITIALIZATION  

COUNT    ←  1  

MAIN  LOOP  

REPEAT  

   MAIN  LOOP  INITIALIZATION  

   FOR  ALL  ver3ces  ri    ∈  V,  visitedi  ←  False    

   FOR  ALL  ver3ces  ri    ∈  V,  current_planningi  ←  0    

   SINGLE  RELEASE  PLANNING  LOOP      

   //  FINDS  A  NEW  RELEASE  PLANNING  (current_planning)    MAIN  LOOP  FINALIZATION  

   IF  current_planning.eval(  )  >  best_planning.eval(  )  THEN            best_planning  ←    current_planning  

COUNT  ++    

UNTIL    COUNT    >  MAX_COUNT  

(14)

OVERALL  INITIALIZATION  

COUNT    ←  1  

MAIN  LOOP  

REPEAT  

   MAIN  LOOP  INITIALIZATION  

   FOR  ALL  ver3ces  ri    ∈  V,  visitedi  ←  False    

   FOR  ALL  ver3ces  ri    ∈  V,  current_planningi  ←  0    

   SINGLE  RELEASE  PLANNING  LOOP      

   //  FINDS  A  NEW  RELEASE  PLANNING  (current_planning)  

 MAIN  LOOP  FINALIZATION  

   IF  current_planning.eval(  )  >  best_planning.eval(  )  THEN            best_planning  ←    current_planning  

COUNT  ++    

UNTIL    COUNT    >  MAX_COUNT  

(15)

OVERALL  INITIALIZATION  

COUNT    ←  1  

MAIN  LOOP  

REPEAT  

   MAIN  LOOP  INITIALIZATION  

   FOR  ALL  ver3ces  ri    ∈  V,  visitedi  ←  False    

   FOR  ALL  ver3ces  ri    ∈  V,  current_planningi  ←  0    

   SINGLE  RELEASE  PLANNING  LOOP      

   //  FINDS  A  NEW  RELEASE  PLANNING  (current_planning)  

 MAIN  LOOP  FINALIZATION  

   IF  current_planning.eval(  )  >  best_planning.eval(  )  THEN            best_planning  ←    current_planning  

COUNT  ++    

UNTIL    COUNT    >  MAX_COUNT  

(16)

OVERALL  INITIALIZATION  

COUNT    ←  1  

MAIN  LOOP  

REPEAT  

   MAIN  LOOP  INITIALIZATION  

   FOR  ALL  ver3ces  ri    ∈  V,  visitedi  ←  False    

   FOR  ALL  ver3ces  ri    ∈  V,  current_planningi  ←  0    

   SINGLE  RELEASE  PLANNING  LOOP      

   //  FINDS  A  NEW  RELEASE  PLANNING  (current_planning)    MAIN  LOOP  FINALIZATION  

   IF  current_planning.eval(  )  >  best_planning.eval(  )  THEN            best_planning  ←    current_planning  

COUNT  ++    

UNTIL    COUNT    >  MAX_COUNT  

(17)

OVERALL  INITIALIZATION  

COUNT    ←  1  

MAIN  LOOP  

REPEAT  

   MAIN  LOOP  INITIALIZATION  

   FOR  ALL  ver3ces  ri    ∈  V,  visitedi  ←  False    

   FOR  ALL  ver3ces  ri    ∈  V,  current_planningi  ←  0    

   SINGLE  RELEASE  PLANNING  LOOP      

   //  FINDS  A  NEW  RELEASE  PLANNING  (current_planning)    MAIN  LOOP  FINALIZATION  

   IF  current_planning.eval(  )  >  best_planning.eval(  )  THEN            best_planning  ←    current_planning  

COUNT  ++    

UNTIL    COUNT    >  MAX_COUNT  

(18)

 SINGLE  RELEASE  PLANNING  LOOP  

   FOR  EACH  Release,  k  

     Randomly  place  ant  k  in  a  vertex  ri    ∈  V,  where  

       visitedi  ←  False    and  overall_costi  ≤  budgetReleasek  

   ADDS  (ri  ,  k)  

   WHILE  opt_visk(i)  ≠  0  DO  

     Move  ant  k  to  a  vertex  rj  ∈  opt_visk(i)  with  

       probability  pij  k  

     ADDS  (rj  ,  k)        i  ←  j  

(19)

   //  Besides  ri,  adds  to  release  k  all  of  its  dependent  requirements,  and,    repeatedly,  their  dependent  requirements  

 ADDS  (ri  ,  k)    

   ENQUEUE  (Q,  ri)        WHILE  Q  ≠  ∅  DO  

       rs      DEQUEUE  (Q)  

       FOR  EACH  rt    ∈  mand_visk(s)  DO  

         ENQUEUE  (Q,  rt)          visiteds  ←  True  

       current_plannings←  k        

(20)

 SINGLE  RELEASE  PLANNING  LOOP  

   FOR  EACH  Release,  k  

     Randomly  place  ant  k  in  a  vertex  ri    ∈  V,  where  

       visitedi  ←  False    and  overall_costi  ≤  budgetReleasek  

   ADDS  (ri  ,  k)  

   WHILE  opt_visk(i)  ≠  0  DO  

     Move  ant  k  to  a  vertex  rj  ∈  opt_visk(i)  with  

         probability  pij  k    

     ADDS  (rj  ,  k)        i  ←  j  

(21)

How  does  the  proposed  ACO  adapta5on  compare  to  

other  metaheuris5cs  in  solving  the  So'ware  Release  

Planning  problem  in  the  presence  of  dependent  

requirements?  

 

(22)

 The  Experimental  Data  

 Table  below  presents  the  

number  of  releases

,  

requirements

 

and  

clients

 of  a  sample  of  the  

72  syntheIcally  generated  

instances  

used  in  the  experiments.  

Instance  

Name Number  of     Instance  Features

Requirements   Number  ofReleases   Number  of  Clients Precedence  Density Budget  Overall  

I_50.5.5.80 50 5 5 0% 80% I_50.5.5.120 50 5 5 0% 120% I_200.50.20.20.80 200 50 20 20% 80% I_500.50.20.20.120 500 50 20 20% 120%

(23)

                                                                       The  Algorithms  

               Gene5c  Algorithm  (GA)  

 widely  applied  evolu3onary  algorithm,  inspired   by  Darwin´s  theory  of  natural  selec3on,  which   simulates  biological  processes  such  as  

Inheritance,  muta3on,  crossover,  and  selec3on

 

Simulated  Annealing  (SA)    

it  is  a  procedure  for  solving  arbitrary  op3miza3on   problems  based  on  an  analogy  with  the  annealing  

(24)

 Comparison  Metrics  

         Quality  

 it  relates  to  the  quality  of  each  

generated  solu3on,  measured  by  

the  value  of  the  objec3ve  func3on.

 

               Execu5on  Time  

 it  measures  the  required  execu3on  

3me  of  each  strategy.  

(25)

                     PAPER  SUPPORTING  MATERIAL            

                     WEBPAGE  

 

 

hXp://www.larces.uece.br/~goes/rp/aco/

 

(26)

       Results  

ACO  (1k)  x  GA  (1k)  x  SA  (1k)  (General  Results)

 

ACO  performed  beaer  than  GA  and  SA  in  all  cases.    

Percentagewise,  ACO  generated  solu3ons,  in  average,  78.27%  

beaer  than  those  produced  by  GA  and  96.77%  than  SA.    

In  terms  of  execu3on  3me,  ACO  operated  substan3ally  slower  

than  the  other  two  metaheuris3cs.  In  average,  ACO  required  

almost  60  3mes  more  than  GA  and  more  than  90  3mes  more  than  

(27)

Instances  in  which  sta3s3cal  confidence  cannot  be  assured  when  comparing  the   quality  of  the  solu3ons  generated  by  ACO  with  GA  and  SA,  with  all  algorithms  

execu3ng  1000  evalua3ons,  calculated  with  the  Wilcoxon  Ranked  Sum  Test    

ACO  (1k)  x  GA  (1k)  x  SA  (1k)  (StaIsIcal  Analyses)

 

90% confidence level 95% confidence level 99% confidence level

GA I_50.5.5.20.80, I_50.5.20.0.80, I_50.20.20.0.120, I_50.20.20.20.80, I_200.5.20.0.80,I_200.5.20.0.120, I_500.5.5.0.80,I_500.5.20.0.80 I_50.5.5.20.80, I_50.5.20.0.80 I_50.20.20.0.120,I_50.20.20.20.80, I_200.5.20.0.80,I_200.5.20.0.120, I_500.5.5.0.80,I_500.5.20.0.80 I_50.5.5.20.80, I_50.5.20.0.80, I_50.20.20.0.120,I_50.20.20.20.80, I_200.5.20.0.80,I_200.5.20.0.120, I_200.50.20.0.80,I_500.5.5.0.80, I_500.5.20.0.80,I_500.5.20.0.120, I_500.20.20.0.80 SA - -

-Only  for  8  instances  -­‐  out  of  72  -­‐,  sta3s3cal  significance  could  not  be  assured  

under  the  95%  confidence  level  when  comparing  ACO  with  GA.    

For  SA,  even  within  the  99%  level,  ACO  performed  significantly  beaer  in  all  

(28)

       Results  

 

ACO  (1k)  x  GA  (10k)  x  SA  (10k)  (General  Results)

 

The  ACO  algorithm  did  beaer  than  GA  in  69  out  of  the  72  

instances.  

The  exact  same  behavior  occurred  with  SA,  which  outperformed  

ACO  over  the  same  3  instances.    

ACO  was  s3ll  substan3ally  slower  than  GA  and  SA.  This  3me,  

however,  ACO  performed  around  9  3mes  slower  than  both  GA  and  

(29)

Instances  in  which  sta3s3cal  confidence  cannot  be  assured  when  comparing  the   quality  of  the  solu3ons  generated  by  ACO  with  GA  and  SA,  with  ACO  execu3ng  

1000  evalua3ons,  and  GA  and  SA  execu3ng  10000  evalua3ons,  when  ACO  

performed  beaer,  calculated  with  the  Wilcoxon  Ranked  Sum  Test    

ACO  (1k)  x  GA  (10k)  x  SA  (10k)  (StaIsIcal  Analyses)

 

Considering  a  confidence  level  of  95%,  GA  and  SA  had,  respec3vely,  two  and  

three  cases  where  they  were  able  to  produce  significantly  beaer  solu3ons.    

90% confidence level 95% confidence level 99% confidence level

GA I_50.20.5.0.120,I_50.20.20.0.80, I_50.20.20.20.80,I_50.50.20.0.120, I_50.50.20.20.120,I_200.5.20.0.120, I_200.5.20.20.80,I_200.50.20.0.80, I_500.5.5.0.120, I_500.5.20.0.80 I_50.5.5.20.120,I_50.20.5.0.120, I_50.20.20.0.80,I_50.20.20.20.80, I_50.50.20.0.120,I_50.50.20.20.120, I_200.5.20.0.120,I_200.5.20.20.80, I_200.50.20.0.80,I_500.5.5.0.120, I_500.5.20.0.80 I_50.5.5.20.80,I_50.5.5.20.120, I_50.5.20.20.80,I_50.20.5.0.120, I_50.20.5.20.120,I_50.20.20.0.80, I_50.20.20.20.80,I_50.50.5.20.120, I_50.50.20.0.120,I_50.50.20.20.120, I_200.5.20.0.120,I_200.5.20.20.80, I_200.50.20.0.80,I_500.5.5.0.80, I_500.5.5.0.120,I_500.5.20.0.80

(30)

       Results  

 

ACO  (Restricted  Time)  x  GA  (1k)  x  SA  (1k)    

(General  Results)

 

Even  with  the  3me  restric3on,  ACO  con3nues  to  outperform  both  

(31)

Correla3on  metrics  (Pearson,  Kendall  and  Spearman)  over  the  results  

generated  by  ACO    before  and  ajer  the  3me  restric3on.  

ACO  lost  very  liale  of  its  capacity  when  subjected  to  such  3me  constraints.  

When  performing  beaer,  GA  could  not  obtain  solu3ons  significantly  beaer  than  

ACO  (95%  confidence  level).    

Over  all  other  cases,  under  the  95%  level,  ACO  did  significantly  beaer  63  3mes.  

Considering  SA,  ACO  significantly  outperformed  this  algorithm  all  but  one  case.  

 

ACO  (Restricted  Time)  x  GA  (1k)  x  SA  (1k)    

(StaIsIcal  Analyses)

 

Pearson Correlation Kendall Correlation Spearman Correlation ACO (1k) vs ACO - Time GA (1k) 0.9999907 0.9929577 0.9993890
(32)

                         Threats  to  Validity  

Ar5ficial  instances  

Parameteriza5on  of  

algorithms  

(33)

CONCLUSIONS

Very  liXle  has  been  done  regarding  the  employment  of  the  Ant  

Colony  OpImizaIon  (ACO)  framework  to  tackle  soKware  

engineering  problems  modeled  as  opImizaIon  problems.  

This  paper  describes  a  novel  

ACO-­‐based  approach  

for  the  

SoKware  Release  Planning  problem  

with  the  presence  of  

dependent  requirement.  

All  experimental  results  pointed  out  to  the  ability  of  the  

proposed  ACO  approach  to  generate  precise  soluIons  with  

(34)

along  with  

XXV  Brazilian  Symposium  on  SoKware  Engineering  (SBES  2011)   XV  Brazilian  Symposium  on  Programming  Languages  (SBLP  2011)   XIV  Brazilian  Symposium  on  Formal  Methods  (SBMF  2011)   V  Brazilian  Symposium  on  SoKware  Components,    

Architectures  and  Reuse  (SBCARS  2011)  

II Brazilian Wor

k

shop on

Search Based Software

Engineering

 

SÃO  PAULO  -­‐  SP,  BRAZIL     SEPTEMBER  26,  2011    

hap://www.compose.ufpb.br/wesb2011/  

(35)

That  is  it!

 

References

Related documents

Analisis sensivitas ini dilakukan untuk melihat perubahan-perubahan yang terjadi pada usaha pengolahan kerupuk jari Bapak Andika ini dengan kenaikan biaya produksi

however what is incorporated into organisms is not always proportional to what is consumed. Biochemical compounds have recently been explored in marine and terrestrial systems to

Ciaopp also uses analysis information to per- form program transformations and optimizations such as múltiple abstract specialization, parallelization (including granularity

This paper particularly does a study of how Ant Colony optimization is being used for Software Project Resource Allocation to automate the planning and scheduling

We have constructed the graph that will help to assign the dedication of employee to the task. Once the tour is completed the quality of solution is checked by using fitness

Strengthening machine agency through automation may allow human actors to shift activities from the level of detail data collection and local procedure to higher level tactical

The investigation of the curricula at both graduate and undergraduate levels across different colleges (business, IT, science, and engineering) showed that none

Then we apply the closure to the PARENT relation to obtain a BLOCK relation with perfect Recall in terms of name-matching (no matching names are split across blocks).. The