click to enlarge

S. Lohmann, S. Dietzold, P. Heim, and N. Heino. A Web Platform for Social Requirements Engineering. In Proceedings of Software Engineering (SE), pages 309–316, 2009.

When a software project involves a large number of stakeholders, participants often resort to using e-mail, instant messaging, and face-to-face meetings along with traditional requirements engineering (RE) tools. While these additional methods provide a convenient and less formal collaborative environment, they also result in intraceable requirements.

The authors developed a web-based RE wiki tool that keeps a history of changes for each collaborative activity. The user-friendly interface and browser accessibility ensure that the stakeholders will not feel the need to use an alternative means of communication.

The tool enables participants to add a new requirement or modify an existing one. They can also assign descriptive tags to the requirements, but to avoid ambiguity or repetition, a definition must be entered for each tag.

Stakeholders have the ability to comment on, rate, or vote for a certain item, features designed to help determine the significance of each requirement. However, instead of rating the idea, participants often rate the quality of the description itself. This skews the ratings, and therefore requirements should not be prioritized based on the final scores.

The system largely relies on its users to moderate the content. With regulation levels kept low, the resulting wiki could be an endless web of incomplete and/or inaccurate requirements. However, as this software has not been evaluated, its impact and effectiveness are yet to be determined.

Peng Liang, Paris Avgeriou, Keqing He, Lai Xu. “From Collective Knowledge to Intelligence: Pre-Requirements Analysis of Large and Complex Systems”. Web2SE ’10, May 2-8, 2010, Cape Town, South Africa

Traditionally, software requirements are communicated through documentation. This approach has been shown to be insufficient when the number of the stakeholders is unpredictable, such as in web-based systems.

When a large number of geographically dispersed stakeholders are invilved, requirements engineering for complex systems can be a challenging task. As with most social collaborative activities, differences in opinions and expectations arise, causing ever changing requirement statements. Large-scale system stakeholders often face incomplete or contradictory specifications.

In this paper, the authors point out four major challenges in the pre-requirements analysis phase: requirements communication, negotiation, traceability, and change control. They propose a solution that utilizes Web 2.0 tools and technologies such as wikis, tags (folksonomies), and semantic web (ontologies).

Functional requirement tagging is the first step in this collaborative process. Stakeholders are asked to assign a content or meta tag to each requirement statement. Content tags are used for the domain specific classification of statements, e.g., invitation and email. Meta tags are used to specify domain independent properties such as high priority. These collaborative tags are then refined and transformed into formal specifications.

As pointed out by the authors, this approach comes with several limitations, such as inconsistency, ambiguity, and redundancy. Stakeholders have the ability to create their own tags, and hence the same item can be labelled as letter, invitation letter, or invitation. These tags then need to be merged or grouped as appropriate, and depending on the number of stakeholders involved and tags crated, it could turn out to be quite a tedious, costly task.

Free/Open Source Software Development: Recent  Research Results and Emerging Opportunities

Author

FOSSD – community intensive approach to development of software systems and related artifacts and communications are openly accessible and publicly availavle on the web.

Free software – social movement. Licensed with the GNU General Public License.

Open Source – software development methodology, may not be free software.

Free software is always available as OSS, but OSS is not always free software.

FOSS developers re typically also end users.

Beliefs:

- freedom of expression and freedom of choice

- what to develop or work on

- how to develop

- what tools to employ

- when to release work products

- what to review and when

- what to be said and to whom without reservation

Motivation:

- self determination

- peer recognition,

- project affiliation or identification

- self-promotion

- belief in the inherent value of free software

Size matters:

FOSS systems co-evolve with their development communities. The evolution of one depends on the evoltion of the other.

FOSS project with a small # of developers (typically one) will not produce and sustain a viable system unless/until the team reaches a larger critical mass of 5-15 core developers. (not true in traditional SE)

The Metropolis Model: A New Logic for Development of Crowdsourced Systems

Definition

Crowdsourcing — the popular term for commons-based peer production

Two types of crowdsourced systems: community-based service systems (CBSS) and open sourced sotftware (OSS).

Businesses are shifting from a “goods-dominant” view, in which tangible output and discrete transactions are central, to a servicedominant view, in which intangibility, exchange processes, and relationships are central.

Eight characteristics of crowdsourced systems:

Open teams – Linux, Apache, Wikipedia

Mashability – the consumption of software by one person or project does not make it less available for consumption by another (Linux)

Conflicting, unknowable requirements – requirements in a crowdsourced system emerge from its participants operating independently

Continuous evolution – small, frequent releases and tight integration with users.

Focus on operations – (as opposed to development and maintenance). Must be reliable and accessible as a public utility, no downtime.

Sufficient correctness – “perpetual beta”, ongoing incompleteness

Unstable resources – built by volunteers. Work is not assigned; people undertake the work they choose to undertake

Emergent behaviors -  seller boycott on ebay (as opposed to deterministic behavior)

Principles:

Crowd engagement and egalitarian management of open teams -

