Collaborative Ontological Design of a Web Portal

8/11/2019 Collaborative Ontological Design of a Web Portal

http://slidepdf.com/reader/full/collaborative-ontological-design-of-a-web-portal 1/7


http://slidepdf.com/reader/full/collaborative-ontological-design-of-a-web-portal 2/7Electronic copy available at: http://ssrn.com/abstract=1982707

of the requirements and the taxonomy of eachdimension from the requirements, the collaboratinggroup can encapsulate and extend the requirementsusing an ontology [4].

Thus collaborative design using an ontology can be a tool in Collaboration Engineering [5], for“collaborative learning of design” [6, p. 170], and“architectural decision capturing” [7, p. 15]. Theentire ontology, the dimensions, or parts of thetaxonomies of each dimension can be used in“recurring collaboration tasks”. [5, p. 611] Similarly,the dimensions of the ontology, the taxonomy of eachdimension, and the ontology itself are design patternswhich can be reused [8]. They can also provide focusfor generating inquiry and synthesizing knowledge.The method will allow the designers to “integrate

both ontological (top-down) and discursive (bottom-up) approaches to knowledge elicitation andstructure” [9, p. 672] in designing a system. Aboveall, a major advantage of the method is that it can beimplemented on paper or using simple tools like aspreadsheet.

We describe the collaborative development of anontology for designing a web portal as part of asystem development life cycle. Starting with the

problem statement of the sponsors, we discuss theinduction of the ontology from the requirements andthe articulation of the ontology in wireframes for thesystem. Subsequently, we describe the multiplemethods of external and internal validation of theontology. We conclude with a discussion of futureapplication of the ontology and recommendations forimprovement.

The method can be used to generate a natural-language based, concise, and comprehensive map ofthe system. The map is modular and parsimonious,can be scaled to different levels of granularity, andadapted to the desired scope. In the following we willdescribe the method for systemically andsystematically modeling the problem of web portaldesign collaboratively using an ontology.

2. Designing IT Projects’ Status WebPortal

The objective of the project was to design an

integrated SharePoint portal to provide informationabout all the IT (Information Technology) projects ina large reinsurance firm’s risk solutions division.This portal aims to communicate project statuses andupdates between IT teams and internal clients easily,thus acting as a common platform for increasedtransparency. Many stakeholders including businessusers, IT users, and vendors need periodic updatesabout project outcomes and status. Currently, most of

the projects manage their own individual SharePointsite; the CIO and internal clients get status updatesvia ad-hoc e-mails and phone calls. Thus, for the

portal to deliver its intended business value there wasa need to determine in detail the information entitiesto be captured and presented, and ensure a consistenteasily updatable and navigable design.

This case study describes the use of ontology forcollaborative conceptual modeling to design anintegrated SharePoint portal. There were many typesof collaborations: among the design team members,the team and the sponsors (Business Analyst andCIO), the team and the developer, and the team andthe users. Collaboration was vital because manydifferent users are involved and incorporating theirdiverse inputs and that of other stakeholders wasnecessary for a successful system design. The projectfollowed the Software Development Life Cyclemodel – requirement gathering and analysis,conceptual modeling, data modeling, design of the

portal, and implementation of the design.Initial information requirements obtained

through a questionnaire sent to a broad user grouphelped determine the conceptual model. This initialmodel both facilitated detailed requirementsgathering from users, and was itself further refinedthrough discussions with users. The model,developed collaboratively, captured the full set ofinformation entities and granularity of interest to thediverse user group, and helped establish systemscope. It was also useful in validating applicationneeds and understanding processing and userinterface concerns from the users’ standpoint. A key

advantage, at this stage, arises from requirementsdiscovery that the conceptual model facilitates. In providing, from a users’ viewpoint, a comprehensive picture of the full information set, it fosters a broaderconsideration of scenarios than users might otherwisehave thought through.

The conceptual model, with its comprehensivecharacterization of varied information needs, thenformed the basis for the data design. Note that theontology, representing a high level conceptual viewof information requirements, is not intended for oramenable to any direct or automated translation fromontology to data schema, etc. Rather, it allowedanalysts to develop a data design considering the fullrange of user interests. The conceptual model alsofacilitated an effective user interface design, throughcollaborative consideration of information

presentation and interaction requirements of diverseusers.

337



3. Development of the Conceptual Model

The conceptual model presents a comprehensiveview of the information available/required about

projects, the varied needs of many stakeholders, aswell as the different information and reporting

requirements of the users. It helps identify the mostrelevant pieces of information from the standpoint ofa diverse set of users. Thus, a subset of the model can

be carried forward in the design of the portal. Theinformation can be viewed at the required level ofdetail and can vary for different users. Theconceptual model can thereby help define the datamodel, as well as the user interface, and also thereports most suitable for the needs of different users.

