1 / 16

User requirements for UK e-Science grid environments

User requirements for UK e-Science grid environments. Bruce Beckles University of Cambridge Computing Service. Background (1). Growing technical concern about “grid technologies”: Suitability and Direction particularly amongst “grid developers” and deployers over the last year

zihna
Télécharger la présentation

User requirements for UK e-Science grid environments

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. User requirementsforUK e-Science grid environments Bruce Beckles University of Cambridge Computing Service

  2. Background (1) • Growing technical concern about “grid technologies”: • Suitability and Direction • particularly amongst “grid developers” and deployers • over the last year • “Workshop on Requirements Capture for Collaboration in e-Science” • Intense discussion within the UK Grid Engineering Task Force (ETF)

  3. Background (2) – WSRF • The WSRF standard: • announced at the start of the year • “the way forward for grid technology” • WSRF is an “open standard”: • designed “in secret”, with “limited consultation” • by the Globus Alliance, IBM and HP • Concern about the viability of current e-Science projects

  4. A Technical Perspective • “grid technologies” and “grid infrastructure”: • “low level plumbing” for “grid applications” • If the plumbing is wrong then application development is futile. • “The Globus Toolkit” / “WSRF”: • What is the question? • No question, can’t critique!

  5. Another Perspective… Grid technology developer: “Here’s a thing I just developed. I’m sure it’ll be useful to you for something or other. Go on, give it a whirl…” Grid infrastructure developer: “OK, I’ll deploy it so that my application developers can use it. Boy, this sure is complicated to deploy… Umm, what did you say it should be used for again?” Grid application developer: “Right, so this is the latest grid technology? Great. I’ll build it into my application… Now my application is five times as large, doesn’t do anything useful and I have a migraine. Why am I doing this?” End-user: “I am confused. Please help.”

  6. What problem are we trying to solve? • Difficult problem but no clear formulation: • can’t use systematic approach, so… • use combination of: • Intuition: complex problem, intuition unreliable • Trial and error: complex problem, lots of trials! • Luck • The ETF’s goal: To deploy grid infrastructure that is useful to the UK e-Science community • Is it useful?: • Don’t know unless have a clear, technical statement of “useful” • So…

  7. The ETF’s position (then) • Concerned that: • not delivering useful “grid infrastructure” • not clear what it should deliver • not clear what “grid technology” to use • A requirements gathering exercise: • Gather data to help address these concerns • Some more enthusiastic than others

  8. Proposed Requirements Capture Exercise • Discussed on ETF mailing list • Active involvement by ETF members • Intended consultation with: • UK e-Science Usability Task Force (UTF) • UK e-Science User Group

  9. Phase 1: Contacts • Canvass ETF: • opinions on relevant: • issues • people • detailed interviews as appropriate • Ask e-Science Centres via ETF: • description of their projects • contacts for these projects • contacts for other projects that might benefit from “grid technology”. • Examine UK e-Science Stakeholders Meeting attendance list • Use ‘snowball’ technique to gather further contacts

  10. Phase 2: Requirements Elicitation • Analyse contacts to determine ‘representative’ cross-section • Undertake contextual interviews: • about 5 interviews/‘user group’ • about 10 such groups • Raw data made available to interested parties

  11. Phase 3: Requirements Analysis • Data analysis: • Contextual Design (Beyer & Holtzblatt) • Interaction Design (Cooper & Reimann) • Produce: • user personas (‘grid users’) • user scenarios (‘grid application use’) • Derive: • detailed use cases • technical specifications

  12. Phase 4: Validation • Choose representative sample of contacts • Design questionnaire: • Describe newly generated requirements • Ask respondents to rate them in importance • Follow best survey practice

  13. So what happened? “the ETF should not put too much effort into gathering new statements of requirements” “other groups should take this responsibility” – Director, . UK e-Science Core Programme (as reported to the ETF) .

  14. The ETF’s position (now) “Requirements analysis? Never heard of it.” (I paraphrase)

  15. And from this we learnt? Requirements gathering is a political activity. • So either: • be willing to defy political authorities, or • convince them that you will validate their decisions, or • convince them that you will produce nothing of interest.

  16. So now? • No longer directly working for e-Science Programme. • Still working within University of Cambridge • Responsible for: • promotion of e-Science and its related technologies within University • allows a scaled-down version of requirements gathering • University of Cambridge: • leading research university, so… • likely to have a reasonably representative sample of potential users of “grid technology”. • So watch this space… (and all help gratefully received!…)

More Related