OSS: there is no project plan, schedule, or list of deliverables. Voting process, but only after first proving themselves in development, debugging, and design.

CBSS: approval rating from their peers. The crowds thus assume administrative, promotion, measurement, and asset-protection responsibility.

Bifurcated requirements -

For example, the requirements for Wikipedia’s wiki are totally unrelated to the requirements for Wikipedia’s content.

Kernel service requirements: little or no end-user value (ex. Facebook application platform)

Periphery requirements: majority of end-user value (ex. Facebook applications)

Bifurcated architecture -

The kernel provides the means for achieving and monitoring quality attributes (such as performance, security, and availability).

Lack of specification permits unbridled growth and parallel creation at the periphery.

Fragmented implementation -

OSS: Developers are working only on things for which they have a real passion. The periphery develops at its own pace, to its own standards, using its own tools, releasing code as it pleases

CBSS: developers contribute their own resources and adhere to no deadlines but their own.

Distributed testing -

Kernel must be highly reliable and highly controlled (slow to change)

The reliability of the periphery is indeterminate; sufficient correctness is the norm

Distributed delivery/maintenance -

Kernel must be stable and when it does change must be backward compatible

Periphery – Gradual and fragmented change is typical and expected

Ubiquitous operations -

upgrades are not ubiquitous; ultra-high availability; backward compatible; scale with the number of users

Implications:

Focus on crowd management -

management must focus on communication, negotiation, and leadership to guide developers and content creators, persuading them to share in the vision of the project.

Separate kernel and periphery.

Change the requirements process -

Req’s asserted by the periphery, typically through email, wikis, and discussion forums. Creating a community.

Increase attention to architecture -

Tthe architecture cannot “emerge,” as it often does in traditional life-cycle and agile models.  It must be designed up-front by an experienced, motivated team focusing on modularity to enable the parallel activities of the periphery and the kernel’s core quality attributes (such as security, performance, and availability).

A lead architect or small team of leads should be assigned to manage project coordination and have the final say in matters affecting the kernel.

Most important is that the kernel be highly modular, allowing a project to scale as its community grows.

Plan for distributed testing -

The project should focus on explicitly taking advantage of the “many eyes” to constantly scrutinize and test the kernel.

Does not imply that all aspects of a Metropolis project are thoroughly tested, only that the kernel is.

Create flexible automated delivery mechanisms -

Delivery mechanism must tolerate older versions, multiple coexisting versions, and even incomplete versions.

Plan for ultra-high availability operation -

Ultra-high reliability of the kernel and its infrastructure while paradoxically accepting the fact that periphery software often fails.

Avoid any form of centralized critical resources or centralized control— people or computation—as they are potential single points of failure.



David M. Hilbert and David F. Redmiles, 2001. Large-Scale Collection of Usage Data to Inform Design. Human-Computer Interaction – INTERACT’01: Proceedings of the Eighth IFIP Conference on Human-Computer Interaction, Tokyo, Japan, pp. 569-576.

Traditional usability and beta testing techniques have many limitations. Usability testing restrictions are related to the scope of functionality being evaluated, the size of the evaluation group, and the fact that users are not in their typical work environments. During beta testing, users often fail to report bugs, thinking that they are part of the design.

Software developers need to be able to determining the impact of a certain bug on the overall usage, and apply that information to manage development resources. However, these answers cannot be achieved via usability and beta testing.

A developer’s notion of usage expectations might not necessarily match with the actual user behaviour. The authors created an automated data collection tool which instantiates tracking agents every time an application is started. Agents compare the user’s behaviour to the developer’s expectations. The user is notified of each mismatch and prompted to provide feedback.

The automated data collection approach has been tested in three different environments: The Department of Defence’s cargo in transit application; The Bridget phone-service system; and Microsoft’s word processing software.

The new tool enables developers to answer questions such as “How often do users do X?”. However, the Microsoft experiment could not be completed as planned since modifications in the data collection mechanism required changes in the application itself, which was costly. Moreover, it is not obvious how the automated monitoring system captures bugs. Users are provided with a feedback box only when their behaviour differs from what was expected.

The CAS University Days workshops held by CAS Research Staff Members at IBM aim to showcase recent research initiatives. This is my summary of Tuesday’s Smart Interactions workshop.

A New Tool for Exploring High Dimensional Tables (Ian Spence, University of Toronto)

Given my experience in the field of Business Intelligence development and reporting, I was looking forward to this talk hoping I’d see some of the major obstacles being removed with the new tool.  They’ve implemented a really neat feature:  ability to display mini-graphs inside a cell in a table. I have not seen this feature anywhere else before, and I thought it would be useful in some scenarios. However, I’d imagine graphs would allow only single-level of drill-down, which often isn’t enough. Other than that,  judging by the short demo that was presented to us, I couldn’t really see additional benefits of using the tool as opposed to one of Business Objects’ or IBM’s Cognos solutions.

Evaluation of Smart Interaction Scenarios in the Emergency Room (Erin Yu and Ryan Kealey, University of Toronto) &
Smart interaction to detect and prevent delirium among older ED patients (Dr. Jaques Lee, Sunnybrook Hospital)

