Difference between revisions of "Inclusive Models"

From wiki.gpii
Jump to: navigation, search
(Functional Views)
Line 121: Line 121:
  
 
== Functional Views ==
 
== Functional Views ==
 +
Below is a UML activity diagram that shows with increasing detail the path within an inclusive ecosystem of a user who has made a request, interacts with the P4A infrastructure, and ultimately is delivered a matching good or service. The figures are shown stepwise from the most fundamental function of making an initial request to a full activity diagram for Handling a Request and Delivering a Match, which shows all of the various functions at work within the ecosystem. The point of this diagram is to show function, not to determine who a ‘user’ is or what a ‘match’ looks like.
 +
We do not know all of the eventual end-users or eventual matches that the Prosperity4All ecosystem will support. We are building an infrastructure to support an inclusive ecosystem that will adapt, grow, emerge, flex, and accommodate diverse and unpredictable use cases and yet unknown users. The UML diagram shows a porous yet complete pipeline of functions that will support this emergence, growth, and change – porous because it is flexible enough to accommodate the unknown and complete because of the fundamental function of providing a match to a request.
 +
 +
=== Making an Initial Request ===
 +
<gallery>
 +
1-uml-initial request.png|Making the initial request
 +
</gallery>
 +
This step shows the most fundamental function of the ecosystem: for a user to make a request and for a match to be delivered. Here ‘user’ should be understood broadly (refer to [[Use_model|Use Model]]) and the “match” should also be understood broadly to represent a need, service, or solution. A match can be fully automated, delivered by a person or any combination along that continuum.  For the purpose of a simple example: A policymaker (user) could enter the system looking (makes a request) for some indication of patterns of unmet needs in the marketplace. The delivery of those metrics would constitute a (match). A developer (user) could enter the system looking for resources (makes a request) to help her put a project team together. The matching of that developer with others who are interested in participating in her project constitutes a (match).
 +
 +
=== Making a Well-Formed Request ===
 +
<gallery>
 +
2-uml-wellformed request.png|Making a well-formed request
 +
</gallery>
 +
A user will make a request and then interact with interfaces and tools that will help her refine that request further. This refinement might happen intentionally (how can I express what I really want?) or might happen as a result of interacting with various tools’ interfaces (fill in the fields to submit your request or enter your project). A request is "well-formed" when it contains complete and accurate information about the user's goal (what needs to be done?), preferences
 +
(what is the best way for me to do it?) and context (what factors influence this?)
 +
 +
=== Addressing the Request ===
 +
<gallery>
 +
3-uml-addressing the request.png|Addressing the request
 +
</gallery>
 +
The infrastructure handles the request by delivering a match. In some cases a match is not found (which then triggers a request to fill a gap). In other cases either a partial match is found (which provides an opportunity for the match to be adapted), or a direct match is found and delivered.
 +
 +
=== Addressing the Gap ===
 +
<gallery>
 +
4-uml-addressing gap.png|Addressing the gap
 +
</gallery>
 +
If a match is not found, a process is triggered to fill that gap. Filling a gap requires recruiting, training and supporting suppliers who could fill that gap and help delivering the required match. The ecosystem will grow and adapt to evolving uses and requests as gaps are filled and the network of suppliers expands.
 +
 +
=== Feedback ===
 +
<gallery>
 +
5-uml-feedback.png|Feedback
 +
</gallery>
 +
Once a candidate match (either partial or direct) is delivered, a mechanism that is built into this ecosystem will allow users to evaluate the delivered match. This evaluation will be delivered to the suppliers who contributed to the match. It will also be delivered to the P4A infrastructure to help refine the services and tools that enable users make well-formed requests – to further grow, refine, and adapt the system and the matches to meet the needs of diverse users and use cases – to diversify.
 +
 +
=== P4A Activity Diagram ===
 +
<gallery>
 +
6-uml activity diagrams.png|P4A Full Activity Diagram
 +
</gallery>
 +
