vision document - drexel universityal495/eport/docs/info627visiondocument.pdf · the vision...

Vision Document

Company Name: PTI

Project Members: Adam Lerman Abdalla Hashem Danijela Lazarevic James Mallon

© 2010 PTI

REVISION HISTORY Date Revision Description Author 02/21/2010 1.0 Initial version Group 3

Lerman, Hashem, Lazarevic, Mallon

1

Table of Contents

1. Introduction ............................................................................................................................... 2 1.1 Purpose of the Vision Document .......................................................................................... 2 1.2 Product Overview ................................................................................................................. 2 1.3 References ............................................................................................................................. 3

2. User Description....................................................................................................................... 4 2.1 User/Market Demographics .................................................................................................. 4 2.2 User Profiles.......................................................................................................................... 5 2.3 User Environment ................................................................................................................. 7 2.4 Key User Needs .................................................................................................................. 10

2.5 Alternatives and Competition ............................................................................................. 12 2.5.1 IssueTrak (current system) ........................................................................................... 12 2.5.2 Home-grown complementary application (custom application) .................................. 13 2.5.3 Bugzilla ........................................................................................................................ 15

2.5.4 HP Quality Center ........................................................................................................ 15 3. Product Overview................................................................................................................... 17

3.1 Product Perspective ............................................................................................................. 17

3.2 Product Position Statement ................................................................................................. 18 3.3 Summary of Capabilities..................................................................................................... 19 3.4 Assumptions and Dependencies ......................................................................................... 20 3.5 Cost and Pricing .................................................................................................................. 21

4. Feature Attributes .................................................................................................................. 21 4.1 Status ................................................................................................................................... 21 4.2 Priority ................................................................................................................................ 22

4.3 Effort ................................................................................................................................... 22 4.4 Risk ..................................................................................................................................... 22 4.5 Stability ............................................................................................................................... 22 4.6 Target Release ..................................................................................................................... 22 4.7 Assigned To ........................................................................................................................ 23

4.8 Reason ................................................................................................................................. 23

5. Product Features ................................................................................................................... 23 6. Exemplary Use Cases .......................................................................................................... 24

6.1 Business use-case ................................................................................................................ 25 6.2 Feature 1 - Ability to Add Issue .......................................................................................... 25 6.3 Feature 2 - Ability to Edit Issue .......................................................................................... 26


2 1. Introduction In this section we introduce the vision document and the necessity for completing it. We also discuss a brief overview of the product intended to be implemented, including its intended use, benefits, and goals.

1.1 Purpose of the Vision Document

The vision document used during the software/systems development lifecycle serves to gather, identify, and analyze high-level needs of the product’s users, along with intended product features. It centers on the system capabilities needed for the users to perform their job duties more efficiently and the reason why these factors exist. Additional more well-defined details and requirements will be provided elsewhere in the requirements specification soon to come. Instead, here we focus on the role that the system will play for PTI and the high-level goals for change.

The proposed system which will be further detailed in following sections is meant to be a more robust issue tracking system with additional features than are currently available at PTI. In addition, the system will have the ability to serve more stakeholders than at present, which is highly beneficial for the organization’s environment and will enhance many work processes. The purpose of the system is to allow for more well-defined submission and tracking of issues and defects, both among the customers, developers, testers, etc. within the organization and to enhance the development/testing communication, collaboration, and information transparency. The following list describes some of the high-level goals the system intends to promote:

• High quality software product. • Better response time to software issues affecting customers. • Shorter development cycle which will result in faster time-to-market:

o To meet rising demands of a rapidly growing customer base, and o To ensure the company's goal of remaining the cutting edge technology leader

in the marketing and sales IT tools market is consistently met • Efficient use of resources (such as improved efficiency of developers and testers and

helpdesk) • Less time spent struggling with the development environment and issue tracking and,

consequently, more time spent on innovation.

Section 2 will illustrate the users involved in using this new system and why these goals are important based on their environments, activities, and needs. First, however, the following section introduces the product with a brief overview.

1.2 Product Overview

As has been stated, the purpose of the system outlined in this document is to enhance collaboration and communication and reduce information hiding among testers and developers, in addition to allowing for more advanced issue tracking and submission. This will be the first


3

version of the new system, with at least two more foreseen to come as is demonstrated in the block diagram below in section 3.1. Once implemented, the system will benefit a variety of stakeholders and enhance multiple business processes, and the list below depicts a number of these advantages. More detail can be found in following sections throughout this report.

• Enhance software issue resolution

• Allow for enhanced reporting of issues and defects

• Allow for improved viewing and tracking of issues and defects

• Ability to add notes to reported issues

• Permit ease of searching with basic and advanced options

• Improved knowledge base

• Ability to track assigned issues and follow through on resolutions

• Generation of multiple reports, both manually and automatically

• Provide issue/defect accountability

• Determine, store, and track issue/defect priority

• Help to ensure work orders are closed when complete

• Provide additional stakeholders with system access and greater robustness

• Allow for confirmation of fixed issues

• Keep users informed of progress at all times

• Reduce information fragmentation

• Open lines of communication between teams

1.3 References

Bugzilla. Features. Accessed on February 8, 2010 from <http://www.bugzilla.org/features/>. Communications with various stakeholders, including testers and developers. Hashem, A., Lerman, A., Lazarevic, D., & Mallon, J. (2010). Project Assignment 1: Problem

and Context Analysis. INFO627, Drexel University: Philadelphia. HP Quality Center Software. Accessed on Feb 10, 2010 from

<https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-127-24^1131_4000_100__>.

Proscape Technologies, Inc. (2010). About Proscape: What We Do. Accessed on February 11,

2010 from <http://www.proscape.com/about.aspx>.


4

Proscape Technologies, Inc. (2010). Closed Loop Marketing: Closed Loop Marketing for Pharmaceutical Companies. Accessed on February 11, 2010 from <http://www.proscape.com/clm.aspx>.

