Presentation is loading. Please wait.

Presentation is loading. Please wait.

1: The Context Presented By: Joe Bolinger 11/3/09.

Similar presentations


Presentation on theme: "1: The Context Presented By: Joe Bolinger 11/3/09."— Presentation transcript:

1 1: The Context Presented By: Joe Bolinger 11/3/09

2 Today’s Outline  Why EcoFlow?  What is EcoFlow?  The Concept  The Business Context  The Software

3 Why EcoFlow?  Our purpose  Provide an example of a real project  Our goals  Demonstrate Software Process  Show how it fits the project  Expose Architecture Examples  Show concrete architecture artifacts  Reinforce the discipline of architecting

4 Why EcoFlow  Today’s Purpose  Introduction to EcoFlow  The Business Context  Why invest in a new application?

5 What is EcoFlow? The Concept  “An innovative decision support tool that helps maximize the financial and societal benefits of industrial ecology – converting waste to profit”  “Eco-Flow TM is the first software tool that couples visual editing of network structures with real-time mathematical optimization”

6 What is EcoFlow? The Business Context  EcoFlow is primarily a methodology of analysis developed by OSU’s Center for Resilience  A standard way of modeling industrial ecology problems  A standard way of engaging multiple industry partners to do the analysis  Initially a Spreadsheet was used to implement the modeling and analysis

7 What is EcoFlow? The Original Software  The Original Spreadsheet  Yes, this is really one page of a spreadsheet!

8 What is EcoFlow? The Organization  Center for Resilience Faculty Directors  Organized industry collaborators to start by-product-synergy networks, raise awareness, publicize results  EcoFlow is just one tool they are using to engage clients  Graduate students  Carried out daily interactions with industrial clients  Collected data, built & interpreted EcoFlow models, discussed results with clients  Acted as a “shield” of some complexity  Sometimes acted as a “buffer” to prevent conflicts or ensure confidentiality among clients that may want some details kept private

9 What is EcoFlow? The Value Chain Broadcasting the results of the Network Alliance to a broader audience, setting an example for the industry, and inviting new business opportunities Network Marketing Implementing changes in business practices to exploit potential synergies for profit, reduced environmental footprint, or other positive results Network Reengineering Applying optimization and visualization techniques to understand the impacts and tradeoffs associated with potential synergies between companies Network Modeling and Analysis Cooperative efforts or the creation of governance organizations that coordinate and nurture relationships between companies with potential synergies Network Alliance Creation and Management

10 What is EcoFlow? The New Software  Limitations of a spreadsheet implementation  Each project required a customized spreadsheet  Time consuming & difficult to customize  Very difficult for industrial clients to use directly  Not visually appealing or captivating to clients  Goals of a new EcoFlow desktop application  Same functionality as spreadsheet  Useable by trained clients with an engineering background  No customization need on a project-by-project basis  Speedup modeling process from data collection to results  More aesthetically pleasing

11 What is EcoFlow? The New Software  EcoFlow Workbench

12 Intermission  Questions?  Next Up  The Development Process

13 2: The Process Presented By: Joe Bolinger 11/3/09

14 Today’s Outline  Watching the Project Shape  External Factors  I can not change  Internal Factors  I can change  Our Goals  Demonstrate Tailoring the Development Process  Introducing the Pattern Approach  Organizational Patterns  Watch for them today, like “this”  Architecture Patterns, Design Patterns  Next time…

15 EcoFlow Project Shape External Factors  People  1 part time developer  Remainder of team also part-time  Most customers are geographically remote  Projects  EcoFlow modeling projects were going on before and while the software was being built  Had to transition between spreadsheet and new software as features were added  Sometimes had to go back and forth

16 EcoFlow Project Shape Internal Factors  Developer “Firewalls” & “Surrogate Customers”  Requirements negotiated with service team internally  Only representative of the “expert” user  Could have sought out more input from “normal” users but deliberately choose not too – for now!  Prevented requirement variability due to specific customer demands  Also lead to some awkward features  For example, tried to satisfy all our targeted customers by designing an encryption feature – even though we know it would seriously limit usability  Disaster!  Threw it out completely in favor of satisfying most customers

17 EcoFlow Project Shape Internal Factors  Shared “Work Queue” or “Backlog” and “Group Validation”  All Stakeholder were very technical in their fields and expected a technically competent team  Also only one 1 developer…  No one wanted to read any sort of plan  Not everyone would actually admit this  we did try at times  Visible work queue of around half a dozen planned features became cornerstone of planning & expectations  Negotiated in person and then re-stated with comments on a Wiki where prototype builds were posted prior to a review  In person group review followed

18 EcoFlow Project Shape Internal Factors  “Implied Requirements” versus a “Smoke Filled Room”  EcoFlow can be split along two major lines  The Interface & User Experience  Developer knew how to design this better (in our case)  The Mathematical Modeling & Correctness of Results  Other stakeholders knew this better  For UI and experience aspects quick discussions of the desired features were favored over detailed requirements discussions  Prototypes were the vehicle for communication  More discussion often lead to strange design  The core modeling & analysis features were hammered out though lengthy group discussions, frequent meetings, and additional design documents  If this was not done correctly nothing else mattered

19 EcoFlow Project Shape External & Internal  Question: Should the external forces drive the internal decisions?  Looks like some did  Geographic distance implies a surrogate customer  Once the “core” functionality was implemented the distance from the customer became more visible  This strategy would probably lead to an “expert-only” implementation if left unchecked forever  1 Developer implies less structured work products  Initially, the stakeholders wanted more design oriented artifacts, like user stories and use cases  But they were never very effective  Why? They are software engineering techniques – not so good for general communication  When? As the team became more comfortable with the use of prototypes they stopped asking

20 EcoFlow Project Shape External & Internal  Question: Should the external forces drive the internal decisions?  Looks like some did  Geographic distance implies a surrogate customer  Once the “core” functionality was implemented the distance from the customer became more visible  This strategy would probably lead to an “expert-only” implementation if left unchecked forever  1 Developer implies less structured work products  Initially, the stakeholders wanted more design oriented artifacts, like user stories and use cases  But they were never very effective  Why? They are software engineering techniques – not so good for general communication  When? As the team became more comfortable with the use of prototypes they stopped asking  One should not drive the other exclusively!

21 EcoFlow Process Artifacts  Example entry on the Wiki’s “Builds Page”  Written by the software developer

22 EcoFlow Process Artifacts  Example design document for a “critical” feature  Written for the software developer

23 EcoFlow Development Process Recap  Very agile with a focus on prototypes  Most valuable activities  Prioritized work queue  Stakeholder feedback using prototypes  More structured design and analysis methods used for “critical” features  This is also where the most domain knowledge needed to be transferred to the developers  Collaborate but avoid over using tools or leaking techniques  Stakeholders may not really know how to design a UI so don’t let them do it alone  Use cases are good techniques for software engineers but poor tools for general communication with stakeholders  Stakeholders drive development but not the process!

24 EcoFlow Development Process Twin Spiders  Two sides of EcoFlow

25 Next Time  Architecture  Questions?


Download ppt "1: The Context Presented By: Joe Bolinger 11/3/09."

Similar presentations


Ads by Google