This image shows the full activity diagram for Handling a Request and Delivering a Match, which shows all of the various steps above at work within the ecosystem.
  
 
== Tools ==  
 
== Tools ==  

Revision as of 21:23, 11 February 2016

The infrastructure teams are asked to explore their practices and assumptions, note where they are falling into the ruts or misconceptions outlined in the misconceptions table below, and explore the design and economic models from SP1 to adapt their processes to achieve greater inclusion. A key part of the SP1 models is a loop of continuous feedback that leads to refinement of the models to ensure they better address the needs of the infrastructure teams while solving complex problems for unique users.


Overview of SP1 Work

The main objective of this page is to provide the infrastructure teams with a brief and clear description of the SP1 design and economic models and their applications. The chart bellow provides a high level demonstration of SP1 work; detailed information regarding the misconceptions, big picture and UML diagrams are presented in the following sections.

Complex System Framework

The ‘Misconceptions’ table contrasts the typical approaches (in various domains) that have failed with new ways of thinking and doing that are driving the paradigm shift needed for making the vision of P4A possible.

Domain Old Way of Thinking/Doing : Misconceptions & Ruts New way of Thinking/Doing : Paradigm Shift Tools and Methods
Development & Design
  • Isolated (stand alone functions) work packages that snap together when completed
  • Require responsive system in quickly changing context with undefined and expanding scope
  • Functions are entangled and interdependent
  • Need built-in ability to incorporate early trial, error and feedback by users and iteratively respond to this
  • Be flexible and porous
  • Create conditions for growth, new uses and connections
Project Management
  • The roadmap can be predicted and controlled
  • We can know the problem and create a solution
  • Can be solved in a standard, linear manner
  • We can control this and predict requirements
  • There is an end point when the project is complete and we have succeeded
  • This is a complex project and so adopting a ‘complex project management’ approach is appropriate (inspired by system of systems )
  • require ongoing transparent communication
  • Emergent systems cannot be *known* and planned in the same way
  • “Success” continues to evolve and change
  • D404.1 for more information
Users
  • Working from deficit model of disabilities
  • We can create persona categories that represent most of the possible end users - they have static needs
  • The only end users are people with disabilities
  • The system is built from a perspective of inclusion and one-size-fits-one
  • This ecosystem is built to empower users and break down barriers to access -- regardless of user ability or disability
  • Personae are meant to help model the range of behaviours, not represent full demographics of complex and unique people
Design
  • Inclusive design isn’t necessary or important -- it’s the touchy/feely stuff
  • Inclusive Design is design that is built upon common design practices with additional principles, practices, and tools used for the benefit of all end-users. It’s better design.
  • We are designing for diversity, inclusive design is needed to design for diversity not the mass
Economic
  • Accommodations represent all new costs, but not investments
  • Prosperity is monolithic
  • We need “full social costing” showing macro and long-term impact of investment
  • Prosperity is not just measured as “more money in my pocket”
  • Prosperity should happen (and be measured) at the “micro” and “macro” levels
  • Costing models need to incorporate collective costs taking into account sharing and collective production
Timing
  • Emergence is a quick process - just a state change not an evolving one
  • Emergence will happen through use and feedback and adjustments
Architectural
  • We can engineer a fix - technology can solve it all and we are smart people who know what is best
  • The engineers are not the only ones building this system -- it is designed to encourage feedback and adapt and grow based on end-user feedback and use
  • We are dependent on all users/stakeholders from the demand to supply side of the system for the solutions and guidance for iterative refinement
  • This needs to be self-healing, self-correcting, and self-refining
Market
  • The sustainable business model is just “details” that someone else can work out
  • There can just be one business model that will work
  • Business model is more than just payment systems
  • Solutions need to adapt to users and user context and evolve over time

Infrastructure Enabling an Ecosystem

