1. CoFM: A Web-based Collaborative Feature Modeling System for Internetware Requirements' Gathering and Continual Evolution Li Yi, Wei Zhang, Haiyan Zhao, Zhi Jin, Hong Mei Institute of Software, School of EECS, Peking University Key Laboratory of High Confidence Software Technology, Ministry of Education of China 2010.11.04

2. Agenda  Motivation  Introduction to the CoFM Method  The CoFM System  Architecture  Production Support  Awareness Support  Coordination Support  Case Study  Conclusion

3. Agenda  Motivation  Introduction to the CoFM Method  The CoFM System  Architecture  Production Support  Awareness Support  Coordination Support  Case Study  Conclusion

4. Motivation  The increasing interest of Internetware  Web services  Service Oriented Computing (SOC)  Service Oriented Architecture (SOA)  Cloud computing  Particularly, the Software as a Service (SaaS) approach in cloud computing has achieved great commercial success in recent years  For example, Salesforce.com maintains a Customer Relationship Management (CRM) application on the Internet and about 70,000 subscribed clients are using this application now.

5. Motivation (cont.)  A significant characteristic of Internetware is that the amount of its potential stakeholders is usually enormous, due to the openness and global availability of the Internet.  Challenges to the requirements engineering  support for gathering, organizing, evaluating, and negotiating requirements from large number of stakeholders.  synthesize the requirements to help Internetware provider identify the most common and essential requirements, to enable the provided Internetware satisfy most stakeholders.  allow stakeholders to track the up-to-moment changes of the requirements, to make Internetware evolve continually.

6. The CoFM System  A web-based collaborative feature modeling system (CoFM) for gathering, organizing, evaluating, and negotiating Internetware requirements  Express and organize requirements in terms of desired features of the Internetware application  Utilize feature models to explicitly model the relationships between the gathered features. The relationships may have great influence on decisions in the later stages of the Internetware development. For example, when making the decision of whether to implement a specific feature, stakeholders should aware that all features required by this feature must be implemented first.  Allow multiple stakeholders to concurrently modify the shared feature models.

7. Agenda  Motivation  Introduction to the CoFM Method  The CoFM System  Architecture  Production Support  Awareness Support  Coordination Support  Case Study  Conclusion

8. Preliminaries: Feature Models from Feature Oriented Domain Analysis (FODA) Feasibility Study, CMU/SEI-90-TR-21, 1990 Feature

9. Preliminaries: Feature Models from Feature Oriented Domain Analysis (FODA) Feasibility Study, CMU/SEI-90-TR-21, 1990 Refinement

10. Preliminaries: Feature Models from Feature Oriented Domain Analysis (FODA) Feasibility Study, CMU/SEI-90-TR-21, 1990 Constraint

11. Extended Feature Models in CoFM +supporters +opponents Relationship Element Feature Refinement Constraint +parent 1 * 1 * +child * * EFM * Name Description Optionality Stakeholder View Global Working Personal Operation CreateVote 1 * 1 1 1 1 Has attribute * 1 1 1.. * ** Key property: divergence tolerance

12. Constructing the EFMs  Broadcasting- based process  Each operation is sent to the central server when submitted  A valid operation is broadcasted to all sites  An invalid operation is undone at its original site

13. Agenda  Motivation  Introduction to the CoFM Method  The CoFM System  Architecture  Production Support  Awareness Support  Coordination Support  Case Study  Conclusion

14. An Overview of the System  A CSCW (Computer-supported cooperative work) system Three main categories of functionalities  Production  Construct, view and check shared feature models  Awareness  Provide necessary information about activities of other people in the shared workspace, which provides the context for individual’s work  Coordination  Mediate and mesh individual work into a whole piece, especially when multiple users are working on the same set of features

15. The Architecture  C/S architecture C Feature Browser Feature Editor Constraints Browser History List User List Discussion & CommentsFeature Model Data Views Name Set Global View Working View Personal View Connector Commands Event Dispatcher Protocol Handler Filters Request Handlers Data Access Objects Database Client Server Controller ViewsModels

16. Support for Production  Key features  Constructing shared feature models via two kinds of basic operations: creating and voting.  Voting on an existing element: ‘YES’ to support its existence in current feature model, ‘NO’ to oppose.  Removing an element if all votes on it are ‘NO’.  Users can add customized attributes to the features in current feature model. (The default attributes are name, description and optionality.)  Checking for conflicts and defects at individual workspaces.

17. The main working page Feature Browser Feature Editor Miscellaneous Info

18. Customize feature attributes  Allow different attributes for different feature models  Four attribute types  Single-line string  Multi-line text  Enumeration  Number

19. Checking the feature model  Where?  At individual workspaces, i.e. each user’s working view and personal view of the shared feature model.  NO checking for the whole feature model (i.e. the global view,) because of the divergence tolerance property of our extended feature models.  What?  Unnamed features  Mal-positioned features Non-positioned Multi-positioned (conflicting refinements)  Conflicting constraints