2. User Description In order to present the products and services necessary to fulfill the needs of the users of our proposed technology, it is crucial to first understand the challenges they face when performing their daily work activities. Therefore, this section will discuss the particular users likely to utilize the new system, along with the current major problems that impede productivity. It is our intent to lay the foundation for the needs that the system will fulfill, allowing the reader to understand why the features of the system described later in section five are required.

Currently, a number of users utilize the issue tracking system supplied by PTI, but it is possible to incorporate additional users with the proposed added enhancements. This will allow for more efficient work processes for the team and a more content customer base. Those who are presently using the system fall into the categories of account managers, application consultants, program/product managers, and customers, all of which are described in the sections below. We first start by discussing the user and market demographics before discussing particular user groups. We then describe the users’ working environments and major needs, and we end the section by discussing various alternative solutions.

2.1 User/Market Demographics

This section serves to discuss the users of the proposed system and the markets in which they operate. It provides an overview of the main demographics that motivate the decisions behind our product, and demonstrates PTI’s position in the market. In addition, we briefly discuss the reason for the need behind the system and the manner in which it is currently used.

PTI is the innovator and global leader of closed-loop marketing software, providing seven of the top ten pharmaceutical companies with improved sales-force effectiveness, sales and marketing productivity, and overall company performance through its Tablet PC software. Closed-loop marketing (CLM) is an innovative technology allowing pharmaceutical companies to enhance the efficiency and effectiveness of sales reps in the field, thereby adding value to physician interactions and increasing the chances of building a lasting relationship and ensuring the company’s success. It does so by allowing for continuous feedback garnered from real-time sales presentations, making it readily available to home-office marketing teams for more informed decision-making. Because of this, the marketing team is able to quickly and cost-effectively modify existing messages, change tactics, and prepare new strategies based on customer feedback, and sales representatives are, in turn, able to deliver more effective and personalized interactions on future sales calls. In addition, PTI products ensure marketing compliance and reduce overall marketing expenditures, along with optimizing the company’s currently used customer relationship management and sales force automation tools.


5

PTI’s current customer base is globally located, and even their employees are somewhat dispersed throughout the United States as well as in global markets. Because of this, a uniformly accessible system must be available for logging and reporting errors/defects, and must be utilized by a number of stakeholders. Customers include major and mid-tier pharmaceutical companies, many with a global reach. This may consist of tens of thousands of marketing professionals, salespeople, graphic designers and content creators, and pharmaceutical reps, as well as IT employees who implement the CLM and database technologies. In addition, PTI has its own salespeople and partners who utilize the software on a daily basis and must stay up to date with current initiatives. Finally, account managers, product managers, application consultants, the developers themselves, and the testers, must also be kept in the loop as to what issues exist and what their current status is. The main use of the issue reporting system is for the aforementioned users to have a secondary means of reporting errors and defects. Since it is mainly the IT staff on the customers’ side who have access, every issue is first reported to them for immediate resolution. If IT is not able to solve the problem, they write an issue submission for resolution by PTI. It is PTI’s job, then, to provide possible solutions to ensure that it is a user error and not a software defect. Discussion takes place back and forth through the current issue tracking system and, if necessary, an application consultant is called to provide assistance for an additional fee. If it is determined to be a software defect rather than a user error, however, the issue is reported to the developers for a solution or possible work-around. Currently, testers are never involved in the process and are unaware of potential defects unless given an assignment by the developer for further testing. Not only is the system used for defects and concerns, but it is also used for enhancement requests and work order requests as well. Again, not all of the right people are involved in these processes, and the usage should be more widespread. Product decisions must be made to include the widespread community of users, making it efficient for everyone to use. The inclusion of error reporting systems in software companies is crucial for remaining on track with development and ensuring a quality product along the way and even after it hits the market. The current use of this system at PTI is not extensive enough and not used by all of the right people. Various pre-made solutions already exist, the best of which are described below in section 2.5. It may be possible for PTI to adopt one of these, or it may be necessary for the company to build its own. It is our hope to determine which case would best suit the company using the information contained within this document and the requirements specification which is to be created in the near future.

2.2 User Profiles

As has been stated, a number of users are anticipated to use this system. Each user group will be described below. This section will take into account factors such as the users’ technical background, key responsibilities, situations that make their job easier or more difficult, interfering problems, and how they measure success.

• Customers – customers are generally the main and frontline users of the issue tracking system, submitting errors they have and awaiting a response from the PTI team. They are


6

mostly IT professionals who have tried other means of resolution before contacting PTI, but do not use the software directly themselves. Other types of customers are the content creators who use PTI’s software for delivering the pharmaceutical sales reps’ presentations. The customers rarely give enough information to reproduce an error and must be coaxed by the PTI staff to submit additional documents, which must be able to be done through the issue tracking system. Every problem to them is always urgent and their success relies on having the problem resolved in a timely manner.

• PTI salespeople and partners – these individuals have a moderate degree of computer experience but little to moderate amount of technical expertise. As their job function is to sell the product and gain new partners, their use of the PTI software is mainly limited to sales demonstrations. Content is created for them and they must download it to be used during presentations. Therefore, they must have effective content and efficiently-working software to provide their best sales effort and portray an effective business solution. However, when inevitably coming across issues with the system, they must have a method of reporting their concerns. Salespeople are obviously successful when they close a deal and when there are no issues with the system.

• Account managers – when customers are dissatisfied, needs arise, or a plan of action for

implementation and usage of the software exists, account managers may be called upon. They are the ones who liaison between PTI and the customer once relationships have been established, and they must have constant access to the issue tracking system. Although they have only a moderate technical background, the account managers have vast experience with customer relations. Therefore, it is important for them to be on top of their client’s concerns, and being a part of the issue tracking process helps them to do so by allowing them to understand the issue from the start and to negotiate a process of customer service. Account managers are successful only when their clients are happy and are successful in their own endeavors using the software.

