1 / 20

Distributed Software development with Knowledge Experience Packages

Distributed Software development with Knowledge Experience Packages. Pasquale Ardimento 1 , Marta Cimitile 2 , Giuseppe Visaggio 1 1 University of Bari 2 Unitelma Sapienza University of Roma. Fourth International Workshop on Information Systems in Distributed Environment (ISDE ’ 13).

hanne
Download Presentation

Distributed Software development with Knowledge Experience Packages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Software development withKnowledge Experience Packages Pasquale Ardimento1, Marta Cimitile2 , Giuseppe Visaggio1 1University of Bari 2Unitelma Sapienza University of Roma Fourth International Workshop on Information Systems in Distributed Environment (ISDE’13)

  2. Overview Fourth International Workshop on Information Systems in Distributed Environment (ISDE’13) • Distributed Software Development • DSD critical factors and open issues • KEP approach and architectural model • Prometheus • Empirical Validation: adoption of Prometheus in a industrial contest • Discussion • Conclusion and Future work

  3. Distributed Software Development • Distributed Software Development (DSD) is the collaborative development of software across different sites • a knowledge-intensive business involving many people working in different phases and activities • Success depends on the ability to create, share and integrate information

  4. DSD critical factors • Accessing domain knowledge. knowledge about the domain for which software is being developed • Acquiring knowledge about new technologies. organizations must quickly acquire knowledge about new technologies and master them • Sharing knowledge about local policies and practices. new developers in an organization need knowledge about the existing software assets and local programming conventions • Capturing knowledge and knowing who knows what. knowing who has what knowledge is also a requirement for efficiently staffing projects.

  5. Open issues • All these needs require: • formalizing knowledge so that it is comprehensible and reusable by others that are not the author of the knowledge and experience • packaging able to guide the user in applying the knowledge in a given context

  6. Proposed approach • We use the concept of KEP as a chunk of knowledge stored in a Knowledge Experience Base • The KEPs have a predefined structure in order to facilitate stakeholders in the comprehension and the acquisition of the knowledge that they contain

  7. Prometheus • A tool that allows to captures, share and retain content to ensure that one or more software processes are automated and managed • PROMETHEUS has been implemented using SCORM (Shareable Content Object Reference Model) to ensure data interoperability • SCORM introduced a complex idea called sequencing, which is a set of rules that specifies the order in which a learner may experience content objects. In this way it’s possible to use the navigation sequences that effectively the creator of the package consider efficient

  8. Art&Practices

  9. Project component

  10. Tool Component

  11. Evidence Component

  12. Competence Component

  13. Empirical validation • Analyze software production following the Prometheus approach with the aim of evaluating it with respect to Productivity following without use Prometheus from the view point of the software engineer in the context of company-projects • Experiment description: • The experimentation was conduct in collaboration with an Puglia IT Enterprise • Nine projects were considered, four already developed, and therefore without using Prometheus, and five developed using Prometheus. • Empirical investigation concerns both development of new applications and maintenance of already existing applications support

  14. Experiment planning • The experiment was organized in the following experimental runs: • RUN1 retrospective analysis of four projects (P1 , P2 , P3 and P4 ) already developed (legacy projects) for each of one was available documentation • RUN2 five projects (P5 , P6 , P7 , P8 and P9 ) developed from scratch • RUN3 maintenance on P5 , P6 , P7 , P8 and P9 • RUN4 maintenance on P5 , P6 , P7 , P8 and P9 • RUN5 maintenance on P5 , P6 , P7 , P8 and P9

  15. Measurement model • • Productivity indicates effort spent in man hours to develop a software application normalized on Function Points • Size is the total number of Function Points (FPA) added to the application to satisfy requirements of production or maintenance • ManEffort is the time, expressed in man days (1 man day = 8 hours), spent for the development of a new functionality of an application

  16. Experimental results: RUN1 and RUN2 • RUN1 Productivity range goes from 0,11 FP per day to 1,58 FP per day with a mean value that is 0,94 • RUN2 Productivity range goes, except for outliers values, from 1,00 FP to 1,37 FP per day, and the mean value is 1,15 FP per day • The dispersion of the results is very high for RUN1 differently from RUN2 • In RUN1 , without Prometheus, the Productivity range is wider than in RUN2 where developers, were supported by Prometheus

  17. Experimental results: RUN1 and RUN2,3,4,5 • Productivity goes from mean value of 0,94 FP per day in RUN1 to the mean value of 2,14 FP per day using Prometheus in the other four experimental runs • it is possible to note that the value mean of Productivity predictability for RUN3 , RUN4 and RUN5 is lower that value mean of RUN2 probably because of increasing reuse of package. • In each experimental RUN Prometheus is always better than the traditional approach

  18. Experimental results: Reuse in RUN3,4,5 • Reuse grows or could grow with the populating of Prometheus • The main value of reused knowledge changed from 0.45 in RUN3 to 0.75 and 0.85 in RUN4 and RUN5

  19. Conclusions and future work • Prometheus with respect to the traditional approaches systematically formalizes and automates knowledge capturing, sharing and retention • Moreover it promotes reuse of development functionalities reducing in this way the time necessary to produce them • In order to generalize the validity of the lessons learned proposed in this work, many replications, statistical validation and further studies, extended to other contexts, are needed • It is important to note that the selected set of experimental subjects, even if variegate, is not completely representative of the population of all software developers • A controlled experiment was therefore carried out with 14 IT professionals contracted in projects led by the Alarcos research group at the University of Castilla-La Mancha (Spain)

More Related