[Psidev-ms-dev] getting on the same page as we define our process

[Kent L. <Ken...@ge...>]

Hi All,

=20

At the meetings that occurred in Geneva in September there was generally
a positive response to the idea of improving and more accurately
defining the methods whereby the PSI MS working group would produce
standards in the forms of documents, specifications and implementations.
Stated another way, a conclusion was made that in order to increase the
velocity of standards production, the quality of the standards and the
breadth of their usage in both the academic and commercial realms, we
might best begin with a candid reevaluation and re-modulation of our
development process.  In short, we will increase our chances of reaching
the desired destination if we share a common understanding of how we get
there and where we are going.  In order to crystallize this
understanding into a persistent and shareable form, its writing down
should be undertaken.  And so this little exposition is catalyzed.

=20

A development process is a guidance that organizes participants into a
workflow of deliverables leading to a desired product or set of
products.  In our case these products are standards for bioinformatics
interchange.  Development processes range from the simple to very
complex.  The trick is to honor both sufficiency and necessity.  We
should seek to introduce enough rigor to foster timely publishing of
quality work, while avoiding overburdening the process with steps that
reduce agility and do not possess a clear value.=20

=20

A development process consists of a set of process components that
operate both in sequence and often in parallel.  A fairly comprehensive
process component from which we might derive a simpler configuration for
PSI-MS might have the following properties

=20

*	Description - A description defining the process and providing
an overview.
*	Entry Conditions - A list of conditions that should be met
before starting into this process.
*	Exit Conditions - A list of conditions that have been met by
completing this process.
*	Steps - A list of the steps that are followed to complete the
process.
*	Planning Notes - Constraints and notes that will be useful to
project managers and the team.  Notes about complex dependencies that
should be considered during the planning stage will be noted here.
*	Prerequisites - A list of the products from other processes that
will be needed to conduct this process efficiently.
*	Products - The products are the artifacts created by the
process, i.e. the deliverables.
*	Risks - Risks associated with the process are documented in this
section.  Any strategies that can be used to mitigate the risk are also
documented here.
*	Metrics - These are the metrics that will be collected by users
of the process. These processes will be used for aiding in process
improvement. There are two sorts of metrics; sizing metrics are used to
help determine the size of the task, whereas productivity metrics are
used to measure the resources that are expended in completing the
process.
*	Forces - The forces or constraints which affect the process and
define why this process is structured in the way that it is.
*	Resources - The resources needed for this development. This
section should be used in conjunction with the planning notes (if
available).
*	Techniques - A collection of techniques that can be used to help
facilitate the process.
*	Tools - Recommended tools that might prove useful during this
stage of development.
*	Patterns - Recommended patterns that might prove useful during
this stage of development.
*	References - A collection of references for further information.
These references may have hotlinks to supplementary files or documents.
*	Related Principles - A list of principles that are in some way
connected to this process. This section is used to help understand how
this process fits into this development process (and other processes) as
a whole.

=20

The most minimal process consists of resources and products, which means
we assign the responsibility of a deliverable to a participant and offer
no other guidance and observability as to how the participant creates
this deliverable.  While this simplicity can work in cases where scope
is constrained and the resource possesses sufficient knowledge to
reliably produce, this simple of a process granularity does not engender
reproducibility, manageability or scalability.  For PSI-MS (and
hopefully other standards working groups) we should foster a reusable
process with the right levels of definition and rigor that lie somewhere
in between the simple and complex.

=20

As is the case with any technological development, we seek to provide a
mechanism for automating particular aspects of a problem space to serve
the needs of stakeholders.  Stated another way, we want to devise a
complete and accurate rendering of artifacts that satisfies the use
cases of our customer.  This need leads to a few essential questions:

=20

*	Who are the stakeholders?
*	What do they want?
*	Why do they want it?
*	How do we work together to answer stakeholder requirements?
*	How do we describe our solution separate from its
physical/machine process-able form in a way that is human understandable
while allowing for evolutionary/incremental implementation?
*	How do we encode or describe our end deliverable with sufficient
technical accuracy, i.e. it works

=20

A universal problem in technological development is the management of
scope.  The classic dimensions where scope applies include time, cost,
size and complexity.  Generally speaking it is this last dimension,
complexity, which is the ruler/constrainer of the other dimensions.  For
this reason, addressing the layers of abstraction is a primary concern
for any development process.

=20

Well, dear reader, if you have made it this far, the writer expresses
his gratitude for both your patience and tolerance.  He will now
endeavor to "get a grip on things" and drive more toward the pragmatic.

=20

Regardless of domain, most development processes can be organized into
three overarching layers of abstraction.  These are observable from
various roles and perspectives and have been expressed in ways such as:

=20

Conceptual --> Logical --> Physical

Business --> User --> Technical

CIM --> PIM --> PSM

Why --> What --> How

=20

So now let's merge these toward a development process for PSI-MS,
remembering that we should have traceability between the levels.  For
example:  A stakeholder in the first level should be able to navigate to
the relevant artifacts in the second level, and be able to have a
reasonable understanding that these second level constructs address the
needs he or she expressed at the first level.  Correspondingly a party
in the second level should be able to quickly find what implementing
artifacts exist in the third level, while a person in the third level
should have sufficient logical completeness from level 2 to encode a
working solution.  The conceptual and navigational gaps between the
levels should be such that a resource from one level can communicate
effectively with a role one level up or down for such purposes as review
and change requests.

=20

First what are some important characteristics of these three levels?

=20

Level 1 - Visionary, business (Science in our case) driven,
computationally independent, expressing an aim, justifying and or
explaining the basis for the effort

=20

Level 2 - Expressed clearly in human understandable terms, logically
complete without implementation dependence, providing satisfactory
rendering of what the solution is, delineating the contract(s) that the
solution must fulfill

=20

Level 3 - Providing sufficient technical detail leading to a machine
process-able implementation or an automated transformation to it,
providing the level of design necessary to bring the solution "into the
physical"

=20

Second, what sorts of roles exist at the levels?

=20

Conceptual/Science - domain expert, subject matter expert, financial
backer, evangelist, decision maker, PR, marketing

Logical/User - domain expert, analyst, technical writer, modeler,
quality assurance

Physical/Technical - analyst, technologist, software architect,
programmer

Umbrella (existing at any level or step) - administration and project
management along with the broader public community who might provide
useful input/feedback aligned with their interest and knowledge

=20

Third what are the deliverables?

=20

Conceptual/Science - Charter or mission statement, high level
requirements, statement of problem or opportunity

Logical/User - Specifications, functional requirements, test
specifications, manuals

Physical/Technical - Schemas, models, code, test implementations,
examples

Umbrella - mailing list discussion, milestone/review/candidate releases
of documentation and schemas/models, web site, communications, meeting
and conference plans, "real world" examples or implementation links

=20

While the above perspectives expressed in three levels of abstraction in
no way pretend to represent the state of the art of development
processes, they can help us in providing some shape to the expression of
a process for PSI standards work.  Given the bespoke philosophies and
principles, the next step will be the publishing of an actual process
definition we can use to guide the workgroup's activities.  Because our
group is comprised of a wide variety of backgrounds and experience, it
was appropriate to "get on the same page" conceptually, prior to the
actual definition of our process.

=20

Regards,

=20

Kent

=20