• Application consultants – these team members are forwarded issues that they have

expertise in to try to solve the problem from the start. In addition, when the problem submitted is too big to be handled by regular discussion but is not due to a defect in the software, an application consultant may be called upon and is paid an extra fee for service by the customer to walk them through to a solution. They have extensive technical knowledge in general and in relation to the software and its configurations specifically, and must keep a careful eye on the issue tracking system at all times. Application consultants’ success relies on the fact that they can track and monitor issues and provide prompt and efficient service in resolving problems.

• Product managers – the product managers must have vast technical experience and a high

level of sophistication and involvement in the software development process as well as with the issue tracking system. They must decide what direction the company should take and will have a hand in a number of aspects of the business. It is necessary for them to be highly involved in the issue tracking process so they know how the product is faring and what issues should be of concern. Product managers are successful when the product is successful and when issues can be scrutinized, analyzed, and taken care of, and when


7

they come to resolution either through walking the customer through the problem or by making a change to the product. They will also be the ones to decide what enhancements must be implemented or what may be charged to a specific customer for an extra fee.

• Developers – developers rarely use the current issue tracking system, but this team

obviously has a high level of technical knowledge and sophistication. They create the software and should be informed of any problems which may arise and need resolution. It is not important to see every issue that comes through since most of them are not related to software defects, but they should have their own channel of reporting and tracking defects for testing and debugging. Their success comes when the product is well-written with minimal bugs and provides an optimum solution to the customer for pharmaceutical sales presentations. They are told when it is necessary to provide enhancements, and they are responsible for creating their own visions for the future of the software. The development team provides the software to the other stakeholders above, and must also provide modules and whole implementations to the QA department for testing.

• Testers – the QA/testers do not currently utilize an issue tracking system but it is

important to do so to keep track of bugs they have found and reported to developers. In addition, they should be apprised of any known defects or future enhancements to be tested. The testers come from various backgrounds, some with technical and hands-on experience but some without. All rely on logic and tooling around with the system, however, to find bugs and reproduce reported errors. They are successful when this has been completed, but they rarely know if what they report to the developers is seen and placed at any level of importance. Therefore, it is necessary for them to deliver their findings and to be able to track them as well.

• System Administrator – this role is currently managed by the third party software

licenser. However, for the intended new system, this will be a super user of the system who will be maintaining the issue tracking, user accounts, and knowledge base system and search capabilities. This role will be supplementary to the same role as currently filled by the third party since our product will be an upgrade/add-on to the current system, as will be discussed in later sections. This user must have a fairly technical and sophisticated background since he or she will have control over much of the entire system and his or her goals will be reached depending upon successful implementation of user rights, system privileges, etc.

2.3 User Environment

This portion of the vision document outlines the new system’s users’ working environments. This is important to determine how work is currently conducted and allows us to visualize potential changes and enhancements to the processes as will be provided by the system. The following is a list of users and a description of their job settings.

• Customers – PTI has tens of thousands of customers utilizing their software on a daily basis throughout the world. In addition, more users are being supplied with the software


8

on a regular basis as the companies realize its benefits. These customers speak various languages and have differing cultures, but their work is carried out in a similar fashion. Content is created by a content administrator/developer and is then synced to the client’s tablet PC for presentation on a sales call, and the information gained is then synced back to the marketing department. This process takes anywhere from a few days to weeks to create the content, and is synced within a few hours at most depending on its size and number of files. If problems arise, the company’s IT people are called upon to resolve the problem, and if they cannot do so, an issue is generated on PTI’s current issue tracking system. Since most sales presentations are delivered at the doctors’ offices, the main form of communication is face-to-face with a tablet computer. However, it is possible to present the information online via a self-directed or rep-directed presentation. In this case, an Internet browser and PC of choice are used, and additional content servers are as well. Possible additional applications in use are customer relationship management software, and PTI’s solution integrates with the most popular ones.

• PTI salespeople and partners – the sales staff and partners of PTI range in the hundreds, and their job is to obtain more customers and partners to buy and sell the software, respectively. As new partners are gained, the number of staff increases, but the current sales staff specifically under PTI is fairly constant. When presenting the PTI solution on a sales call and acquiring new customers, it could take up to a few weeks or months to nurture the prospective clients and win their business. They then have to be kept happy to remain loyal to the company. Since PTI is a global business, sales calls must be made worldwide by salespeople and account managers, and varying cultures and ways of life must be taken into account. Tablet PCs and other demonstrable content may be used, and mock presentations are made to demonstrate how the software works. Again, salespeople are provided with the content needed, which must show the full functionality of the system and must be in proper operational form. Any problems must be reported and resolved immediately so as not to interfere with the process or cause the loss of business.

• Account managers – these staff account for less than ten percent of PTI’s employees, but are vital to the company’s success. Their job is to make sure that customers are happy and to interface with large company clients to formulate success plans. They iron out the details of contracts and discuss enhancement requests as well. They are constantly in contact with the customers to ensure their satisfaction, and any particular process they carry out is generally ongoing. Account managers must also be present locally or internationally, depending on where their companies are located, and they stay in contact through phone, e-mail, and web-conferencing communications.

• Application consultants – these individuals are called upon when technical problems

must be fixed or additional knowledge must be provided to solve an issue. They also consist of less than ten percent of the company’s employees and each consultant is an expert in a particular module of the software. When an issue arises that needs consulting, these staff spend the time to attempt to obtain as much information about the problem as possible and to provide possible solutions. This may only take a few minutes to write a note to the user about the problem, but may take hours or days to hear back about its resolution or further information. If the problem cannot be fixed easily, they charge


9