3.1. Requirements Gathering and Analysis

An online survey was conducted by the teamrequesting users to state their informationrequirements from the portal in general terms.Following the survey, the team interviewed some ofthe identified end-users, in person and/or viaconference calls and discussed their informationrequirements in detail.

Based on the survey and interviews, end-userswere classified into six different groups, each with adifferent set of information requirements: FinanceExecutives, Business Executives, IT Executives, ITProject Managers, IT Business Analysts, andVendors. The survey data showed that the end-users’needs varied with regard to: (a) information entities,(b) type and granularity of information about theentities, and (c) frequency of interaction with theinformation. The information entities werecategorized as Business Units, Programs, Projects,and Activities; Projects were further categorized

based on their budget approval status as Approved,Requested, and In-pipeline. Information about theentities required by users was broadly categorized as:Business Case, Financials, Project Plan, Complianceand Strategy Initiatives, Global Initiatives, MajorActivities List, Contact List, Calendar, Updates, andAnalysis. Many of these categories were furthersubcategorized resulting in a three-level taxonomy.Last, the desired frequency of interaction was

categorized as Weekly, Biweekly, Monthly,Quarterly, and Annually.

3.2. Conceptual Modeling

The above requirements were encapsulated in anontology as shown in Figure 1. The taxonomies in thefour columns from left to right represent the

information entities, frequency of interaction, typesof information, and users respectively. A requirementcan be derived from the ontology by concatenating acategory from each column with the words/phrasesadjacent to the column. Two illustrativeconcatenations are shown at the bottom of the figure.The ontology represents all possible requirements ofthe proposed portal, and can include the ones notspecified in the interviews with users. Some of thelatter, although not articulated, may be relevant to thedesign; discovering and validating them were key tothe effective design of the portal.

Business users found theinformation/requirements presented in the ontologyintuitive and easy to understand, without needlesstechnical detail. Moreover, the ontology capturesenough details for SharePoint developers to helpderive the data model design from it. The CIO foundit useful to view the comprehensive set ofrequirements without being overwhelmed with thedetailed technical specifications, as is typical in atraditional modeling approach.

4. Application of the Ontology

4.1. Data Modeling

The ontology can be readily used in defining thedata requirements for a portal. The database schemaand data definition are an important part of a portaldesign and this is managed in SharePoint using lists.Every list in SharePoint acts as a database table andevery column name in the list corresponds to acolumn in the database table. The componentsdefined under the “Information Type” column in theontology were directly mapped to tables and columnnames with varied data types. For example, the“Business Case” information type can be aSharePoint list, with “Executive summary” as adescriptive text field, “Value to the firm” as acategorical field, or “Budget” as a numerical valuefield for the “Financials” list. Also, complexinformation like “High level timeline” can be handledas a Gantt chart list for “Project Plan” informationtype.

4.2. Design

The team created wireframes for the portaldesign on the basis of various project componentsdefined in the ontology. The wireframes depict thescreen design of various portal pages. An example ofthe Business Case (a business case captures thereasoning for initiating a project or task) view is as

338



Figure 1: Ontology of Web Portal Requirements

339



shown in Figure 2. The wireframe has various fieldslike Summary, Business sponsor, Driver, BusinessUnits impacted, etc. directly mapped from the“Business Case” Information Type in the ontology.Similarly, the “Financials” information type can bemapped to another wireframe. The ontology alsohelped the design team refine these generic userinterface or information views as per needs andconstraints for different users. For example, the“Financials” view should only be visible to the“Finance Executives”, “IT PMs” and “IT BAs” usergroups defined in the ontology. The ontology thushelped the team design the wireframes for the portaleffectively and efficiently.

While validating the user interface design, theontology helped end users develop a betterappreciation of the information they need on the

portal. The ontology along with the wireframeshelped users realize the full set of information thatcan be made available to them through the portal.This is particularly noteworthy, given that end users

are often unable to articulate precise and completerequirements, especially for new systems; theconceptual model in the form of ontology facilitateda more complete analysis of requirements.

If the ontology had not been used, therequirement gathering and analysis as well as thedesign phase would have involved multiple back-and-forth iterations for information captured amongstthe design team and the different end users. This isusually time-consuming and it is nearly impossible toobtain a complete set of requirements with all theusers on the same page literally, as has beendemonstrated with a single-page ontology.

5. Validation of the Ontology

The ontology was validated in a number of ways both internally and externally. The first validationwas the ability of the team to satisfactorily fit thedetailed requirements from the surveys and

Figure 2: Wireframe of the Business Case View

340



interviews on to the ontology. This is the equivalentof assuring the content validity and the face validityof the ontology.