20. Examples TypeInitialOperationsResult Unnamed FeatureVote NO on the name F Non-positioned Feature (1) Vote NO on the refinement R Non-positioned Feature (2) Vote NO on the feature Parent Multi-positioned Feature (Conflicting Refinements) (None) Conflicting Constraints (None) (Feature F) (Unnamed) F Parent Child R: refinement Parent Child Parent Child Parent 1 Child Parent 2 R1R2 Parent 1 Child Parent 2 R1R2 F1 F3 F2 R1: excludes R2: requires R3 F1 F3 F2

21. Support for Awareness  Awareness support is essential for improving the usability of CSCW systems  Where?  In the CoFM system, most awareness information is shown in the feature browser, because it is the most frequently used UI region.  What?  Others’ current working location  “Hot-spots” in current feature model  Recent changes being made by co-workers  How?  Use different UI elements (fonts, colors, etc.) for different types of information  Make sure these different UI elements can be combined together

22. The awareness information InformationPurpose *Display: Where Display: How Others’ edit location Location (Where are they working?) Presence (Who are participating?) Feature Browser Show people’s name next to the being edited features. ControversyArtifact (What is the state of the objects?) Feature Browser Bold the name of controversial features. ProblemsArtifactFeature Browser Coloring each type of problems. My creationAuthorship (Who did that?)Feature Browser Underline features created by me. Recent changes Action (What are they doing?)Feature Browser Use larger font for recently changed features. Change history Action HistoryHistory Browser List the details of changes. * According to Gutwin and Greenberg’s work: A descriptive framework of workspace awareness for real-time groupware.

23. Example: awareness My Creation Others’ edit location Recently changed feature Recently changed, controversial feature

24. Support for Coordination  Serialized processing and broadcasting The Client SEND (o: Operation) Send operation o to the server. RECEIVE (o: Operation) Update local copy of EFM by operation o. The Server MAIN_PROCESS (loop) p  The first operation in the Operation_Queue. if (p is valid) Execute p on the EFM. Broadcast p. else if (p can be transformed) q  transformed(p) Execute q on the EFM. Broadcast q. else Inform the invalidity of p to its originator. RECEIVE (o: Operation) Put o at the end of Operation_Queue.

25. Operation transformation Original operationWhen it is invalidTransformed it to the following valid operation(s) Create a feature named X The name ‘X’ has already existed in current FM. If X has been used by the feature of the ID F: Vote ‘YES’ on feature F; Vote ‘YES’ on the name X. Create an alias X for some feature The name ‘X’ has already existed in current FM. Vote ‘YES’ on the name X. Create a value V for an attribute of some feature The value ‘V’ has already existed in this feature. Vote ‘YES’ on V. Create a relation RR has already existed in current FM. Vote ‘YES’ on R. Create a relation RR involves non-existing feature(s). (Cannot be transformed.) Vote on an elementThis element does not exist. (Cannot be transformed.)  An invalid operation will be transformed into valid operation(s), if any. The original operation and the transformed operation(s) have the same semantics. Operations that cannot be transformed will fail and be undone at its originator’s site.

26. Agenda  Motivation  Introduction to the CoFM Method  The CoFM System  Architecture  Production Support  Awareness Support  Coordination Support  Case Study  Conclusion

27. Case Overview  An Online Recruiting Management system  A SaaS application  Clients use the CoFM system to propose, discuss and evaluate its requirements in terms of desired system features  Four Participants  Each participant stands for a distinct client  Three hours, 113 features  The participants spend about three hours on the collaborative work, and finally they have proposed 113 features.  The participants confirmed desired features by voting ‘YES’.

28. Results: Collected features

29. Results: Clients’ confirmed features Participant Number of confirmed features TotalCreated by this participantCreated by others P19121 (23.1%)70 P28737 (42.5%)50 P39434 (36.2%)60 P410421 (20.2%)83  By collaborating with others, now the participants work less, but get more.  For each participant, up to 80% confirmed features are created by others and reused by the participant.  The participants report that “it is easier to review an existing feature than to think of a new one,” therefore their work load is reduced.

30. Results: Variability in collected features  This data is helpful to prioritize the requirements

31. Results: Phases of the work 43 82 122 128 117 121 111 120 113 Brainstorming PhaseEvaluation Phase

32. Phases of the work  Brainstorming phase  A large number of features are collected in a short period of time.  Parallel creation happens in different parts of the feature model.  Evaluation phase  The total number of feature changes slightly.  Participants focus on improving and refining raw features Remove redundant features Improve unclear features Find missing features Add constraints between features Confirm desired features

33. Agenda  Motivation  Introduction to the CoFM Method  The CoFM System  Architecture  Production Support  Awareness Support  Coordination Support  Case Study  Conclusion

34. Conclusion  The CoFM system  A web-based platform for gathering, organizing, evaluating, and negotiating requirements in terms of desired system features.  A feature model is utilized to explicitly model the relationships between the gathered features.  Allow concurrent modification on shared feature models by multiple stakeholders.  Statistics of the feature models are presented to help stakeholders make further decisions.  Work less, get more  Collaboration improves stakeholders’ efficiency of work.

35. Thank you!! Q&A