customers by the hour to consult one on one, over the phone or in the customer’s place of business. This may also cause the application consultant to have to leave town for a big job, but much of the time is spent working over the phone. They use PCs to walk through the problem, generally using a virtual machine loaded with the software as a test environment, and are frequently directly forwarded issues by employees acting as issue screeners without having to constantly monitor the tracking system themselves.

• Product managers – product managers make up only a few of PTI’s employees and are generally located on-site. Their participation in the software process is ongoing and they play a major role. Their job is to decide what features should be included in new software releases, if and when enhancements should be made, when the product should be released, etc. Much of the managerial development process is in their hands. Therefore, they play a big role in monitoring the issue tracking system, albeit from somewhat of an external, hands-off perspective. They rely on reports and use their own PC to perform their daily activities, and are in constant contact with developers, customers, and various other PTI employees. They attempt to have a new software build released every 6 months and a new version every year.

• Developers – unlike product managers, developers are generally located off-site in the

continental United States. There are a handful of these staff and, as stated above, they attempt to complete a new software build every six months and a new version every year. In addition, they frequently work on the reported defects and attempt to have them resolved as quickly as possible for further testing. Developers are constrained by product deadlines, modern technology, features that the product managers impose, etc. As the software gets bigger and demands more functionality, the need arises to hire new developers, but this has not yet been the case as of recent. Work is conducted on PCs and tablet computers, using various operating systems, virtual machines, servers, etc. The developers only use the issue tracking system to a limited extent and mainly conduct correspondence through e-mail.

• Testers – as of now, there are only three testers, two of which are recent additions to PTI.

They were hired because the company is expanding and the product is becoming more robust, utilizing additional operating systems, servers, etc. in addition to new features being added. A single task may take a day or a week to complete, depending on the setup that has to be created and the content/issue being tested. Testers utilize desktop PCs and perform their work on various virtual machines, setting up servers and clients with multiple configurations. This includes every available combination of Windows products, in addition to a few customer relationship management programs. Testers do not currently monitor the issue tracking system or report issues through it, but are in direct contact with the developers for assignments and error reporting.

• System Administrator – since this will be a new role, the working environment has yet to be concretely defined. However, we anticipate that the user will work directly in the office of PTI’s headquarters and will mainly use a PC to access the web. Much of the work will be carried out behind the scenes and communication should be between all user groups.


10 2.4 Key User Needs

In order to provide the best possible solution, it is important to determine the key needs as defined by the users. The following list contains the problems and needs as seen by the collective of users and identifies the reasons they exist, how they are currently solved, and what solutions the users envision.

The following list contains problems and needs as seen by the collective of users.

• Need to resolve issues with PTI’s software – being a software company, the products that PTI produces will inevitably contain defects. These, along with other issues such as configurations, user errors, etc. must be able to be fixed in a timely and efficient manner. Currently, testers and customers report known issues/defects, but the system is not robust and needs updating. They hope to be provided with a stronger, more intelligent and useful system in the future.

• Need to be able to report issues/defects – as stated above, this problem is inevitable, but the way it is dealt with should be improved.

• Must be able to view and track reported issues/defects – currently, issues are able to be

viewed but not tracked very well. Some may be orphaned and forgotten about or just ignored. It is necessary to allow for continuous tracking, updates, and accountability.

• Must be able to add notes to reported issues with the ability to make them private

(internal viewing only) – notes and discussions should be able to take place surrounding an issue, both with the customer and privately internally.

• Need to search issues – issues and defects should be easily searchable with simple and

advanced search options. This is important so that known issues can be found and users can determine current status.

• Need to search a knowledge base with known issues and fixes – much of the articles are

old and not easily searchable. Old articles should remain for those with that version of the software, but articles should also be updated for current versions. It is important to start here to see if the issue the user is reporting is already known and a solution or work-around exists. This will avoid redundant submissions and reduce work effort.

• Unable to track specific defects for resolution – defects cannot currently be tracked but

the users would like them to be so that they can determine whether they have been considered, overlooked, fixed, placed on hold for future software versions, etc. This would allow for accountability and transparency of work effort.

• Unable to track assigned issues – issues are not able to be tracked due to current

limitations. Users would like to be able to quickly and easily see an audit trail to see the


11

status of a reported issue. It is also important that issues can be closed so we can determine their resolution or lack thereof.

• Need to generate reports for open/closed/resolved/unresolved/etc. issues/defects – reports

are not currently generated but would be helpful for users to easily determine the status of their submitted issues. These should be able to be generated automatically or manually based on specific criteria or general issue categories.

• Issues remain unresolved in current software versions – this may be due to the fact they

were overlooked or not found to be important enough to warrant a change. Certain stakeholders such as testers, however, would like to be kept in the know of what the status is and why. As of now they are not informed and do not know whether issues should be submitted or tested again.

• No way to determine priority of issues – issue priorities are not readily available to all,

and the users would like to be able to determine how their problem might be resolved and in what timeframe.

• Work orders aren’t closed when complete – work orders are not always closed due to the

number of involved users but no specific accountability for an issue. Users would like to ensure that every work order has a resolution and that it was worked on by the respective individual. Even if they are not complete, status should be updated and a timeframe or deadline should be implemented. These should then be easily viewable by those with a vested interest.

• Issue tracking system not used by all stakeholders – currently, it is not seen as necessary

to include all stakeholders in the use of the issue tracking system. In addition, the system is not robust enough to warrant various uses for multiple stakeholders. However, this means that multiple systems are used or none at all, and issues/defects may go unaccounted for or unresolved. Stakeholders would like a more robust, more inclusive system to be used for multiple purposes.

• Need confirmation of fixed issue – issue fixes are not confirmed because they are not

always resolved or are disregarded. Even when they are fixed, they are not always reported as such. Therefore, stakeholders would like to see specific persons be made accountable for certain issues and would like a way to view status and confirmation. This would reduce redundant effort and ensure that interested parties are kept happy.

• Must be able to keep up to date with changes – this incorporates a number of different

