Child pages
  • XSEDE Quarterly Meeting - Aug 29-31 2016 - CI Requirements Breakout
Skip to end of metadata
Go to start of metadata

Discussion Outline

Motivation

To achieve its vision XSEDE must enable and enhance access to and usage of integrated cyberinfrastructure. We need to gather and understand CI access and usage requirements from users directly and from the resource, software, and service providers that serve users.

XCI is wrapping up XSEDE 1 prioritized use case priorities.

The XSEDE 2 proposal process prioritized use cases for PY1.

We need to engage with existing and new communities to identify requirements to work on in PY2 and beyond.

CEE can discover many requirements thru education and engagement activities. CEE proposed to gather requirements and produce actionable lightweight Use Case documents: "the UE team will process and track actionable items obtained from user feedback and monitor them throughout the UE loop, from assignment to a responsible XSEDE party through communication of subsequent actions back to the user community. To obtain user feedback, we will engage users of XSEDE’s resources and services to gauge overall satisfaction, pervasive problems, emerging needs, and requirements. Integral to this process is the derivation of requirements from diverse sources—micro-surveys, user satisfaction surveys, user interviews—and turning them into actionable Use Cases that can be tracked and handled in all areas of the XSEDE2 organization. The UE team will use tools provided by the XSEDE Project team including JIRA and issue tracking software to monitor requests and enhancements linked to the stakeholders who originated the requirement. The UE team will use this feedback to create a lightweight Use Case document—an encapsulation of user needs via scenarios—attach it to the JIRA issue, and assign it to the responsible XSEDE2 area.".

ECSS can discover many requirements thru its allocated staff engagements, and from the science gateways that it tries to enable.  It proposed "For XCI, ECSS will provide use cases and participate in technical reviews.".

SP proposal include many user requirements. XSEDE needs to maximize both SP and XSEDE infrastructure ROI by looking for opportunities to leverage, coordinate, and integrate capabilities across SP awards. If more than one SP is providing the same or similar integration software function, we should be looking at opportunities to reduce costs and maximize ROI.

Other infrastructures, software awards, vendors, XSEDE operations, and user representatives also have user requirements.

 

Gathering requirements (who, when, and how)

Some concrete examples of the kind of feedback/information we receive.

How and when do we prompt users for requirements?

  • Some may come to us in ad-hoc fashion thru tickets, user-n-staff e-mail, and user-n-staff fact-to-face interactions.
  • CEE (Chris H et. al) request periodic feedback from PIs.
  • ECSS conducts post-engagement interviews with PIs.
  • Could we provide "Feedback links" embedded in XUP component documentation?
  • Other ideas?

How do we demonstrate that giving XSEDE requirements produces results?

We need to demonstrate that we take action on feedback.

  • Thank-you from a human and commitment to respond within X weeks with a plan
  • Respond to user within X weeks explaining how we will address the feedback
  • Inform the user when we've addressed the feedback

How can we streamline the requirements gathering and management process?

  • Do we need to record and track requirements, regardless of source?
  • Who/how will we record and track requirements, regardless of source?
  • Could we have a project wide software/service requirements repository, "customer relationship management" like?
  • Do we make known requirements transparent to users and the public?

How do we branch out to other non-HPC usage modalities and more diverse science domains/communities?

  • Listen or proactively ask: Are we going to be most effective by listening or by reaching out proactively?
  • Proactively ask or analyze: Should we only ask for requirements, or can we try understand the user usage patterns to find opportunities?

Turning requirements into Use Cases

We need to aggregate similar requirements and document them as new or revised use cases. Use cases are what we prioritize and deliver.

  • CEE proposed to produce actionable lightweight Use Case documents
  • ECSS, SPs, and others can produce them also
  • XCI is creating a new Use Case registry to help manage use case information
  • We need to make sure we have a consistent format and process
  • XCI has a proposed new and slightly more compact XSEDE 2 Use Case format

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

 

  • No labels