The approval from the sponsors was a secondsource of validation – external validation. They foundthe ontology to be a new and useful way of

presenting information and requirements. To quoteone of the sponsors: “I thought it was extremelyhelpful. I have not seen it put that way before, so itwas nicely laid out and easy to understand. I believeit can be applied to multiple projects and I think itwas helpful in the sense that it was able to provideyou with the framework for the requirements.”

The approval from the technical support personwas the third source of validation, again external. Hewas able to relate to the ontology immediately interms of the database model.

The approval from peer project groups doingsimilar projects was a fourth source of validation,quasi-external since they were part of the samecourse. They found ontology to be a useful conceptand a presentation device. It provided a convenientway to depict comprehensive informationrequirements from different analysis points of view.They felt that the ontology could lead to morecomplete specification of the requirements andeffective design.

Last, the approval from broader group ofindustry professionals who were presented the projectat a Student Project Expo was the fifth source ofvalidation, external. The visitors’ attention wasdrawn towards ontology because it was somethingnew and different to them, they asked questions and

sought explanations, and generally appreciated how itcould be useful to represent and ensure a complete setof requirements.

6. Conclusions and Recommendations

The ontology is a comprehensive, concise,robust, and extensible framework for collaborativeconceptual modeling of a web portal on a sheet ofletter-size paper. We have demonstrated how it wasused by the team members to collaborate with eachother, and for the team to collaborate with thesponsors and the users to integrate and map their

requirements systematically. Through the case, wehave also demonstrated how the ontology can be usedto specify the requirements of the system at differentlevel of details; additionally, the granularity of therepresentation can be varied based on need. Further,we have demonstrated how it can be used to designthe portal by deriving the wireframes from it. Theabove mentioned flexibility and extensibility allowsone to map the wide ranging requirements of users by

incorporating the appropriate categories anddimensions - if a category is excluded from thetaxonomy, it can be added with little perturbation.Overall, we believe that the method is generalizableand repeatable.

The ontology was validated internally andexternally from multiple sources. The applicationcase study presented here, however, did not involvefurther steps for quantitative validation. While it is agood beginning, and adequate for the purposes in thisapplication, in the future it may in general be usefulto validate and expand the ontology for the web

portal through user interviews and designer feedback.Maintaining the ontology by enforcing adherence toit on the one hand, extending or modifying it asnecessary on the other can ensure the continuity andintegrity of the system design. Such an ontology can

be used for deriving the on-going designspecifications, platform integration requirements, andabove all, user validation and approval. With regardto user validation, the ontology has the advantage ofcommunicating the big-picture as well as the details –to see the forest and the trees, to put requirements in

perspective. Last, but not the least, the ontology canmake the design efficient and effective. Efficient

because of the nature of the structure it imposes onthe process, effective because of its natural languageinterpretability. A systematic study of the pros andcons of incorporating an ontology as part of thesystems development process, as highlighted in thiscase study, remains a topic of future research.

7. References

1. Ladkin, P.B., Ontological Analysis. Safety Systems,2005. 14(3): p. 1-7.

2. Ramaprasad, A. and S.S. Papagari. OntologicalDesign. Proceedings of DESRIST 2009, Malvern, PA,USA May 2009. Availablefrom:http://ssrn.com/paper=1335984.

3. Renger, M., G.L. Kolfschoten, and G.-J. Vreede,Challenges in Collaborative Modeling: A LiteratureReview, in Advances in Enterprise Engineering I.2008. p. 61-77.

4. Ramaprasad, A., et al., Collaborative ConceptualModeling Using an Ontology, in Proceedings of 16thCRIWG Conference on Collaboration and TechnologyG. Kolfschoten, T. Herrmann, and S. Lukosch,Editors. 2010: Maastricht, The Netherlands. p. 25-32.Available from: http://ssrn,com/paper=1738616

5. Kolfschoten, G.L., et al., A conceptual foundation ofthe thinkLet concept for Collaboration Engineering.International Journal of Human-Computer Studies,2006. 64(7): p. 611-621.

6. Bravo, C., et al., Collaborative environments for thelearning of design: a model and a case study in

341



Domotics. Computers & Education, 2006. 46(2): p.152-173.

7. Zimmermann, O., et al., Reusable ArchitecturalDecision Models for Enterprise ApplicationDevelopment, in Software Architectures, Components,and Applications. 2007. p. 15-32.

8. Kolfschoten, G., et al., Cognitive learning efficiency

through the use of design patterns in teaching.Computers & Education, 2010. 54(3): p. 652-660.9. Pike, W. and M. Gahegan, Beyond ontologies:

Toward situated representations of scientificknowledge. International Journal of Human-ComputerStudies, 2007. 65(7): p. 674-688.

342

Documents

Collaborative Ontological Design of a Web Portal