issues. Status of issues should always be submitted and users should be kept informed. As of now, the system does not have the ability to do so, but users should be able to sign up for status reports and be able to see and track issues at their disposal.

• Information fragmentation problem – this issue arises from the lack of a central

information repository, ad hoc document distribution, and disorganized sharing across


12

multiple user environments. At the moment, nothing is being done to solve this problem, but it is the stakeholders’ wishes that a central repository and tracking system be created to house this knowledge. Also, accountability for documents and frequent communication should be implemented.

• No open communication between teams – this problem is due to the fact that there is no

liaison between different teams and no direct contact between many of the members. Nothing is currently being done, but the stakeholders envision a change of business process and adding new key members to act as points of contact to facilitate communication.

2.5 Alternatives and Competition This section will discuss the current system in place at PTI and will identify and briefly discuss various alternative solutions. In addition, weighted tables will be provided to score the usefulness of each and their ability to meet the main goals and problems of the business. At the end, one alternative will be chosen to be detailed throughout the rest of this and the requirements specification reports.

2.5.1 IssueTrak (current system)

This is the software that is currently used to track issues related to software development and testing in addition to allowing customers to report issues. This is a web-based application which makes it easy for customers, as well as company employees to access and use. A new and enhanced version of this software has been released this year that addresses some of the issues reported by the users. Some of these issues were perceived as efficiency issues and others were perceived as being a result of inadequate features of the software. The following are some of the enhancements that potentially make it possible to use the current system to address some of the concerns at hand. Furthermore, this is maybe viewed as a viable solution since the company has already been using this system. Therefore, continuing to use it with the new enhancements may save the company money and time since there would be minimal training involved, if any, and the learning curve would be very shallow. The following are the new/improved features:

• One-click access to frequently used pages/screens along with new features that make

the process of submitting and handling issues much easier than before. • An auto-complete feature that filters information automatically as you type, which, in

turn, allows the user to select the right choice effortlessly by minimizing the number of choices on the screen; only relevant matches are displayed.

• More flexible and customizable Dashboard that allows users to see the date and time

of the last data refresh; the user is instantly able to know how current the displayed metrics are.


13

• Customizable user view which results in seeing information/issues most important to them quickly and acting promptly.

• Customers can create customized issue screens for various departments and types of

requests

• Management Dashboard: Mangers can easily scan open issues by subtype, location, region and severity on the dashboard.

Communications: IssueTrak e-mail module enables end-users and customers to submit issues directly into the IssueTrak itself using a free-form e-mail. This streamlines submitting support requests as it eliminates copying and pasting user requests into IssueTrak. Additionally, it eliminates the possibility of losing emails. Consequently, it saves the company time and money handling customers issues. The support request process happens in the following sequence:

• The user/customer using the email module sends an email requesting support. • This email is automatically converted into a support request/ticket. • IssueTrak determines the request type and the person/group that should handle the

issue and assigns the ticket to that person/group. • IssueTrak notifies the user/customer that their request has been received and assigned.

Strengths: Issuetrak has been the primary issue tracking system in the company and, thus, internal users as well as external users know how to use the system and have built processes around this system. Keeping the system and upgrading it will eliminate the need for porting the data to another system, training users, and building a new set of extensive processes around the system. Consequently, keeping the system and just updating it saves the company time and money in addition to preserving the integrity of the historical data. Weaknesses: IssueTrak does not meet all users’ needs, especially in terms of search abilities, collaboration, and work-flow.

2.5.2 Home-grown complementary application (custom application)

IssueTrak has been the primary issue tracking system that the company has used for years. Employees, and more importantly, customers are used to using this system. Therefore, replacing the system with a new one may disturb tracking issues and help desk functionality and will have some impact on the development and testing processes. These potential impacts will take time to settle down. Because of this, it is a viable solution to build an application that can be integrated with the current system and can address its shortcomings. This can be a work order system that allows attaching and sharing files, virtual machine assignments, instant communications and logging of procedures necessary, and related


14

special instructions for testing in addition to providing the ability to generate customized reports for the different types of stakeholders. Some of the important projected features:

• Advanced Search Capabilities: The intention here is to provide the following capabilities:

1.Simple search, similar to Google search, which will enable users to search text. 2.Advanced search that enables users to create custom searches including time-

based searches. For example, “show me the bugs that have changed status within the last 2 days” or “show me the bugs that changed priority within the last 24 hours”, etc. Additionally, advanced users can run specific SQL-like queries.

3.Save and share searches: this gives the ability to save your own searches and run them any time you want in addition to the ability to allow other users or groups to link to your searches (this will reflect any updates to the search) or copy them.

• Email notification based on user preferences: Email notifications will be sent for any updates of issues/tickets based on the users’ preferences, settings, department, etc.

• Scheduled Reports (Daily, Weekly, Hourly, etc.) by Email: Ability to schedule reports (hourly, daily, weekly, etc.) to be sent to a user, a group, or a list of users. These reports can be the results of a particular search that is defined by the user.

• Reports and Charts: this is to enable viewing trends and to help in strategic planning. • Time Tracking:

This can show estimated time of fixing an issue vs. actual time it took to fix it. Additionally, one can set a deadline by which an issue must be fixed. If the deadline is passed, a compliance report will be sent to team lead/manager, etc. This can enhance transparency.

• Ability to List bugs in Multiple Formats (HTML, Excel, Word, etc). • Custom Fields: ability to add custom fields to the database in order to capture certain

data and also to enable customized searches that are unique for a specific group or department, etc.

• Customizable workflow: provides the ability to define and set the lifecycle for issues. This includes statuses, resolutions, and a sequence of status changes. This will be customizable so it can be changed to fit business/user processes.

