The Experts below are selected from a list of 71799 Experts worldwide ranked by ideXlab platform
Diffin Jennifer - One of the best experts on this subject based on the ideXlab platform.
-
Library systems documentation: Pulling it together with SharePoint
New Library World, 2013Co-Authors: Diffin JenniferAbstract:Documentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge.Library Systems Documentation: Pulling it Together with SharePoint Introduction Documentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge. Why is documentation so important? Those who claim that documentation is not so important because “anyone in the future should be able to figure out what was done in the past” should “[m]ake that argument to someone who has inherited an undocumented network and watch the response!” (Wilson, 1998, p.100). The goal of documentation is “to keep technology running smoothly and serving the good of the institution” and “includes organizing, collocating, and disseminating the knowledge that will help you and others succeed in your library’s technological environment.” It also provides “a concrete pool of evidence for you to point to in describing the importance of your department’s function to your institution” and “paints a picture of what you have done and of the technological environment that needs supporting (Engard and Gordon, 2012, p. 94).” What needs to be documented? “Think of the information that would have made your job easier and provide it for yourself, your staff, and your successor” (Engard and Gordon, 2012, p. 94). Document “how you do things so that if you have to do them again, you don’t have to start from scratch trying to remember how” (Rossman, 2003, p. 22). This includes configuration information for networks, servers and computers, maintenance procedures, as well as support issues and problem resolutions (Engard and Gordon, 2012). It is also important to establish a method for consistently documenting procedures and decisions (Wilson, 1998). How should things be documented? For common tasks, provide step-by-step instructions and be liberal with screen shots. These will coalesce into “a pool of documentation” for the systems staff (Engard and Gordon, 2012). From a higher level, to organize that pool into an effective portal, it is especially important to develop a carefully thought-out taxonomy, mapping out your sites, content types, and navigation, as well as a governance strategy for its ongoing management (Buckley, 2011). What tools are available? Common tools available in organizations include intranets, shared network drives, shared e-mail folders, help desk ticketing systems, and document management systems (Engard and Gordon, 2012; Lappin, 2010). A centralized portal and a tool that can manage records in multiple formats are desirable (Lappin, 2010). Large-Scale Enterprise content management (ECM) systems exist, but what many organizations really need is a system that provides basic content services (BCS) such as Microsoft SharePoint, which is a dominant player in this field (Pelz-Sharpe, 2008). SharePoint is of particular interest because it provides an integrated portal platform that combines document management tools with Web 2.0 communication and collaboration features, and it is readily available to Microsoft customers as part of the Microsoft Core Access License (CAL) Suite for institutions (Dahl, 2010; Diffin and Nangle, 2011). Wikis and Document Libraries provide a means of collaboratively creating, editing, storing, and managing documents. Many types of files can be stored in the Document Libraries, and SharePoint is designed to work seamlessly with Microsoft Office (Dahl, 2010). Announcement, discussion, and blog tools allow a centralized hub for managing a team’s communications. Calendar and survey tools are also included, as are workflow tools for managing projects and tracking issues (Herrera, 2008). What have other libraries done? In the literature, there are a number of examples of libraries that have implemented SharePoint for documentation and communication. For example, SharePoint has been implemented at Towson University to create a portal for the reference team (“RefPortal”) (Dahl, 2010); at the University of Mississippi to build departmental sites (Herrera, 2008); at the University of Maryland University College for the Document Management Team (interlibrary loan and book delivery) (Diffin et al., 2010b); and at the University of Alabama for instruction requests, reference, and interlibrary loan (Ennis and Tims, 2010). At the University of Mississippi, the library’s Information Technology department has a SharePoint site, and they use SharePoint’s blog for IT alerts and news items and have developed wiki pages for setup and troubleshooting tips (Herrera, 2008). At the University of Alabama, after developing their initial SharePoint sites, the library used SharePoint to create “Help Central,” which functions as a help desk and knowledge portal. It provides a ticketing system for users to report issues, for the staff to track and monitor the tickets, and for solutions to be added to a knowledgebase (Ennis and Tims, 2012). The present article will elaborate further on how SharePoint can be used as a portal for systems documentation, and discuss how a taxonomy was developed, how the actual documentation was written, and some of the best practices that were adopted. Background UMUC Library Systems The University of Maryland University College (UMUC) is a predominantly distance education institution serving more than 97,000 students in more than 25 countries (University of Maryland University College, 2012a, 2012b). Information & Library Services (ILS) relies heavily on technology to deliver library services to students, faculty, and staff worldwide. The Systems Team consists of four librarians: a Systems Librarian, a Digital Services Librarian, an Advanced Technologies Librarian, and a Web Specialist. Each of these librarians has very specialized knowledge, which makes it difficult for anyone else to fill in on those duties. (For the purposes of this article the Digital Services Librarian is being considered as a second Systems Librarian, in that this position also provides technical support for faculty, staff, and students.) The team manages a wide variety of areas, including access to electronic resources, server applications, software installation, cataloging, and the Web site. Other responsibilities include developing multi-media learning objects, in-house databases, and customized programs for the Web site. Before SharePoint Before implementing SharePoint, all of the four team members managed their own documentation. There was a tendency to use the library’s shared network drive (the “S-drive”), but team members also kept documentation on their individual computers and in file cabinets, and much was kept in their own heads. Some procedures were documented; some were not. There was no systematic effort in creating, organizing, and sharing knowledge among the whole team, and there were no best practices. Documentation on the S-drive could be difficult to find and sometimes became outdated. Earlier, some of the staff members had made “Survival Guides” listing where their documentation was stored, and the Systems Librarian compiled a local “Procedures” Web page to try to point to all the various documentation, but none of these were consistently maintained or were ever heavily used. What the team needed was a central portal and more consistent procedures for documentation. Cross-training initiative Since ILS is a small library, it is critical to have training and documentation that allows someone to step in for another person and keep things moving in case of absences due to illness or vacations. The Document Management and Electronic Reserves (EReserves) Teams had recently embarked on a successful cross-training initiative that included using SharePoint for documentation and conducting cross-training sessions between the two groups. To keep the knowledge fresh once the initial training was complete, every member of both teams worked in the other area one day a month. SharePoint was chosen as the collaboration tool because it was designed specifically to manage documents, share information, and facilitate communication. Plus, the UMUC IT department had a license for it and had made it available without the library incurring any additional cost. While other options were considered, such as free, online wikis, none of them had all the functionality offered by SharePoint. Also, these services could disappear or become fee-based at any time, and there was no guarantee that data would be retrievable if the services went down. Knowing that the IT department hosted the secure SharePoint server and that they backed it up daily eliminated the concern for potential data loss (Diffin et al., 2010b, p. 231). The cross-training worked so well that the Assistant Director for Systems and Access Services then expanded the idea to the Systems Team. Using the concepts learned by Document Management and EReserves, the Systems Team began a more formalized process of sharing and documenting knowledge. Implementation Getting started The Assistant Director for Systems and Access Services had some initial meetings with the Systems Team to discuss the cross-training project and to decide how the team would proceed. The main focus of this project would be building the knowledgebase. The UMUC IT Department had created a SharePoint site for the Library, and a Systems sub-site was added. The launch of the Systems site created a sense of community among the team members and officially marked the beginning of the implementation. Site structure As part of the planning, the first priority was to develop the site structure. This provided a fresh start to reorganize the documentation strategically. The structure and hierarchy was mapped out according to the team member functions, including: cataloging, electronic resources, in-house applications, IT (hardware, software, and server management), multi-media learning objects, patron and staff assistance, and Web site management, plus useful contacts. Best practices and conventions Given that the Document Management Team had already “implemented best practices for the wiki so it would have a homogenous look and feel even though several different people were working on it” (Diffin et al., 2010a, p. 575), a member of that team was invited to speak to the Systems Team. He covered the basics of SharePoint’s tools and features and shared best practices on style and visual aids. Verdana was chosen as the text font and standardized sizes were adopted for content and headers. Annotated screenshots were preferred over descriptive paragraphs for concision. Breadcrumb trails would be added to the very top of every wiki page for navigation. Internet Explorer became the preferred browser when updating wiki pages because important formatting features in SharePoint were exclusive to this browser. A consensus was reached that the wiki feature would be used as the main tool for creating, organizing, and sharing documentation because of the following features, as summarized by Diffin and Nangle (2011, p. 136): 1. Editing and updating is easy through the WYSIWYG (What-You-See-Is-What-You-Get) editor. 2. Errors can be quickly and easily undone using version history which encourages collaboration. SharePoint creates a new version of the document whenever any change is made in a document. 3. E-mail alerts inform subscribers of any changes to wiki pages. 4. Permissions can be added to selected pages that contain sensitive information. 5. Visual aids (e.g. screenshots) can be inserted to simplify documentation. In addition, all wiki pages can be distributed and shared via URLs. The Systems Team then came up with documentation conventions for the wiki pages that specified several recipe-style elements to be included as needed, such as background information, tools, how-to steps, and problem resolution. Tools included what the user would need (e.g., software, user IDs and passwords, directories) to complete the documented task. The how-to section included step-by-step instructions with screenshots. Problem resolution indicated things that have gone wrong and steps that were taken to fix the issue. When the rubber hits the road Based on the job duties, the responsibilities for creating content in SharePoint were divided among the four library professionals. The Systems Librarian was responsible for Web sites, cataloging, and IT. The Digital Services Librarian documented electronic resources and provided assistance with Web sites. The Web Specialist worked on in-house applications. The Advanced Technologies Librarian covered the multi-media learning objects. Each member decided on the structure and content within their assigned functional areas while still following the basic agreed-upon guidelines and conventions. The Systems wiki site then started to take shape. Over time, the initial structure was fleshed out considerably, as documentation was migrated from the S-drive or created anew. In some cases, sub-menus were created to refine the organizational structure. For example, the top-level IT page linked to a page called “Server Applications,” which in turn linked to pages on EZproxy, ILLiad, and PeopleSoft. As documents migrated off the S-drive and were converted into wiki pages, shortcuts were provided from the S-drive to the new SharePoint site so that anybody looking for the old documents could get to the new documents quickly. Perhaps more importantly, links were provided in SharePoint to the documentation that still resided on the S-drive, so that SharePoint could effectively function as a portal to all or most of the documentation. The idea was that a user could come to SharePoint and still get to everything, even if some things were still on the S-drive. While Word documents on the S-drive were generally re-done in wiki format, other types of documents (e.g., spreadsheets) were simply uploaded into SharePoint into the “Documents” area. These were organized into subfolders as needed, and were linked to from wiki pages where appropriate. The S-drive would still be needed for certain types of files, such as software installation executable files. Also, documents that were not currently in use but were needed for historical purposes would remain on the S-drive and not migrated. During implementation, monthly team meetings were scheduled to review progress. The members presented their new wiki pages, elaborating on the procedures, policies, and knowledge contained therein. The other team members then had a chance to ask questions about the procedures. For example, one member asked for clarification on how Captivate tutorials were created; another asked for details about updating electronic resources. This cross-training enabled all the team members to become familiar with each other’s work and to know where to look if questions came up during a team member’s absence. After much of the initial documentation was created, team members made an ongoing effort to review and update their pages and met every few months to discuss the updates. They signed up for e-mail alerts to be notified when pages were updated. The Result The home page The Systems home page includes a checklist of important maintenance functions in the center. On the right is a who’s who, indicating which staff have responsibilities for the various areas. At the bottom of the home page is a list of current projects. The site navigation bar on the left contains the menu linking to the top-level functional areas of the wiki. Also included on the navigation bar are standard SharePoint links to “Documents” (the library of uploaded documents, such as spreadsheets), “Pictures” (in this case, the library of uploaded screenshots), and other tools (Calendar, Lists, Discussions, Sites, People, and Groups). 1. Home page Organization The major functional areas, comprising the top-level navigation, are as follows: Cataloging: This includes cataloging and weeding procedures, links to useful documentation (such as MARC standards), and the necessary tools (such as OCLC logins). Contacts: Important contact information for the IT department (including after-hours and emergency numbers), plus other UMUC units and external vendors of vital importance, as well as the after-hours contact information of the library Systems Team members is gathered here. Electronic Resources: Providing technical support for electronic resources includes documentation on setting up, branding, and troubleshooting electronic resources, maintaining the SFX linking service, and obtaining Lexis.com IDs for the Legal Studies program. In-house Applications: This section includes documentation on special processes that were created by or for the library. These include everything from Access and MySQL databases that were created for in-house use, outward-facing systems such as the electronic reserves request system used by faculty, and processes involving external systems, such as the nightly processes that extract patron data from PeopleSoft and load it into the library catalog. IT: This section became a launchpad for a broad range of systems documentation, including equipment inventories, software installation instructions, server applications (such as EZproxy and ILLiad), and IP and domain information. Learning Objects: Documentation in this section covers how multi-media and interactive learning objects on the library Web site were created and are maintained. Patrons and Staff: This section includes tools for assisting patrons (e.g., verifying whether a patron is current), a setup checklist for new employees, how-to pages for library staff (e.g., how to access network printers, tips for using Dreamweaver), plus links to some of IT’s help pages (e.g., about using UMUC e-mail and calendars). Web Site: The Web site management page contains documentation on how to use the content management system and what Web site conventions are in use (e.g., image and file naming conventions). 2. Top- level page for “IT” category 3. IT > Software Installation 4. IT > Software Installation > ILLiad Project management Although not initially considered during the planning stages, SharePoint has also been used by some of the staff as a simple project management tool. Pages have been set up for special projects, indicating to-do lists and timelines. These pages will be saved after project completion in order to document what was done. “Project” sections have been added to the top-level pages as needed, with links to these pages. Links to current projects are also placed on the Systems home page for easy access. 5. Project page that was developed when servers had to be taken offline for a facilities electrical upgrade In fact, SharePoint was used by the authors to collaborate on this article. A project folder was created in the Document Library, and each added a Microsoft Word document with their respective parts. The parts were then combined into a master document that was reviewed by the group. Further changes were made to the master document by the individual members with Word’s change tracking feature turned on, and SharePoint prevented more than one individual from working on the document at a time. The group then met again and reviewed the changes, approving or modifying them as needed. No documents were e-mailed back and forth, nor was there any confusion about what version was the most up-to-date. SharePoint, in conjunction with Word, proved to be a very useful collaboration tool. Conclusion SharePoint has been a very successful portal for the Systems Team. There is now a single, consistent interface for documenting and sharing knowledge and procedures. Having one central, structured location for documentation works much better than e-mailing how-to instructions back and forth or trying to find documents on the departmental shared drive. Links to wiki pages can be sent easily to library staff who ask about specific procedures. The two Systems Librarians, who need to cover for each other, have particularly benefitted and have been the heaviest users and biggest advocates. Having their documentation readily available is critical for the Assistant Director for Systems and Access Services, who also provides back-up coverage for technical support. The initial planning of the interface gave it a solid structure on which to grow, and consistent procedures for creating documentation have helped it grow in a somewhat orderly fashion. Placeholders for items that still need to be documented have been put in place, as have links to documentation that still lives on the shared network drive, enabling SharePoint to function as a more comprehensive portal. While the top-level structure has been stable, some of the lower-level structure may need some adjustment, as some pages have ended up getting buried. For example, to find the page on DreamWeaver Tips from the Systems wiki home page, the user has to click on Patrons & Staff on the left navigation menu, then on a link to Staff Instructions, and finally on a link for the DreamWeaver Tips page. This has frustrated some library staff members. Creating and updating wiki pages in SharePoint is not difficult due to the WYSIWY
-
Library systems documentation: Pulling it together with SharePoint
'Emerald', 2013Co-Authors: Diffin JenniferAbstract:Documentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge.Library Systems Documentation: Pulling it Together with SharePoint Introduction Documentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge. Why is documentation so important? Those who claim that documentation is not so important because “anyone in the future should be able to figure out what was done in the past” should “[m]ake that argument to someone who has inherited an undocumented network and watch the response!” (Wilson, 1998, p.100). The goal of documentation is “to keep technology running smoothly and serving the good of the institution” and “includes organizing, collocating, and disseminating the knowledge that will help you and others succeed in your library’s technological environment.” It also provides “a concrete pool of evidence for you to point to in describing the importance of your department’s function to your institution” and “paints a picture of what you have done and of the technological environment that needs supporting (Engard and Gordon, 2012, p. 94).” What needs to be documented? “Think of the information that would have made your job easier and provide it for yourself, your staff, and your successor” (Engard and Gordon, 2012, p. 94). Document “how you do things so that if you have to do them again, you don’t have to start from scratch trying to remember how” (Rossman, 2003, p. 22). This includes configuration information for networks, servers and computers, maintenance procedures, as well as support issues and problem resolutions (Engard and Gordon, 2012). It is also important to establish a method for consistently documenting procedures and decisions (Wilson, 1998). How should things be documented? For common tasks, provide step-by-step instructions and be liberal with screen shots. These will coalesce into “a pool of documentation” for the systems staff (Engard and Gordon, 2012). From a higher level, to organize that pool into an effective portal, it is especially important to develop a carefully thought-out taxonomy, mapping out your sites, content types, and navigation, as well as a governance strategy for its ongoing management (Buckley, 2011). What tools are available? Common tools available in organizations include intranets, shared network drives, shared e-mail folders, help desk ticketing systems, and document management systems (Engard and Gordon, 2012; Lappin, 2010). A centralized portal and a tool that can manage records in multiple formats are desirable (Lappin, 2010). Large-Scale Enterprise content management (ECM) systems exist, but what many organizations really need is a system that provides basic content services (BCS) such as Microsoft SharePoint, which is a dominant player in this field (Pelz-Sharpe, 2008). SharePoint is of particular interest because it provides an integrated portal platform that combines document management tools with Web 2.0 communication and collaboration features, and it is readily available to Microsoft customers as part of the Microsoft Core Access License (CAL) Suite for institutions (Dahl, 2010; Diffin and Nangle, 2011). Wikis and Document Libraries provide a means of collaboratively creating, editing, storing, and managing documents. Many types of files can be stored in the Document Libraries, and SharePoint is designed to work seamlessly with Microsoft Office (Dahl, 2010). Announcement, discussion, and blog tools allow a centralized hub for managing a team’s communications. Calendar and survey tools are also included, as are workflow tools for managing projects and tracking issues (Herrera, 2008). What have other libraries done? In the literature, there are a number of examples of libraries that have implemented SharePoint for documentation and communication. For example, SharePoint has been implemented at Towson University to create a portal for the reference team (“RefPortal”) (Dahl, 2010); at the University of Mississippi to build departmental sites (Herrera, 2008); at the University of Maryland University College for the Document Management Team (interlibrary loan and book delivery) (Diffin et al., 2010b); and at the University of Alabama for instruction requests, reference, and interlibrary loan (Ennis and Tims, 2010). At the University of Mississippi, the library’s Information Technology department has a SharePoint site, and they use SharePoint’s blog for IT alerts and news items and have developed wiki pages for setup and troubleshooting tips (Herrera, 2008). At the University of Alabama, after developing their initial SharePoint sites, the library used SharePoint to create “Help Central,” which functions as a help desk and knowledge portal. It provides a ticketing system for users to report issues, for the staff to track and monitor the tickets, and for solutions to be added to a knowledgebase (Ennis and Tims, 2012). The present article will elaborate further on how SharePoint can be used as a portal for systems documentation, and discuss how a taxonomy was developed, how the actual documentation was written, and some of the best practices that were adopted. Background UMUC Library Systems The University of Maryland University College (UMUC) is a predominantly distance education institution serving more than 97,000 students in more than 25 countries (University of Maryland University College, 2012a, 2012b). Information & Library Services (ILS) relies heavily on technology to deliver library services to students, faculty, and staff worldwide. The Systems Team consists of four librarians: a Systems Librarian, a Digital Services Librarian, an Advanced Technologies Librarian, and a Web Specialist. Each of these librarians has very specialized knowledge, which makes it difficult for anyone else to fill in on those duties. (For the purposes of this article the Digital Services Librarian is being considered as a second Systems Librarian, in that this position also provides technical support for faculty, staff, and students.) The team manages a wide variety of areas, including access to electronic resources, server applications, software installation, cataloging, and the Web site. Other responsibilities include developing multi-media learning objects, in-house databases, and customized programs for the Web site. Before SharePoint Before implementing SharePoint, all of the four team members managed their own documentation. There was a tendency to use the library’s shared network drive (the “S-drive”), but team members also kept documentation on their individual computers and in file cabinets, and much was kept in their own heads. Some procedures were documented; some were not. There was no systematic effort in creating, organizing, and sharing knowledge among the whole team, and there were no best practices. Documentation on the S-drive could be difficult to find and sometimes became outdated. Earlier, some of the staff members had made “Survival Guides” listing where their documentation was stored, and the Systems Librarian compiled a local “Procedures” Web page to try to point to all the various documentation, but none of these were consistently maintained or were ever heavily used. What the team needed was a central portal and more consistent procedures for documentation. Cross-training initiative Since ILS is a small library, it is critical to have training and documentation that allows someone to step in for another person and keep things moving in case of absences due to illness or vacations. The Document Management and Electronic Reserves (EReserves) Teams had recently embarked on a successful cross-training initiative that included using SharePoint for documentation and conducting cross-training sessions between the two groups. To keep the knowledge fresh once the initial training was complete, every member of both teams worked in the other area one day a month. SharePoint was chosen as the collaboration tool because it was designed specifically to manage documents, share information, and facilitate communication. Plus, the UMUC IT department had a license for it and had made it available without the library incurring any additional cost. While other options were considered, such as free, online wikis, none of them had all the functionality offered by SharePoint. Also, these services could disappear or become fee-based at any time, and there was no guarantee that data would be retrievable if the services went down. Knowing that the IT department hosted the secure SharePoint server and that they backed it up daily eliminated the concern for potential data loss (Diffin et al., 2010b, p. 231). The cross-training worked so well that the Assistant Director for Systems and Access Services then expanded the idea to the Systems Team. Using the concepts learned by Document Management and EReserves, the Systems Team began a more formalized process of sharing and documenting knowledge. Implementation Getting started The Assistant Director for Systems and Access Services had some initial meetings with the Systems Team to discuss the cross-training project and to decide how the team would proceed. The main focus of this project would be building the knowledgebase. The UMUC IT Department had created a SharePoint site for the Library, and a Systems sub-site was added. The launch of the Systems site created a sense of community among the team members and officially marked the beginning of the implementation. Site structure As part of the planning, the first priority was to develop the site structure. This provided a fresh start to reorganize the documentation strategically. The structure and hierarchy was mapped out according to the team member functions, including: cataloging, electronic resources, in-house applications, IT (hardware, software, and server management), multi-media learning objects, patron and staff assistance, and Web site management, plus useful contacts. Best practices and conventions Given that the Document Management Team had already “implemented best practices for the wiki so it would have a homogenous look and feel even though several different people were working on it” (Diffin et al., 2010a, p. 575), a member of that team was invited to speak to the Systems Team. He covered the basics of SharePoint’s tools and features and shared best practices on style and visual aids. Verdana was chosen as the text font and standardized sizes were adopted for content and headers. Annotated screenshots were preferred over descriptive paragraphs for concision. Breadcrumb trails would be added to the very top of every wiki page for navigation. Internet Explorer became the preferred browser when updating wiki pages because important formatting features in SharePoint were exclusive to this browser. A consensus was reached that the wiki feature would be used as the main tool for creating, organizing, and sharing documentation because of the following features, as summarized by Diffin and Nangle (2011, p. 136): 1. Editing and updating is easy through the WYSIWYG (What-You-See-Is-What-You-Get) editor. 2. Errors can be quickly and easily undone using version history which encourages collaboration. SharePoint creates a new version of the document whenever any change is made in a document. 3. E-mail alerts inform subscribers of any changes to wiki pages. 4. Permissions can be added to selected pages that contain sensitive information. 5. Visual aids (e.g. screenshots) can be inserted to simplify documentation. In addition, all wiki pages can be distributed and shared via URLs. The Systems Team then came up with documentation conventions for the wiki pages that specified several recipe-style elements to be included as needed, such as background information, tools, how-to steps, and problem resolution. Tools included what the user would need (e.g., software, user IDs and passwords, directories) to complete the documented task. The how-to section included step-by-step instructions with screenshots. Problem resolution indicated things that have gone wrong and steps that were taken to fix the issue. When the rubber hits the road Based on the job duties, the responsibilities for creating content in SharePoint were divided among the four library professionals. The Systems Librarian was responsible for Web sites, cataloging, and IT. The Digital Services Librarian documented electronic resources and provided assistance with Web sites. The Web Specialist worked on in-house applications. The Advanced Technologies Librarian covered the multi-media learning objects. Each member decided on the structure and content within their assigned functional areas while still following the basic agreed-upon guidelines and conventions. The Systems wiki site then started to take shape. Over time, the initial structure was fleshed out considerably, as documentation was migrated from the S-drive or created anew. In some cases, sub-menus were created to refine the organizational structure. For example, the top-level IT page linked to a page called “Server Applications,” which in turn linked to pages on EZproxy, ILLiad, and PeopleSoft. As documents migrated off the S-drive and were converted into wiki pages, shortcuts were provided from the S-drive to the new SharePoint site so that anybody looking for the old documents could get to the new documents quickly. Perhaps more importantly, links were provided in SharePoint to the documentation that still resided on the S-drive, so that SharePoint could effectively function as a portal to all or most of the documentation. The idea was that a user could come to SharePoint and still get to everything, even if some things were still on the S-drive. While Word documents on the S-drive were generally re-done in wiki format, other types of documents (e.g., spreadsheets) were simply uploaded into SharePoint into the “Documents” area. These were organized into subfolders as needed, and were linked to from wiki pages where appropriate. The S-drive would still be needed for certain types of files, such as software installation executable files. Also, documents that were not currently in use but were needed for historical purposes would remain on the S-drive and not migrated. During implementation, monthly team meetings were scheduled to review progress. The members presented their new wiki pages, elaborating on the procedures, policies, and knowledge contained therein. The other team members then had a chance to ask questions about the procedures. For example, one member asked for clarification on how Captivate tutorials were created; another asked for details about updating electronic resources. This cross-training enabled all the team members to become familiar with each other’s work and to know where to look if questions came up during a team member’s absence. After much of the initial documentation was created, team members made an ongoing effort to review and update their pages and met every few months to discuss the updates. They signed up for e-mail alerts to be notified when pages were updated. The Result The home page The Systems home page includes a checklist of important maintenance functions in the center. On the right is a who’s who, indicating which staff have responsibilities for the various areas. At the bottom of the home page is a list of current projects. The site navigation bar on the left contains the menu linking to the top-level functional areas of the wiki. Also included on the navigation bar are standard SharePoint links to “Documents” (the library of uploaded documents, such as spreadsheets), “Pictures” (in this case, the library of uploaded screenshots), and other tools (Calendar, Lists, Discussions, Sites, People, and Groups). 1. Home page Organization The major functional areas, comprising the top-level navigation, are as follows: Cataloging: This includes cataloging and weeding procedures, links to useful documentation (such as MARC standards), and the necessary tools (such as OCLC logins). Contacts: Important contact information for the IT department (including after-hours and emergency numbers), plus other UMUC units and external vendors of vital importance, as well as the after-hours contact information of the library Systems Team members is gathered here. Electronic Resources: Providing technical support for electronic resources includes documentation on setting up, branding, and troubleshooting electronic resources, maintaining the SFX linking service, and obtaining Lexis.com IDs for the Legal Studies program. In-house Applications: This section includes documentation on special processes that were created by or for the library. These include everything from Access and MySQL databases that were created for in-house use, outward-facing systems such as the electronic reserves request system used by faculty, and processes involving external systems, such as the nightly processes that extract patron data from PeopleSoft and load it into the library catalog. IT: This section became a launchpad for a broad range of systems documentation, including equipment inventories, software installation instructions, server applications (such as EZproxy and ILLiad), and IP and domain information. Learning Objects: Documentation in this section covers how multi-media and interactive learning objects on the library Web site were created and are maintained. Patrons and Staff: This section includes tools for assisting patrons (e.g., verifying whether a patron is current), a setup checklist for new employees, how-to pages for library staff (e.g., how to access network printers, tips for using Dreamweaver), plus links to some of IT’s help pages (e.g., about using UMUC e-mail and calendars). Web Site: The Web site management page contains documentation on how to use the content management system and what Web site conventions are in use (e.g., image and file naming conventions). 2. Top- level page for “IT” category 3. IT > Software Installation 4. IT > Software Installation > ILLiad Project management Although not initially considered during the planning stages, SharePoint has also been used by some of the staff as a simple project management tool. Pages have been set up for special projects, indicating to-do lists and timelines. These pages will be saved after project completion in order to document what was done. “Project” sections have been added to the top-level pages as needed, with links to these pages. Links to current projects are also placed on the Systems home page for easy access. 5. Project page that was developed when servers had to be taken offline for a facilities electrical upgrade In fact, SharePoint was used by the authors to collaborate on this article. A project folder was created in the Document Library, and each added a Microsoft Word document with their respective parts. The parts were then combined into a master document that was reviewed by the group. Further changes were made to the master document by the individual members with Word’s change tracking feature turned on, and SharePoint prevented more than one individual from working on the document at a time. The group then met again and reviewed the changes, approving or modifying them as needed. No documents were e-mailed back and forth, nor was there any confusion about what version was the most up-to-date. SharePoint, in conjunction with Word, proved to be a very useful collaboration tool. Conclusion SharePoint has been a very successful portal for the Systems Team. There is now a single, consistent interface for documenting and sharing knowledge and procedures. Having one central, structured location for documentation works much better than e-mailing how-to instructions back and forth or trying to find documents on the departmental shared drive. Links to wiki pages can be sent easily to library staff who ask about specific procedures. The two Systems Librarians, who need to cover for each other, have particularly benefitted and have been the heaviest users and biggest advocates. Having their documentation readily available is critical for the Assistant Director for Systems and Access Services, who also provides back-up coverage for technical support. The initial planning of the interface gave it a solid structure on which to grow, and consistent procedures for creating documentation have helped it grow in a somewhat orderly fashion. Placeholders for items that still need to be documented have been put in place, as have links to documentation that still lives on the shared network drive, enabling SharePoint to function as a more comprehensive portal. While the top-level structure has been stable, some of the lower-level structure may need some adjustment, as some pages have ended up getting buried. For example, to find the page on DreamWeaver Tips from the Systems wiki home page, the user has to click on Patrons & Staff on the left navigation menu, then on a link to Staff Instructions, and finally on a link for the DreamWeaver Tips page. This has frustrated some library staff members. Creating and updating wiki pages in SharePoint is not difficult due to the WYSIWYG editor
Tom Maibaum - One of the best experts on this subject based on the ideXlab platform.
-
combining static and dynamic impact analysis for large scale Enterprise systems
Product Focused Software Process Improvement, 2014Co-Authors: Wen Chen, Alan Wassyng, Tom MaibaumAbstract:Software changes and their impact on Large-Scale Enterprise systems are critical, hard to identify and calculate. A typical Enterprise system may consist of hundreds of thousands of classes and methods. Thus it is extremely costly and difficult to apply conventional testing techniques to such a system. In our previous work [1], a conservative static analysis with the capability of dealing with inheritance was conducted on an Enterprise system and associated changes to obtain all the potential impacts. However, since static analysis takes into account all the possible system behaviours, the analysis often results in a good number of false-positives and thus over-estimation of the impact on other methods in the system. This work focuses on extending our previous static approach by an aspect-based dynamic analysis, to instrument the system and collect a set of dynamic impacts at run-time. The new approach is still safe, but more precise than the static analysis. Safety is preserved since the static analysis serves as the input source to the dynamic analysis, and we are careful not to discard impacts unless we can show that they are definitely not impacted by the change. It is more precise since dynamic analysis examines behaviours that do definitely occur at run-time and hence is able to reflect the real impacts. Additionally, our analysis is able to handle the scalability issue. The targeted system is orders of magnitude larger than the system other existing approaches can deal with. A case study was conducted to illustrate that specific objectives can be attained.
-
large scale Enterprise systems changes and impacts
International Conference on Enterprise Information Systems, 2012Co-Authors: Wen Chen, Asif Iqbal, Akbar Abdrakhmanov, Jay Parlar, Chris George, Mark Lawford, Tom Maibaum, Alan WassyngAbstract:Changes and their impacts to Large-Scale Enterprise systems are critical and hard to identify and calculate. This work focuses on analysing changes and their potential impacts, and in particular on how regression testing following such changes can be minimised. The target scope of the approach we describe here is systems containing hundreds of thousands of classes and millions of methods. It is extremely difficult and costly to apply regular regression testing techniques to such systems. It is very expensive and often unnecessary to retest everything after a change is introduced. Selective retesting is dangerous if the impacts of change are not understood, and analysing such systems to understand what is being changed and what the impacts are is difficult. This paper proposes a way to perform a change impact analysis which makes it possible to do efficient, targeted regression testing of Enterprise systems. Our approach has been tried on a large system comprising 4.6 million methods with 10 million dependencies between them. Using our approach, maintainers can focus on a smaller, relevant subset of their test suites instead of doing testing blindly. We include a case study that illustrates the savings that can be attained.
Jochen Krebs - One of the best experts on this subject based on the ideXlab platform.
-
ibm rational unified process reference and certification guide solution designer
2007Co-Authors: Ahmad Shuja, Jochen KrebsAbstract:The Only Official RUP® Certification Prep Guide and Compact RUP ReferenceThe IBM® Rational Unified Process® has become the de facto industry-standard process for Large-Scale Enterprise software development. The IBM Certified Solution Designer - IBM Rational Unified Process V7.0 certification provides a powerful way for solutions developers to demonstrate their proficiency with RUP.The first and only official RUP certification guide, this book fully reflects the latest versions of the Rational Unified Process and of the IBM RUP exam. Authored by two leading RUP implementers, it draws on extensive contributions and careful reviews by the IBM RUP process leader and RUP certification manager.This book covers every facet of RUP usage. It has been carefully organized to help you prepare for your exam quickly and efficiently--and to provide a handy, compact reference you can rely on for years to come.Coverage includes A full section on RUP exam preparation and a 52-question practice exam Core RUP concepts, the new RUP process architecture, and key principles of business-driven development RUP's architecture-centric approach to iterative development: practical issues and scenarios Patterns for successful RUP project implementationi??and “anti-patterns” to avoid The Unified Method Architecture (UMA): basic content and process elements RUP content disciplines, in depth: Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment, Project Management, Change and Configuration Management, and Environment Essential RUP work products, roles, and tasks RUP phases, activities, and milestones RUP tailoring and tools for your organization--including introductions to IBM Rational Method Composer (RMC) and MyRUP
-
ibm rational unified process reference and certification guide solution designer
2007Co-Authors: Ahmad Shuja, Jochen KrebsAbstract:The Only Official RUP® Certification Prep Guide and Compact RUP ReferenceThe IBM® Rational Unified Process® has become the de facto industry-standard process for Large-Scale Enterprise software development. The IBM Certified Solution Designer - IBM Rational Unified Process V7.0 certification provides a powerful way for solutions developers to demonstrate their proficiency with RUP.The first and only official RUP certification guide, this book fully reflects the latest versions of the Rational Unified Process and of the IBM RUP exam. Authored by two leading RUP implementers, it draws on extensive contributions and careful reviews by the IBM RUP process leader and RUP certification manager.This book covers every facet of RUP usage. It has been carefully organized to help you prepare for your exam quickly and efficiently--and to provide a handy, compact reference you can rely on for years to come.Coverage includes A full section on RUP exam preparation and a 52-question practice exam Core RUP concepts, the new RUP process architecture, and key principles of business-driven development RUP's architecture-centric approach to iterative development: practical issues and scenarios Patterns for successful RUP project implementationi??and “anti-patterns” to avoid The Unified Method Architecture (UMA): basic content and process elements RUP content disciplines, in depth: Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment, Project Management, Change and Configuration Management, and Environment Essential RUP work products, roles, and tasks RUP phases, activities, and milestones RUP tailoring and tools for your organization--including introductions to IBM Rational Method Composer (RMC) and MyRUP
Ehab Alshaer - One of the best experts on this subject based on the ideXlab platform.
-
correlation based load balancing for network intrusion detection and prevention systems
International Workshop on Security, 2008Co-Authors: Raouf Boutaba, Ehab AlshaerAbstract:In Large-Scale Enterprise networks, multiple network intrusion detection and prevention systems are used to provide high quality protections. In this context, keeping load evenly distributed among the systems is crucial. This is because even load distributions provide protection to the networks and improve the networks' quality of service. A challenging problem, however, is to maintain the load balancing of the systems while minimizing the loss of correlation information due to distributing traffic. Since anomaly- based detection and prevention of some intrusions, such as distributed denial of service (DDoS) attacks and port scans, require a single system to analyze correlated flows of the attacks, this loss of correlation information might severely affect the accuracy of the detections and preventions. In this paper, we address this challenging problem by first formalizing the load balancing problem as an optimization problem, considering both the systems' load variance and the correlation information loss. We then present our Benefit-based Load Balancing (BLB) algorithm as a solution to the optimization problem. We have implemented a prototype load-balancer which uses the BLB algorithm. We evaluated the load-balancer against various port scans and DDoS attacks. The evaluation results show that our load-balancer significantly improves the detection accuracy of these attacks while keeping the systems' load close within a desired bound.
-
specifications of a high level conflict free firewall policy language for multi domain networks
Symposium on Access Control Models and Technologies, 2007Co-Authors: Bin Zhang, Ehab Alshaer, Radha Jagadeesan, James Riely, Corin PitcherAbstract:Multiple firewalls typically cooperate to provide security properties for a network, despite the fact that these firewalls are often spatially distributed and configured in isolation. Without a global view of the network configuration, such a system is ripe for misconfiguration, causing conflicts and major security vulnerabilities. We propose FLIP, a high-level firewall configuration policy language for traffic access control, to enforce security and ensure seamless configuration management. In FLIP, firewall security policies are defined as high-level service-oriented goals, which can be translated automatically into access control rules to be distributed to appropriate enforcement devices. FLIP guarantees that the rules generated will be conflict-free, both on individual firewall and between firewalls. We prove that the translation algorithm is both sound and complete. FLIP supports policy inheritance and customization features that enable defining a global firewall policy for Large-Scale Enterprise network quickly and accurately. Through a case study, we argue that firewall policy management for Large-Scale networks is efficient and accurate using FLIP.
Boris Stumm - One of the best experts on this subject based on the ideXlab platform.
-
change management in large scale Enterprise information systems
Extending Database Technology, 2006Co-Authors: Boris StummAbstract:The information infrastructure in today's businesses consists of many interoperating autonomous systems. Changes to a single system can therefore have an unexpected impact on other, dependent systems. In our Caro approach we try to cope with this problem by observing each system participating in the infrastructure and analyzing the impact of any change that occurs. The analysis process is driven by declaratively defined rules and works with a generic and extensible graph model to represent the relevant metadata that is subject to changes. This makes Caro applicable to heterogeneous scenarios and customizable to special needs.