The diagram above shows the tools that SP1 is delivering for the various infrastructure teams to use as they build the component parts of the P4A. These tools help ensure the project achieves its overall vision as stated above. The Design Kit and Economic Model contain the initial information the infrastructure teams will need to create an inclusive infrastructure that can serve as the backbone to an inclusive ecosystem. The Design Kit includes a Use Model, global and component specifications, and Inclusive Design Guides. The Economic Model contains a business model and payment system analysis. The infrastructure teams are asked to both use and help refine these models as they gain experience and provide feedback on their efficacy and use. The models have been created from within the current context in Europe: namely the combination of the 4 areas earmarked in the EU’s Disability Strategy Goals and the ever-changing ‘verticals of complexity’ that make up Europe, markets, and technology. The SP1 team’s hope is that the various infrastructure teams will keep this larger context in mind and think beyond what is defined as disability and instead focus on breaking down the barriers in each of these four areas while they use the SP1 models to design and develop technologies, and provide feedback. With this feedback loop, SP1 can effectively refine the models to best reflect the needs and contexts of users of P4A while helping the infrastructure teams fulfill those needs with ever-changing complexity.


Functional Views

Below is a UML activity diagram that shows with increasing detail the path within an inclusive ecosystem of a user who has made a request, interacts with the P4A infrastructure, and ultimately is delivered a matching good or service. The figures are shown stepwise from the most fundamental function of making an initial request to a full activity diagram for Handling a Request and Delivering a Match, which shows all of the various functions at work within the ecosystem. The point of this diagram is to show function, not to determine who a ‘user’ is or what a ‘match’ looks like. We do not know all of the eventual end-users or eventual matches that the Prosperity4All ecosystem will support. We are building an infrastructure to support an inclusive ecosystem that will adapt, grow, emerge, flex, and accommodate diverse and unpredictable use cases and yet unknown users. The UML diagram shows a porous yet complete pipeline of functions that will support this emergence, growth, and change – porous because it is flexible enough to accommodate the unknown and complete because of the fundamental function of providing a match to a request.

Making an Initial Request

This step shows the most fundamental function of the ecosystem: for a user to make a request and for a match to be delivered. Here ‘user’ should be understood broadly (refer to Use Model) and the “match” should also be understood broadly to represent a need, service, or solution. A match can be fully automated, delivered by a person or any combination along that continuum. For the purpose of a simple example: A policymaker (user) could enter the system looking (makes a request) for some indication of patterns of unmet needs in the marketplace. The delivery of those metrics would constitute a (match). A developer (user) could enter the system looking for resources (makes a request) to help her put a project team together. The matching of that developer with others who are interested in participating in her project constitutes a (match).

Making a Well-Formed Request

A user will make a request and then interact with interfaces and tools that will help her refine that request further. This refinement might happen intentionally (how can I express what I really want?) or might happen as a result of interacting with various tools’ interfaces (fill in the fields to submit your request or enter your project). A request is "well-formed" when it contains complete and accurate information about the user's goal (what needs to be done?), preferences (what is the best way for me to do it?) and context (what factors influence this?)

Addressing the Request

The infrastructure handles the request by delivering a match. In some cases a match is not found (which then triggers a request to fill a gap). In other cases either a partial match is found (which provides an opportunity for the match to be adapted), or a direct match is found and delivered.

Addressing the Gap

If a match is not found, a process is triggered to fill that gap. Filling a gap requires recruiting, training and supporting suppliers who could fill that gap and help delivering the required match. The ecosystem will grow and adapt to evolving uses and requests as gaps are filled and the network of suppliers expands.

Feedback

Once a candidate match (either partial or direct) is delivered, a mechanism that is built into this ecosystem will allow users to evaluate the delivered match. This evaluation will be delivered to the suppliers who contributed to the match. It will also be delivered to the P4A infrastructure to help refine the services and tools that enable users make well-formed requests – to further grow, refine, and adapt the system and the matches to meet the needs of diverse users and use cases – to diversify.

P4A Activity Diagram

This image shows the full activity diagram for Handling a Request and Delivering a Match, which shows all of the various steps above at work within the ecosystem.

Tools

The infrastructure teams are asked to both use and help refine these models as they gain experience and provide feedback on their efficacy and use.The tools provided by SP1 consist of: