The S Curve

Wikidsmart for OpenStack is Live!

We are proud to announce that zAgile has recently engaged with the OpenStack Foundation to create the Activity Board, powered by Wikidsmart.

OpenStack is a leading open source software platform for building public and private clouds. The OpenStack Foundation drives its evolution and is backed by enterprise leaders include IBM, Cisco, HP, Red Hat, RackSpace, AT&T, VMware, Dell, Canonical, and others.

The development Activity Board for OpenStack provides a visual overview of all the OpenStack public activity of community members across multiple dimensions: contributors and organizations, projects and code-related contributions. From a single interface, you can easily surf OpenStack project content, whether it is coming from the Launchpad bug tracker, Git version control system or Gerrit code review application--all mapped against the OpenStack Foundation members database. 

The intention of the Activity Board is to give the community a way to answer very precise questions like: who’s contributing to that particular project? What is that developer working on? Which commits/changes are related to a particular bug? Who’s joined the development community recently? etc.

And for OpenStack corporate members, an additional benefit you may wish to consider is to integrate your own internal tools with the OpenStack community project content to create your own composite internal dashboard, to provide your teams with instant and precise access to community activity and efforts.   Wikidsmart Context Server’s approach enables you to integrate your tools to automatically build a cohesive view of all content. That means you don’t have to do extensive integration work which can be quite costly to build and maintain.  

If you would like to learn more, we are featuring the OpenStack Activity Board in the upcoming events:

• OpenStack Summit , April 15, Portland, OR: one long session to show the state of the art and to gather feedback

• Webinar, May 2, 9am Pacific Time: Introducing OpenStack Activity Board, A Unified View of OpenStack Project Content 
  

-Sanjiva

A 'Wikidsmart' Project Explorer in Confluence

Since zAgile's Wikidsmart integrates concepts across tools and phases in the software lifecycle, there are a number of ways this integrated information can be leveraged by engineering teams.  Recently, we have had a number of requests to present this information on a confluence page in a tree-like form, analogous to file explorers.   For example, this would allow a tree view of all concepts (version, component, feature, design document, task, test suite, checkin, build, etc.) related to a JIRA project, regardless of where that information exists (Confluence, JIRA, Subversion, Jenkins, Salesforce,...).  The explorer presents the consolidated view of the relationships, much like typical file explorers, such as the Windows Explorer.

We have now developed a widget that can provide this functionality within Confluence.  Its most typical use would be to render all related information about a JIRA Projects.  However, the usage is not limited to any particular 'root' concept.  For example, if you have integrated Salesforce into the Wikidsmart platform, you can see a tree-view of all your CRM Accounts. 

This simple to configure and customize widget macro provides a hierarchical (multi-level) view of JIRA projects and related artifacts, tasks, etc. in the example below.   It supports the following features:

• Customizable -- The root or base concept can be any concept represented in the Wikidsmart knowledge model.  The examples here show root concept as JIRA project.  However, it is possible to have the root as CRM Account, Document or Build, depending upon the context which the page represents.  
• Hierarchical -- execution of the macro will result in the tree-style listing of the root or base concepts.  It will also render the nested relationships in a hierarchy, as specified in the JSON graph.  The logical hierarchy of the example is shown below:

• It can render multiple levels of hierarchical relationships without any constraints, with each level capable of representing heterogeneous concepts 
• It is dynamic and renders all relationships in realtime, as they are established.

 

Here is an example of an implementation of this macro.  It shows a JIRA Project, Features, Components and Test Suites associated with each Project, Stories associated with each Feature, and so on (as shown in the graph above).

 

 

 

To explore this and other features of Wikidsmart, visit the Wikidsmart Sandbox.

 

 You can also download Wikidsmart from Sourceforge.

Confluence 4.1 and Wikidsmart

We have made a lot of progress towards adapting the Wikidsmart smart-forms templates for Confluence to be 'natively compatible' with Confluence 4, leveraging its rich user inteface for creating structured content that can be integrated with other applications and tools, including JIRA, Salesforce, etc.

Since there has been a lot of interest in Wikidsmart for Confluence 4, we thought to provide a sneak peak into what to expect.  The new UI is rich, exciting and inviting.  We are looking forward to the final form within the next few weeks.  

We will continue to provide progress on this towards our goal of releasing the product for Confluence 4 by mid summer.

• The form layout 

 

• The template-based form for structured content entry

 

• The structured page in view mode

-Sanjiva

www.zAgile.com

Atlassian Chats It Up

Kudos to Atlassian for expanding the collaborative and social aspects of the Atlassian suite even further with HipChat. And congrats to the HipChat team for joining Atlassian! Chat is of course a critical aspect to collaboration along with wikis, activity streams, etc. zAgile recognized this as such a few years ago when we integrated the Jabber-based Openfire server into the zAgile Wikidsmart platform.

As always, you can count on zAgile as the Atlassian software vendor partner to contextually integrate Atlassian products. zAgile's Wikidsmart open source platform and applications deliver tight interoperability, traceability, and federated search of content (Requirements, Issues/Tasks, Tests, etc.) across the Atlassian environment, as well as with other tools (Jenkins, Selenium, etc.) and applications (Salesforce.com, etc.). 

And now HipChat's chat history content will be counted among those of course. In this way, HipChat conversations may be automatically tied (via key word/topic association) to issues in JIRA, requirements in Confluence, projects in JIRA, customers in Salesforce.com, etc. No longer will chats remain isolated but can be shared (to the extent desired) and associated with all aspects of the project. 

This means historical chats may be part of the contextual content served to users whenever they are doing something (like creating an issue in JIRA) or performing a search for something. For example, if they are performing a search for a specific Requirement, now they can also see the associated historical conversations along with the associated Tasks/Issues, associated Customers, etc.

The Wikidsmart platform is about teams gaining efficiency and managers gaining insight into the software engineering activities by contextually integrating content and information. Now Atlassian's HipChat's chat history will be amongst that important content to drive collaboration in an ever more contextual way.

@AndrewLampitt
zAgile

Wikidsmart!! Knowledge Management

Wikis have become entrenched in the enterprise as the most common ‘groupware’ application for collaboration amongst individuals and teams.  They are easy to acquire, easy to setup, and easy to use for capturing ad hoc content that teams desire to share amongst themselves.  It is not unusual to find dozens and sometimes even hundreds of wiki instances within enterprises.  Whether it is Human Resources, Sales, Marketing, or IT, teams find ways of leveraging the convenience of wikis to publish and share information with each other.  

While wikis permeate the enterprise, the convenience of capturing information, the ad hoc nature of this information and its lack of structure also contribute to the general failure of the wiki as an effective information collaboration tool.  As the published content grows into hundreds and thousands of pages, it becomes increasingly difficult to organize, maintain, access, and search.  It quickly loses credibility and becomes stale.  Since there is no consistency or discipline with which information must be published or organized, different groups within an organization may experience varying degrees of success with their wiki.  

Traditional wikis also present additional limitations that often constrain their usage as an enterprise groupware application.  These constraints are not a critique of the inherent design of the wiki since it was intended as a simple tool for allowing people to capture information.  We discuss them mostly in the context of the evolution of the wiki in the enterprise.

For example, the page-paradigm for representing content or information does not support ‘formal type’ declaration of specific content in a page or capturing any classification or taxonomic relationship between pages of information.  Rather, it restricts the organization to simple page-level hierarchies.  In multi-dimensional taxonomies, it should even be possible for a page to be represented in more than one classification scheme.  And what about inheritance where information in a page may draw from that already represented in the parent page?  or somewhere else external to the wiki?

Many commercial wikis support information integration from external sources through mashups.  However, the context of such integration is implied based on its location rather than through any formal interpretable relationship with the page where it renders.  There is no inherent capability of dynamically integrating content from external applications based upon page-level context.

Wikis do not support any federation of content.  When there are hundreds of wikis in an enterprise, there is no mechanism for sharing information across them.  Wikis in such scenarios represent team-level and department-level information silos.  

In spite of these shortcomings, wikis have the potential to become an Information or Knowledge Portal within an enterprise and its users demand it.  The emergence of semantic technologies, particularly as applied to wikis (aka Semantic Wikis) has gone a long way to address these gaps.  To further read about the current limitations of wikis and how zAgile’s Wikidsmart semantic technology provides ways of overcoming them, specifically in the context of Atlassian’s Confluence enterprise wiki -- read the whitepaper on Enterprise Knowledge Management with Wikidsmart for Confluence available on Slideshare 

 

Executing JIRA Workflow Tasks from within Confluence using Teamwork 3

Teamwork 3 provides much tighter integration of Confluence with JIRA Workflows using the JIRA XMLRPC API using the zAgile Teamwork plugin for JIRA.   So it is now possible to initiate and interact with JIRA Workflow-based tasks from within Confluence pages and tables.  

However, beyond this user-friendly interaction, the tasks and their states are also automatically linked with the specific entity (Requirement, Test Case, Document, Business Request, Invoice, etc.) in Confluence from where they are initiated (see example below).  

The two-way linking can now provide the users with a friendly interaction with JIRA while achieving full traceability and reporting.  Users  don't need to access JIRA unless they need to edit/update task details.  Since the integration is done using zAgile's zCALM Server, the information may be accessed anywhere in Confluence or JIRA.   For example, you can query the Review Status of a Specific Document or Requirement, or the Test Execution Status of a Test Case using simple queries in the context of the Document, Requirement or Test Case, without having to go to its corresponding JIRA Task.

 

And of course, all of this is highly configurable, since it is accomplished using templates and macros provided with Teamwork.  Visit the Teamwork sandbox to check out this and other features of Teamwork 3.  

Here is how it works:

The screenshot below shows a couple of sample Requirements for Feature (Smart Search) in Confluence.  Each Requirement may have associated Component(s), Stakeholder(s) as well as Review and Development Tasks.  Review Task here is tied to an Approval Workflow in JIRA.  The same can be done for Implementation Tasks.

Product Managers or Business Analysts defining these Requirements above can "Initiate" Review Sessions, and register the resulting outcome (Approved/Deferred, etc.) with the Requirement.  Clicking on the "Initiate Review" Button against the Requirement 2 above will result in the automatic creation of a JIRA Task for Requirement Approval and return the Task link along with its possible next states as shown below.

 

From here, it is possible to take next actions against the Task, without interacting directly with JIRA.  

 

 

I will be speaking at SemTech 2010 - June 21-25 in San Francisco

A Jena-based Framework for Semantic Enterprise Information Integration (SEII)

EII (Enterprise Information Integration) and MDM (Master Data Management) have been the leading strategies in large enterprises for data integration across business functions. Initiatives driven by these strategies have been deployed successfully and proven effective in providing data consistency to business units as well as reducing costs of data maintenance. They also provide powerful analytics and business intelligence capabilities.

Semantic web technologies can offer a powerful complement to EII. Through the implementation of application-specific, collaboration and process ontologies, integration transcends from application data to the semantics of that data. Repositories may be central or federated across the enterprise - but they still provide a unified view of information. This level of semantic information integration may be tool or application-agnostic, domain-specific and easy to implement via a supporting framework.

This presentation discusses a Jena-based architecture for semantic enterprise information integration. This architecture has been implemented to integrate collaboration and tools within software engineering. It is also equally applicable in other areas. The resulting semantic information network can provide unique dashboards to decision makers.

In this session, we will address the following:

• EII versus Semantic EII (SEII)
• Role of ontologies and metamodels in SEII
• A framework for SEII based upon Jena
• Proposed connector architecture for integrating applications and tools
• Demo

 

I will be speaking at SemTech 2010 - June 21-25 in San Francisco

Orthopaedia - A Semantic Platform for Collaborative Knowledgebase Development in Orthopaedics

Semantic technologies have been aggressively applied in biomedical and healthcare domains to address a number of problems related to the representation, interpretation, integration and access of knowledge. These technologies include the development of machine readable thesauri and vocabularies, taxonomies, formal ontologies as well as NLP tools and techniques. And of course, there are emerging applications that are being developed to deal with these underlying metamodels.  

This case study discusses a semantic platform that incorporates these technologies and metamodels towards the collaborative development of a knowledgebase in Orthopaedics. The platform enables users to easily enhance local content with publications from various sources, blogs, discussions, annotations, and automatically tag them with domain-specific terms, as well as make this information accessible across the enterprise to other tools and applications via a semantic repository.

We will also describe the current challenges in achieving coherency and integration across medical subdomains, and describe some the design decisions taken to overcome some of these challenges.

We will address the following points:

• Overview of semantic technologies in healthcare
• Challenges in semantic information integration across resources and applications
• Objectives of the project
• Discussion of technologies implemented
• Review of strengths and weaknesses of the current state of technologies in addressing knowledge management issues in healthcare
• Demo

 

Achieving Requirements Traceability with Confluence & JIRA, the rational (!Rational) way

Requirements Traceability refers to the ability to link requirements to projects, change requests, development tasks, test cases and results, checkins, builds, releases and stakeholders.   In other words - linking requirements with all relevant concepts associated with a software engineering life cycle. Given that Requirements drive the activities across the software engineering projects, maintaining such interrelationships can provide answers to some very critical and business-relevant questions relative to each requirement, whether they are related to business justification, auditing/compliance, delivery management or quality assessment.  

These can be grouped by stages and constituents (some examples below). 

Business Justification:

Who are the Stakeholders of each requirement?

Which requirements are being delivered in a release and for which stakeholders?

What is the business justification and cost of delivering a feature or requirement?

What is the ROI (once the costs are determined)?

Project Management:

Which release will the requirement be delivered in?

What are the risks and dependencies related to the implementation of a requirement?

What is the current state of a requirement with respect to development and QA?

Who signed off on it, who accepted it? 

Which checkins correspond to code complete for a requirement or feature?

Which build includes a particular requirement implementation?

Development & QA 

What are the design goals and motivations of a requirement?

What are the associated test cases and quality goals?

What are the associated use cases or user stories?

In typical engineering environments, some of these questions are difficult or impossible to determine, while others require a significant amount of tedious manual effort.  The reasons can be mostly attributed to the heterogeneity of ALM tools and the lack of integration between them.  Whatever the cause of this fragmentation of information, requirements traceability isn't always optional for organizations. Many expend significant human effort and co$t towards collecting sufficient traceability data to maintain their audit and compliance mandates.  

Traditional ALM vendors provide their own integrated solution set to help their customers achieve requirements traceability.  While they are able to address most, if not all, questions above, you have to invest into their entire portfolio of products and at significant co$ts.  I have rarely seen an engineering environment that has successfully adopted a single vendor solution across teams and departments.  For most part, such solutions end up as shelf-ware, reflecting wasteful and irRational decisions.

It is with this in mind that zAgile delivers its tool-agnostic and open source zCALM platform that is capable of integrating concepts across software engineering life cycle with the tools that you are using in YOUR environment. 

And to take that even further, you can achieve significant amount of requirements management and traceability by simply integrating your Confluence wiki and JIRA issue tracking application via zTeamwork.

  zTeamwork allows you to: 

1. Capture features, requirements, use cases, test cases, test suites, etc. in Confluence in a semi-structured way using zAgile's smart templates.  
2. Link them to each other using pre-defined relationships.
3. Create JIRA tasks, link them to various Confluence artifacts created above, so that you can now associated requirements with use cases, test cases, tasks, and bugs
4. View any and all of these links and relationships (including attributes such as status, completion, etc.) in Confluence or JIRA using simple queries.  There are JIRA properties tabs that may be configured to provide 'dashboard' type contextual views of this information.
5. Search for these specific concepts from within Confluence or JIRA, regardless of where they are created.  The search not only returns the matching result set but also all of the contextual relationships.