Strengths: This solution eliminates the cost associated with acquiring a new system to address all the current system issues. Instead, it builds on the strengths of the current system while addressing its shortcomings. Users do not have to re-learn the system; they only have to learn the new functionality of the new application. Consequently, this would be the best of both worlds, as the new application will be built and customized to solve users’ issues as opposed to a new generic system that may address some of the needs and miss others.


15

Weaknesses: The only weakness that we see is having to make resources available to work on building the new application and, hence, that may translate into having less people working on client-facing applications until the new application is done.

2.5.3 Bugzilla

Bugzilla is an open source testing platform developed by Mozilla Corporation and licensed under the Mozilla Public License (MPL). Its issue tracking application is a comprehensive issues tracking system that enables customers, software quality assurance (SQA), and development teams to collaborate effectively and efficiently in ensuring quality software development and product delivery. The application has been known as a successful open source resource for reporting issues, defects, and enhancements in order to ensure quality of current products and provide improvement of future product releases in start-ups and small to medium sized IT companies. The application is compatible with, and offers the following solutions:

• OS: developed for Linux OS with Apache HTTP Server but can be adapted to run successfully on other widely used OS;

•DB: Oracle, MySQL, and PostgreSQL; •GUI: web and desktop; •Notification: email and RSS.

The major advantage of this alternative is its open source nature which provides an opportunity for developing a flexible and cost-effective solution for PTI’s needs. However, for the solution to be adopted, customized, and integrated into the current PTI workflows, internal resources may be required with a working knowledge of the Perl programming language. Furthermore, although the Mozilla Corporation is dedicated to providing high quality products with the best possible maintenance and support services, its open source business model does not offer any guarantee of such service. Thus, PTI will have to take into account such additional costs when considering the ROI of this alternative.

2.5.4 HP Quality Center

HP Quality Center (QC) is a proprietary Hewlett- Packard quality management platform that consists of several modules. The modules of interest for PTI include a comprehensive issue tracking system and a testing module with test plan management and manual and automated test case execution capabilities. These will allow PTI’s QA, development, and business teams to collaborate within the product quality lifecycle and will enable the organization to better manage its testing assets.

•OS: MS Windows; •DB: SQL Server, Oracle; •GUI: Web; •Notification: email.


16

QC has solid, scalable solutions for the two major PTI organizational problems: issue tracking and testing management, and the software comes with service support by HP, one of the leaders in the IT industry. However, the cost of this proprietary software may be one of the biggest disadvantages of this alternative. Also, the system requirements compatibility needs to be further investigated.

The following tables depict scoreboard analyses for the software alternatives based on PTI’s business goals and problems, and each factor is weighted according to its importance and impact.

Table 1: Major Goal Scoreboard Analysis based on a 1-10 (lowest to highest)

MAJOR GOALS & Problems

solved

Business Goals Problems Solved

Customer satisfaction, retention,

and expansion [weight x4]

Retain industry

leadership by supplying cutting-edge technology

[x3]

Improved reliability

and quality of products

[x2]

More effective issue tracking

system for internal and external use

[x4]

Inadequate internal

collaboration and

communication channels

[x3]

Lack of centralized knowledge repository

[x2]

Home-grown complementary

system

10 10 8 10 9 9

Bugzilla

8 8 7 6 7 6

HP Quality Center

10 5 8 6 6 2

Table 2: Problems are weighted to be twice as important as business goals

Alternatives Support for Business Goals

Problems Solved Total Score

Home-grown complementary

system

86 85x2 170

Bugzilla

70 57x2 114

HP Quality Center

71 46x2 92

As we can see from the tables above, the home-grown complementary application was favored due to the fact that it meets more of the business needs and satisfies the problems more


17

efficiently. In table 1 it ranks higher on most priorities, and in table 2 we can see its anticipated effectiveness noticeably surpasses the alternatives.

3. Product Overview This section intends to provide a high-level summary of the chosen product’s capabilities, interfaces to additional applications, and its system configurations. We start by putting the product into perspective amongst the other alternatives, and we demonstrate why it is the better choice according to its position statement. We then summarize its benefits and the features which allow them to transpire, followed by its assumptions and dependencies and, finally, its costs.

3.1 Product Perspective

This section attempts to put the chosen product into perspective among the other alternative choices with respect to the product’s users and environments. The best way to do so is to present a block diagram which is shown below, the purpose of which is to demonstrate the major components of the larger system, along with its interconnections. In addition, the diagram shows in which versions of the product certain features will be added.

System Management Module

SearchModule

Report Module

Knowledge Mngmnt Module

Demographics Module

Issue Tracking Module

DashboardModule

Email Module

Web Module

Admin Module

DiscussionThread Module

Work Order Module

Priority Module

Date/Time Translator Module

Automation Module

Security Module

Duplication Module

VM Module

Test Case Module

Audit Trail Module

File Attachment Module

Version 1 Version 2 Version 3


18

3.2 Product Position Statement

Section 3.2 demonstrates the product’s position statement, starting with the statement itself followed by a brief description. The intent is to communicate the objective and importance of the product with respect to the stakeholders concerned.

For

PTI’s employees and customers

Who

need enhanced issue tracking and submission, along with better means of communication, collaboration, and knowledge/information sharing,

The Home-grown complementary application

is a complete, robust issue tracking system

That

allows users to comprehensively share and manage reported issues and defects.

Unlike

other alternatives such as Bugzilla and HP Quality Center,

Our product

is more inclusive and provides more mature issue tracking, submission, and overall effectiveness.