I found these two talks closely related as they both dealt with the problem of integrating systems that are currently in use within the ER department. According to Dr. Lee, he spends 23% of his shift searching and waiting for information. Different patient results are stored in separate systems, and each require their own log-on credentials. These systems are currently not aware of one another. Erin and Ryan are working on developing a solution that will be able to query all medical record databases via a single log on. This system is also a two-way communication channel as it automatically sends updates and notifications to the medical staff. This is where the smartness factor of the new system comes into play. Determining what the appropriate interruption frequency is, as well as timing, is a challenging problem. This also ties back to Dr. Lee’s talk. The ER department currently has no way of tracking when each patient last drank a glass of water or took a walk (these activities are crucial for preventing delirium among elder patients). One of the options he talked about were smart devices that monitor patients’ motion, and hence have a way of notifying the staff if they haven’t moved out of the bed for over 6 hrs. However, this gadget was too large to be sewn onto the gown, and wearing it as a ankle bracelet didn’t sit right with the patients.

Social Commerce (Daisy Tan, IBM) &
eCommerce customer Smart Interactions requirements  (Yumman Chan, IBM)

These two talks tackled the importance of user communities within e-commerce services. Shopping websites are no longer a one-way street, they’ve become  information portals where users can rate and share information about the products being offered. In the past two years these communities have taken an extra step forward with Facebook Connect. It has opened up a whole new collaboration platform with the following added benefits for the user:

- single log-on feature, no need to register for each service separately.
- linking commerce account with facebook accounts and synching with facebook news feed.
- sharing reviews with friends and receiving reviews from same (trusted sources)
- content filtering based on facebook friend list and preferences

The overall goal is to seamlessly integrate collaborative platform (eg. facebook) and e-commerce transaction engine. Benefits for the seller include:

- User Identification (tracing users, monitoring the activity)
- Targeting of customers based on their social participation (lurker, participant, power reviewer)

Using RFID-Enabled Mobile Phones for Enhanced Context Awareness (Hao Shi, University of Toronto)

activity = role + time + location

Hao talked about the use of radio frequency identification to help hand held devices become context-aware. Imagine your car unlocking automatically as you approach it, without having to press any buttons. Smart devices would be able to measure distances between objects and hence make decisions based on their locations. The wave of the future?!

The Role of Social Media in Software Engineering (Margaret-Anne (Peggy) Storey, University of Victoria)

I found this talk to be one of the most interesting as the topic fits within my research interest. I’d like to write a separate blog post on the topic, and I’ve asked Peggy to email me the presentation slides to use as a reference. Check back soon for the update.

Paper: The Development of Successful On-Line Communities by Karen S.K. Cheung, Fion S.L. Lee, Rachael K.F. Ip, and Christian Wagner

Abstract

This paper explores the design characteristics that define successful virtual communities.

Definition

On-line virtual communities are social aggregations. They provide an interactive environment where people form personal relationships and share member-generated content.

Characteristics of On-line Communities

motive, cardinality of interaction, source of content, autonomy.

1. Motive
- relationship building and mutual emotional support (comfort groups)
- information/knowledge exchange
- transaction oriented, economic interests (ex. amazon.com)

2. Cardinality
- one-to-one (private chat room, used in communities based on relationships)
- one-to-many (hubs, one party is the main focus point of all communication. Examples include one seller – many buyers, or celebrity websites. Difficult to sustain when the community grows.)
- many-to-many (discussion)

3. Content
many contributors vs. single (wiki, blogs…). Host, horde, or interaction based content.

4. Autonomy
coordination between community members – independent to highlt integrated communities with well-defined rules of collaboration.

Communities

Principles for developing and Maintaining Successful On-Line Communities

1. Many-to-many exchange.
Communities need to be built as networks. Company websites lose their value as an information exchange forum, while community forums are blossoming and freely exchanging product information, good or bad.

2. Strong champion to build the community
A founder that drives the development and encourages others to participate. Needed to propel the community through its initial growth phase. Administrative role.

3. Build around a need and with social capital
Valuable interaction between members mandatory.

4. Provision of rules and regulations
Administration, expected behaviour. Clearly state and enforce the rules.

5. Critical Mass
Critical mass may imply that there are enough writers to produce new material, but also enough readers so that writers feel their contributions are worthwhile.

6. Community role and membership life cycle
Uneven participation, 30:1 read to write ratio. Participants fall into three different categories based on their role in the community:
I) Functional – thought leader/expert, acrive member, administatir, soul of the team
II) Neutral/Undetermined role – lurker, silent participant. 90% of members are lurkers.
III) Dysfunctional – advertiser, cynic, troll, manipulator.

7. Community stages of development
Community development life cycle: initiation, growth, maturity, decline, dissolution.

Lessons

The primary reason for people to join a community is that they have a shared goal, interest, or need.

It is important to have flexible mechanisms to foster continuity and growth of the communities in response to the changing needs of the members.