Teamwork's integration can be further extended with connectors for salesforce (link customers and cases to requirements and issues within your environment), Subversion (associate checkins with requirements) and CruiseControl (link requirements to builds).  

 With these connectors in place, you can answers ALL of the questions above with respect to requirements traceability -- without having to buy into expensive, complex and painful single-vendor solutions.  

And since zAgile's solutions are tool agnostic, you can also plug other tools on its platform to achieve the same integration capability - via custom connectors.

Somehow that seems more rational than Rational :)

-Sanjiva

Test drive these features in the sandbox

Machine-based semantic annotation of content in Confluence Enterprise Wiki

Annotation of content in any CMS, including traditional wikis, to provide contextual reference to any word or phrase is a common practice.  I am doing that in my blogs as I write.  When I reference specific topics or items, I go through the steps of creating links to them. 

Wiki annotation, therefore, also typically involves highlighting words or phrases and associating each to some reference - an external link or another page within the wiki.   It is a tedious process that involves marking up each word or phrase using specific wiki tags.  It not only requires considerable effort but also a meticulous nature and some dedication towards creating meaningful content.

What if it were automatic?  All you had to do is to add a macro at the beginning of your paragraph or page and everything meaningful within that text would automatically be annotated.

What if it were dynamic, so that the wiki content is still in its original form but all annotations are done when the page is rendered.  The annotation would automatically reflect any changes to the reference.  It would be more reliable and not prone to going stale.

What if the annotation was more contextual to your specific domain, to your business processes and functions, rather than highlighting of people, countries, organizations -- which may have less relevance when the text if referring to some technical requirements for a software component.

And finally, what if the annotation not only provided a link to some reference, but also some information about its type (is it a reference to a Project, a Requirement, a Task, a Bug, a Customer, a Software Component, ...)

Well, that's the capability that we will soon release for Atlassian's Confluence Enterprise Wiki in zAgile Teamwork and Wikidsmart products.

A simple, yet powerful capability in our upcoming release of Wikidsmart (Release 2.0) is the machine-based semantic annotation of wiki content.  It is easier to play with this feature than to describe it to really understand the possibilities that it opens up in making content more meaningful and accessible in enterprise wikis.  But here is an explanation:

By machine-based, I mean all you need to do to enable this capability is to surround the wiki paragraph with a macro (zannotate).

By semantic annotation, I mean that words or phrases in that paragraph that match any reference in our ontology-based semantic repository will be highlighted and linkable to additional information about the references.  Since zAgile Teamwork ships with ontologies for software engineering, you will see annotations of words and phrases that reference instances of Requirements, Projects (JIRA Projects), JIRA Issues, Tasks, Bugs, Software Components, Test Cases, etc.

You can test drive this capability in the zTeamwork sandbox.

Here is what it would look like:

WRITE A PARAGRAPH IN A WIKI AND BRACKET IT WITH ANNOTATION MACRO

SAVE THE PAGE AND THE PARAGRAPH WILL BE AUTOMATICALLY ANNOTATED.  CLICKING ON ANY TAGGED PHRASE WILL POPUP ITS REFERENCE CONTEXT

FOR EXAMPLE, REFERENCES TO JIRA ISSUES NOW ARE AUTOMATICALLY ANNOTATED WITH TYPE, DESCRIPTIONS AND LINKS TO THE INDIVIDUAL ISSUES

AND FINALLY, THE SAME APPLIED TO MEDICAL TEXT - APPLIED AGAINST AN  ONTOLOGY DERIVED FROM MeSH (Medical Subject Headings) THESAURUS, ALSO IN CONFLUENCE - SHOWING HIGHLIGHTED TERM AND ITS SYNONYMS

- Sanjiva

To test drive this feature, visit our sandbox