Due to the needs of PTI’s customers and employees for an effective issue tracking system along with enhanced communications, collaboration, and knowledge sharing support, a home-grown integrated system that integrates with IssueTrak will help these stakeholders to manage their daily tasks effectively. The new system will have many features such as advanced searches and automation of some of the tasks associated with issue tracking and reporting, along with customizable features to fit the different types and levels of stakeholders. The most important benefit of this system is enabling effective and timely issue tracking with ease of use across the different geographical boundaries (wherever customers are located). Using the new system will enable PTI to deal with software issues in a timely manner which will result in minimized downtime and, consequently, will result in higher customer satisfaction. Unlike other commercial issue tracking systems, our system will be built to address the shortcomings and the specific needs of PTI. Additionally, it will extend the functionality of issue tracking to include better communications and to promote knowledge sharing among the employees around resolving employee and customer’s software issues. Moreover, users will have an easy to use system to report any software issues (they can simply report an issue by email and that will turn into a ticket to deal with the issue). Users will also be able to monitor the status and progress of their reported issues, in addition to instructions on any work-around for the issue. This transparency will help assureeveryone that their issues are being dealt with efficiently, effectively, and in a timely manner.


19

3.3 Summary of Capabilities

This section summarizes the key benefits and supporting features of the proposed product in an easy-to-read table format.

Customer Benefit Supporting Features System ease of use • Ability to add issue/defect easily and efficiently

• Browser based access via the internet • Ability to work offline • Web-based system administration • Customizable forms • Ability to report issues by email • Ability to log subsequent email correspondence in the issue record • Customizable selectable system options that fit different users

abilities and preferences • Ability to automatically close issues/tickets or change status based on

pre-defined criteria • Customized views based on department, hierarchy, etc. • Smart issues tracking by automatic search for duplicates • Ability to generate test cases from an reported/resolved issue. • Ability to view who’s testing what module on what machine. • Ability to view test phases and ticket progress • Ability to support users’ different time zones. (all dates and times will be

converted to the local time zone of the logged in user; this is read from user profile/settings)

• Automatically assign issues to individuals or groups using pre-defined criteria such as issue type, project, dept, etc.

Effective issue tracking • Ability to view test phases and ticket progress • Ability to support users’ different time zones. (all dates and times will be

converted to the local time zone of the logged in user; this is read from user profile/settings)

• On the fly (ad-hoc) user defined fields that can also set to private • Automatically assign issues to individuals or groups using pre-defined

criteria such as issue type, project, dept, etc. • Ability to configure email triggers • Ability to attach files • Ability to report issues by email • Ability to log subsequent email correspondence in the issue record • Automatically assign issues to individuals or groups using pre-defined

criteria • Ability to schedule work on issue and receive email reminders • Ability to subscribe to issues/ticket for email updates on status/progress • Automatic approval requests are sent to gatekeepers/personnel • Automatically assign issues to individuals or groups using pre-defined


20

criteria such as issue type, project, dept, etc. • Ability to have automatic notifications when action is required

Enhanced transparency • Ability to view test phases and ticket progress

• Automatically generate reports • Manual custom reports generation generate • Audit trail and changed history • Ability to subscribe to issues/ticket for email updates on status/progress

Enhanced security • On the fly (ad-hoc) user defined fields that can also set to private. • Field-level security • Administrative ACL for enhanced security • Audit trail and changed history •

Time saving & Enhanced efficiency

• Ability to report issues by email • Ability to log subsequent email correspondence in the issue record • Automatically assign issues to individuals or groups using • pre-defined criteria • Ability to schedule work on issue and receive email reminders • Ability to view who’s testing what module on what machine • Ability to add issue/defect easily and efficiently • Ability to generate test cases from an reported/resolved issue. • Ability to have automatic notifications when action is required

Strategic planning • Automatically generate reports • Manual custom reports generation generate • Running dashboard for senior level

management

Enhanced knowledge sharing • Searchable knowledge base • Ability to view discussion threads

3.4 Assumptions and Dependencies

Here, we review potential assumptions that, if changed, will alter the vision for the product.

• One area of concern is the level of buy in from upper management. With the exception of the CTO, the rest of the leadership team does not view the current inability to collaborate, communicate, and share information in the manner in which the QA and development teams do. The leadership team needs to understand the benefits of moving forward and embracing a new and improved system; otherwise it is possible that they may only agree to modest changes in the current environment.


21

• Since the potential solution touches many different departments, it is essential that the users play a big role in testing and validating the requirements as they are incrementally rolled out.

• Having the available resources to work on and implement the new system poses a challenge. PTI will need to assess current workloads in order to maximize resources.

• An open source and highly flexible object oriented programming language such as Java

is recommended.

• An impact analysis should be initiated to insure that the new system will not negatively impact the current infrastructure. The analysis should include but not be limited to, the current software and hardware database capabilities, potential bandwidth limitations, and any security vulnerabilities.

3.5 Cost and Pricing

The cost of the proposed home-grown complementary application should not be too much of an issue. Since this is both an internally and externally developed web-based system and is founded upon existing applications, much of the necessary requirements and features are already built in. A lot of added functionality will come from upgrading the third-party’s software which will not be too much more expensive than PTI has already budgeted and currently pays for. The rest of the additional costs come as personnel resources, and another developer may need to be hired. Assuming that PTI has enough money to hire a new employee or contract out the additional work until the product is completely implemented, the end result costs of maintenance and support should be similar to what they are currently paying.

4. Feature Attributes Features have attributes that provide additional project information that can be used to evaluate, track, prioritize, and manage the product items proposed for implementation. This section need describe only the attributes you've chosen and their meaning, so all parties can better understand the context of each feature.

4.1 Status

The status is set after negotiation and review by the project management team. Status information tracks progress during definition of the project baseline.

Proposed: Used to describe features that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management, and user or customer community

Approved: Capabilities that are deemed useful and feasible and have been approved by the official channel for implementation

Incorporated: Features incorporated into the product baseline at a specific time


22

4.2 Priority

Product priorities (benefits) are set by the marketing team, the product manager, or the business analyst. Ranking features by their relative priority to the end user opens a dialogue with customers, analysts, and members of the development team. Priorities are used in managing scope and determining development priority. One possible prioritization scheme follows.

Critical: Essential features. Failure to implement means that the system will not meet customer needs. All critical features must be implemented in the release, or the schedule will slip.

