1 / 4

Model for reuse of “external software”

Model for reuse of “external software”. Firstly we try to understand what we need Then we look for existing components we can reuse HEP libraries, commercial libraries We assess impact of new component on our GAUDI architecture inter-working with existing components

lcolon
Download Presentation

Model for reuse of “external software”

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. Model for reuse of “external software” • Firstly we try to understand what we need • Then we look for existing components we can reuse • HEP libraries, commercial libraries • We assess impact of new component on our GAUDI architecture • inter-working with existing components • We assess impact on long-term maintenance • support, financial cost, risks etc. • Only if we don’t find anything suitable available do we develop the piece ourselves

  2. Participation in development of new software • R&D • informal approach appropriate - explore, prototype - quick & dirty • our role is to follow progress and give suggestions • need good visibility • meetings for information exchange • can be unlimited participation in this meetings • Product development • to be sure we can use product, more formal approach required • as users we are part of project with a formal role to play • users express needs in written form e.g. requirements and use-cases • total visibility - follow all important decisions • formal project meetings with limited participation • Transition between R&D and Product development needs to be handled at the right moment…..not too late

  3. Observations on Existing Meetings • Work well as a forum for information exchange • Discussion often throws up different points of view • Not clear how this input is used in planning work programme • LHCb not always well-prepared and correctly represented to take part in crucial decisions • Can be potential dangers • some idea or suggestion is picked up and acted upon without thorough discussion • mechanism for setting priorities unclear • decisions based on incomplete and imprecise information

  4. A Possible Model for Development Projects • scope of each project specific to one component • e.g. histogramming, espresso, particle properties • each component should conform to a baseline architecture as set out by the system architect • participation of project team members : typical roles to be filled include • project leader • developers • users e.g. 1 per experiment • architect, librarian, documentation manager, test manager • team discusses and agrees on tasks, priorities and responsibilities • publish everything (project plan etc) on web • frequent project meetings for project team only e.g. weekly in dev phase • brief status reports at less frequent information meetings e.g. monthly

More Related