1 / 25

1 : The Context

1 : The Context. Presented By: Joe Bolinger 11/3/ 09. Today’s Outline. Why EcoFlow ? What is EcoFlow ? The Concept The Business Context The Software. Why EcoFlow ?. Our purpose Provide an example of a real project Our goals Demonstrate Software Process

koren
Download Presentation

1 : The Context

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. 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-FlowTM 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

  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 ShapeExternal 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 ShapeInternal 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 ShapeInternal 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 ShapeInternal 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 ShapeExternal & 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 ShapeExternal & 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 ProcessRecap • 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 ProcessTwin Spiders • Two sides of EcoFlow

  25. Next Time • Architecture • Questions?

More Related