Important: Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in another way. Lack of inclusion of an important feature may affect customer or user satisfaction or even revenue, but release will not be delayed due to lack of any important feature.

Useful: Features that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue loss or customer satisfaction impact can be expected if such an item is not included in a release.

4.3 Effort

The level of effort is set by the development team and used in managing scope and determining development priority. Because some features require more time and resources than others, estimating the number of team- or person-weeks, lines of code required, or function points, for example, is the best way to gauge complexity and to set expectations of what can and cannot be accomplished in a given time frame.

4.4 Risk

The development team sets the level of risk, based on the probability that the project will experience undesirable events, such as cost overruns, schedule delays, or even cancellation. Most project managers find categorizing risks as High, Medium, and Low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the project team's schedule estimate.

4.5 Stability

The analyst and development team sets the stability attribute, based on the probability that the feature will change or the team's understanding of the feature will change. This information is used to help establish development priorities and to determine those items for which additional elicitation is the appropriate next action.

4.6 Target Release

The target release attribute records the intended product version in which the feature will first appear. This field can be used to allocate features into a particular baseline release. When the target release is combined with the status field, your team can propose, record, and discuss various features of the release without committing them to development. Only features whose


23

status is set to Incorporated and whose target release is defined will be implemented. When scope management occurs, the target release version number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

4.7 Assigned To

In many projects, features will be assigned to "feature teams" responsible for further elicitation, writing the software requirements, and implementation. This simple list will help everyone on the project team better understand responsibilities.

4.8 Reason

This text field is used to track the source of the requested feature. Features exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

5. Product Features This particular section serves to record the home-grown complementary application’s features which allow the system to provide the necessary capabilities for the user benefits as discussed in sections above. They will be detailed at a high enough level so that application complexity is effectively managed, and they will serve as the fundamental basis for product definition, scope management, and project management. For ease of readability, they are provided in the table below:

ID Feature Effort Risk 1 Ability to add issue/defect easily and efficiently Low Low 2 Ability to track issues/defects Medium Low 3 Automatically generate reports High Medium 4 Manually generate reports Medium Low 5 Searchable knowledge base Low Low 6 Browser based access via the internet Low Low 7 Ability to configure email triggers Medium Low 8 Administrative ACL for enhanced security Low Low 9 Audit trail and change history Medium Low 10 Running dashboard for senior level management High High 11 Inactivity notifications Medium Low 12 Auto generate work order numbers Medium Low 13 Manual percent complete indicator High High 14 Individualized work order view based on log in credentials Medium Low 15 Ability to work off line High High 16 Discussion thread view High High


24

17 Ability to attach files Medium Low 18 Web-based system administration Medium Low 19 Field-level security Medium Medium 20 Customizable forms High Medium 21 Ability to report issues by email Medium Medium 22 Ability to parse data from emails and convert it to a ticket High High 23 Ability to log subsequent email correspondence in the issue record High High 24 Ability to bill time to the issue tickets High High 25 Ability to schedule work on issue and receive email reminder Medium Medium 26 Ability to subscribe to issues/ticket for email updates on status/progress High High 27 Ability to have automatic notifications when action is required Medium Low 28 Automatic approval requests are sent to gatekeepers/personnel Medium Low 29 Ability to track issues from submission to completion High High 30 Customizable selectable system options that fit different users abilities and preferences High High 31 Ability to automatically close issues/tickets or change status based on

pre-defined criteria High High 32 Customized views based on department, hierarchy, etc. Low Low 33 Intelligently track issues and automatically search for duplicates High High 34 Ability to relate/reference issues based on type/module High High 35 Ability to Edit existing issue (change description, priority, ownership, close, reopen,

etc.) Low Low 36 Ability to generate test cases from an reported/resolved issue. High High 37 Ability to view who’s testing what module on what machine High High 38 Ability to view test phases and ticket progress Low Low 39 Ability to support users’ different time zones. (all dates and times will be converted to

the local time zone of the logged in user; this is read from user profile/settings) Medium Low 40 On the fly (ad-hoc) user defined fields that can also set to private. Medium Low 41 Ability to support customer specific views so they can track their own issues High High 42 Ability to create templates for the issue reporting process. Medium Low 43 Automatically assign issues to individuals or groups using pre-defined criteria such as

issue type, project, dept, etc. Medium Low

6. Exemplary Use Cases This final section serves to provide the business use case diagram and two additional process use case diagrams for specific features. Since a complete set of use cases will be provided in the use-case model that forms part of the requirements specification soon to come, we will only provide an overview of how the system works here.


25

6.1 Business use-case

Figure 1 shows the business use case model for PTI operations involving the issue tracking systems and users' needs within this business environment. PTI’s customer is shown as a business actor because of her/his ability to limitedly but directly interact with the system. A Super User (Systems Administrator) was introduced into the environment to perform system maintainance and account managment.

6.2 Feature 1 - Ability to Add Issue All PTI Employees should have the ability to report an issue through the issue tracking system. Issue Reporting is the main feature of the issue tracking system that will be utilized by many different users within the company and, therefore, needs to accommodate their needs in the most effective way. The system will be set up so that the user's first step will be to use the


26

knowledge base to search if the issue has already been reported. This process will minimize duplicate work and encourage information reusablity. Depending on the search results, the user will be able to Add New Issue, Template an existing one, or Reopen a Closed one.

6.3 Feature 2 - Ability to Edit Issue Developers and Testers need to be able to Edit reported issues in terms of text (description), severity, ownership, status, etc. Submission of any change will send an email notification to the newly assigned user and approval process gatekeepers. Knowledge Base system will be utilized to locate reported issues. Notification groups creation will be handled by another feature and will be heavily utilized to reduce the risk of information overload across the organization.


27

vision document - drexel universityal495/eport/docs/info627visiondocument.pdf · the vision...

Documents