1

Table of Contents

System Prototype...............................................................................2

Part I: Main Menu..............................................................................................................3

Part II: Project Information................................................................................................3

System Recommendation...................................................................4

Part III: Transmittal Letter..................................................................................................5

Part IV: Executive Summary...............................................................................................6

Part V: Detailed Results of Analysis....................................................................................7

Part VI: Systems Alternatives...........................................................................................10

Part VII: Systems Analysts’ Recommendations................................................................11

Part VIII: Proposal Summary............................................................................................15

Appendix A: System Proposal...........................................................17

Part I: Service Request.....................................................................................................18

Part II: Goals and Objectives............................................................................................21

Part III: Feasibility Study...................................................................................................22

Appendix B: Business Analysis..........................................................32

Part I: Conduct of Analysis...............................................................................................33

Part II: Software Requirements Specification (SRS)..........................................................35

Part III: Infrastructure Analysis.........................................................................................50

Appendix C: Systems Analysis...........................................................54

Part I: Use Case................................................................................................................55

Part II: Activity Diagrams..................................................................................................66

Part III: Class Diagram......................................................................................................75

Part IV: Sequence Diagram..............................................................................................76

2

System Prototype

3

Part I: Main Menu

Part II: Project Information

4

System Recommendation

5

Part III: Transmittal Letter

May 4, 2015

Spiros Veliantis

California Department of Technology

1325 J Street #1600

Sacramento, CA 95814

Professor Velianitis,

Our team has gathered the necessary information to build an integrated website and database to meet the California Department of Technology’s requirements. Team One has determined that all your requests for the website and database applications are feasible. Therefore, Team One will create a website and database application to meet the standards that the California Department of Technology needs for long term success.

During the duration of the Spring Semester, Team One has gathered the necessary information and design requirements to begin working on the first half of the Systems Development Life Cycle for this project. Team One will start work on the design and implementation during the Fall Semester. The final applications will not be operational and ready for use until November 2015. I hope this still meets your approval. If not, contact us immediately so we can determine an alternative course of action.

Team One will stay in constant contact and provide periodical updates on the progress of the project to confirm the standards and applications used meet the California Department of Technology’s approval.

Sincerely,

Thang Nguyen x

Darrell Nygard x

David Scott x

Matthew Gibbs x

Nick Grant x

Yen Tran x

6

Part IV: Executive Summary

A. Description of the Problem

A problem exists when there is a difference between the expected performance of software, and the relatively poor actual performance of the software. Team One identified no problems with the CA-PMM tool kit since the software performs as expected. However, Team One identified several potential opportunities to improve the tool kit. One opportunity is accessibility. Currently, IT Project Managers have trouble accessing the correct version of the CA-PMM tool kit quickly and easily. As an excel file, the tool kit uses the file based approach to storage, and comes with all the disadvantages of a file based system. Examples of disadvantages include data redundancy, data inconsistency, data isolation, data atomicity, data dependence, data sharing, data security. Each of these factors affect accessibility to some degree. Accessibility could be improved by changing from a file based storage system to an application with a database solution. Another opportunity presented is that of sharing an collaboration. Sharing is also affected by the use of a file based system (discussed above). In particular, sharing is affected by the following disadvantages of the file based system: data sharing, data redundancy, and data inconsistency. Even if team members share the excel file using a cloud service (e.g. Google Drive, Dropbox), if they try to access the file at the same time they could run into issues merging the files when multiple versions of the same document are created. Synchronous collaboration would solve these issues, but the software providing synchronous collaboration with microsoft excel files (Office 365 and Google Sheets) also have reduced functionality, and would not meet the requirements of the CA-PMM tool kit. The final opportunity presented was a user interface. Since the current toolkit is made in excel, there is plenty of room for improvement when it comes to designing the interface. Three areas of improvement include organizing, economizing, and communicating using a GUI interface. When it comes to organization, consistency and navigability could especially use some improvement.

B. Proposed Solution

Team One will create a fully functioning and dynamic web application where Project Managers will be able to create, access, and edit multiple projects. Project Managers will have the capability to create accounts for new users, grant users access to their projects, and set authorizations for these users (i.e., view, edit). Within each project, users will be able to access web forms where they can update the content of the CA-PMM toolkit for their project. Team One will create a database where the data submitted in the web application will be stored, reducing data redundancy. Since forms will be automatically updated when opened or refreshed, data inconsistency will also be reduced. Application Administrators will be given full access to every account, project, and form in the database to assist users with technical issues, make necessary changes to projects if a manager becomes unavailable, and archive user accounts.

7

C. Cost / Benefit Summary

Team One will develop the software using Microsoft SharePoint and SqlServer for free so these costs will be zero. In addition, all servers will be leased so new hardware costs will also be zero. The main expenses will be that of the salaries of the new employees that will maintain the information system and the new user training of this application. In addition there will be annual recurring costs for storage backup, incremental communication, and leasing of the application, web, and database servers. However, after looking at key financial statistics and ratios, Team One estimates that this application should result in an annual financial benefit of $677,360.85.

D. Implementation Time Frame

Team One determined the requirements of the project in the Spring semester. Team One analyzed business processes, scope, and design requirements of the web application and the database. With that in mind, Team One will be building a proof of concept of the prototype that will be partially functional and will be presented May 11, 2015. We will demonstrate the input of information of the web application and continually check the application and database for any bugs or security issues.

In the fall semester, Team One will make any necessary and requested changes to the design of the web application and database in the first two to three weeks as long as it is economically feasible to implement. After having tested and refined all requirements of the prototypes in six to seven weeks, Team One will install the actual implementation of the web application and database. The following two weeks will be dedicated to assisting the client in testing all aspects of the web application and database to ensure overall satisfaction. In the last two to three weeks of the semester, Team One will document all components and implement the applications. If the programs’ use is met with satisfaction, Team One will close down the project and evaluate the overall success of the project.

E. Outline of Systems Study

During the course of the Spring semester, Team One was went through the planning and analysis phase of the Systems Development Life Cycle of the project. In the fall semester, Team One will move on to the design, implementation, and providing support after the close down of the project. The time frame for this project comes to roughly six months. The client finds this deadline acceptable for the time being.

Part V: Detailed Results of Analysis

A. System Proposal

The System Proposal report will gather information about the proposed solution that we will be giving to our clients. In order to gather information for the report, we will need to find out what our clients desire by meeting up with them. We will then organize and collect the information to propose a database solution that will be necessary for their needs. Once we have a better understanding of our

8

clients’ needs, we will ask for more information on what else they would want to add to the project. After we have established the client's’ core needs for the proposed system, we can create a wishlist of functionalities that can be implemented at a later date. For example: a client might propose we add a time and date stamp on project edits or add project manager permissions within the application. At the final client review of the proposed system, we can check to see if there are any additional functionalities that could be expanded further or made better. Only then will we release the final version to the client. For more information, check out the System Proposal report in Appendix A.

B. Business Analysis

We also performed a Business Analysis to describe the information system’s business requirements. In this report, we summarize our data collection methods in the section titled Conduct of Analysis. We heavily relied on documentation for the existing CA-PMM. Specifically, our team primarily used the CA-PMM Reference Manual and the CA-PMM Template Instructions in our analysis. We also used the existing excel template to identify features that would be necessary in the new web application.

We outlined the system’s business requirements in the Software Requirements Specification. This section identifies the application’s external interfaces, functions, usability requirements, required performance, logical database requirements, design constraints, and software system attributes. The external interfaces from our application include users, hardware, and software. Humans interact with the interface through sight, sound, and motion. The application will interact with client hardware and software through a browser, making it so we do not have to consider which operating system the client will have. The server side of the application will need to operate within the Sharepoint framework, which requires an up to date Windows Server with integrated ASP.NET and Internet Information Services (IIS), as well as SQL Server. The functionality of our system essentially includes creating and managing accounts for users, creating and assigning users to projects, editing and managing projects, and editing forms within projects. Usability was measured across success factors, such as consistency, efficiency and ease, format and flexibility, as well as usability characteristics like the type of user, task, system and environment. Our performance section identified required performance factors across five essential functions, such as database response time and system dependability. For logical database requirements, we estimate that we will need to allow 2,000 to 2,500 accounts to assign individuals to about 500 projects per year.

Finally, we described the system architecture in the Infrastructure Analysis. The hardware required for our application includes a Web Server and a Database server. It will also require a client computer with an Internet connection. The software we will use includes a virtual machine to install the application in an independent operating system, Windows Server with IIS and ASP.NET in integrated mode, SQL Server, and Sharepoint services. For development, we will use Sharepoint Designer and Visual Studio, and we will code in Visual Basic, HTML, and an imported library of code from Sharepoint Designer.

For more information, reference the full Business Analysis at Appendix B.

9

C. Systems Analysis

We performed a Systems Analysis to describe the relationships between users, the application, and the database itself. In the Systems Analysis we had to think critically about each relationship and all the interactions therein. Our Use Case diagram is crucial to our understanding of each function between the team members, project manager, database administrator, and entities throughout the proposed application. Each application entity is detailed in the Use Case descriptions, as are each user-application relationship in the Activity Diagrams. The Class Diagram outlined the methods and fields of the application, while the Sequence Diagram details the order of events for activities and conditional statements performed by the system’s various components, including the user, application, SharePoint, and the database.

For more information, check out the complete Systems Analysis in Appendix C.

10

Part VI: Systems Alternatives

Below is a list of the information technology solutions we considered. The first column lists the potential technology included in the information system. The second column provides a short description of how each solution operational problems or opportunities.

Information System Alternatives Operational Benefits

A. ASP.NET with Sharepoint

Developer Tools: Visual Studio, Sharepoint DeveloperCode Languages: Visual Basic, HTML, CSS, Sharepoint LibraryHardware: Client device, (Virtualized) Web Server, Application Server,

Database ServerOperating System: Installed in a Virtual MachineServer Technologies: Windows Server (IIS / .NET Framework in

integrated mode), SQL Server

This option provides effective collaboration between users and significantly improving productivity due to better planning and control. Initial costs will be zero but recurring costs will rise to maintain the system. The recurring costs will be negligible due to increased productivity. SharePoint is easy to implement, this is the best option and our recommendation.

B. ASP.NET

Developer Tools: Visual StudioCode Languages: Visual Basic, HTML, CSSHardware: Client device, (Virtualized) Web Server, Application Server,

Database ServerOperating System: Installed in a Virtual MachineServer Technologies: Windows Server (IIS and .NET Framework), SQL

Server

This alternative would require a significant amount of coding in Visual Basic and the .NET framework, lengthening the project timeline for essentially the same desired result as the Sharepoint solution.

C. PHP

Developer Tools: SublimeTextCode Languages: PHP, HTML, CSSHardware: Client device, (Virtualized) Web Server, Application Server,

Database ServerOperating System: Installed in a Virtual MachineServer Technologies: Apache (web server), MySQL Server (database server)

This alternative would also require a significant amount of coding for essentially the same desired result. PHP is widely used, thus, support would be plentiful but for ease of integration, we do not recommend this option.

D. Excel Template File (Current Solution)

Developer Tools: NoneCode Languages: NoneHardware: Client DevicesOperating System: AnyServer Technologies: None

This alternative would keep the current system as is but as discussed previously, hinders collaboration between users and will inhibit project timelines from completion. Staying with the current system would keep initial costs down but ultimately end up costing more in the long run due to limitations on collaboration. We do not recommend this option.

11

Part VII: Systems Analysts’ Recommendations

A. Summary of the Proposed System and Operational Benefits

Our team will create a web application where Project Managers will be able to create, access, and edit multiple projects. Project Managers will also be able to create accounts for new users, grant users access to their projects, and set authorizations for these users (i.e., view, edit). Within each project, users will be able to access web forms where they can update the content of the CA-PMM toolkit for their project. The data submitted through a form will be stored in a database, reducing data redundancy. Since forms will be automatically updated when opened or refreshed, data inconsistency will also be reduced. Application Administrators will be given full access to every account, project, and form in the database to assist users with technical issues, make necessary changes to projects if a manager becomes unavailable, and archive user accounts.

These features are meant to address three opportunities we identified to improve the CA-PMM toolkit. These opportunities are 1) improved accessibility, 2) improved sharing and collaboration, and 3) improved performance. Since our solution is a web application, users will be able to access an up to date version of the toolkit from any device with internet access. In addition, if they are working on multiple projects, they could access each of those projects from the same application. Collaboration is improved by the ability to add multiple users to a project, and to create authorizations for those users. In this way, Project Managers can authorize various users to work on certain projects, and users can update different forms for the same project at the same time. Since the data is stored in a database, they will not have to think about how to save the data and share it with other users. They can just focus on completing work. Improved performance refers to the performance of users and not the system. We expect users to be quicker and more effective when we create a streamlined and consistent user interface. We also expect more accurate inputs by providing data validation. The fact that managers or team members can access and review work immediately means performance should be improved. Also, we expect to cut some time by automatically populating fields in some forms with the data from other forms.

We chose to develop the web application using Microsoft’s SharePoint technology. SharePoint was developed by Microsoft to increase the accessibility and effective use of information within organizations. SharePoint is closely integrated with ASP.NET and Internet Information Services (IIS). For example, a SharePoint Web Application will typically create a single corresponding Website (though it can span multiple websites) in the IIS framework, and a SharePoint web page is actually an ASP.NET web page. Most of the content will be developed in SharePoint Designer to expedite development, though some pages will require custom modification in Visual Studio. The coding languages we plan to use include Visual Basic, HTML, and possibly some java script. Java script will allow us to create interactive web sites through client side scripting. We will also heavily rely on Microsoft’s InfoPath application to create customized forms which users can access using the front end GUI of the SharePoint web site.

12

When the user submits (the whole form) or updates (part of a form), the data will update a SharePoint list stored on the database. When other InfoPath forms are opened with fields using the same data, the fields will be populated with the updated data.

We will install the application in a Virtual Machine. Virtual machines allow one operating system to be opened within another operating system, so users will not have to reboot the machine to manage the application. Sharepoint requires that IIS and ASP.NET be installed in Integrated Mode, so they function as a single platform. Also, SharePoint stores its lists, libraries, content types, and field types in SQL Server, so we will need to install an up to date version of SQL Server. For development purposes, we will continue to use the server available in Professor Velianitis’ office on the CSUS campus via Virtual Private Network (VPN). This server already has Windows Server installed, which will allow us to virtualize the Web Server and Database server. We will also develop the application independently of any existing SharePoint information system within the California State Government, and consider possible integration at a later date.

B. Cost / Benefit Analysis

For the fiscal year ending June 30, 2016, the State of California budgeted expenditures of $373,006,000 for the Department of Technology. In addition, the Department of Technology is tracking active projects with a total expected cost of $4,624,072,501. Improving the CA-PMM promotes the efficient and effective management of these resources, and could result in significant benefits. The estimated costs and benefits are broken down below.

i. Benefits

Most of the tangible benefits related to the CA-PMM are cost reductions. The benefits of improved project outcomes are still intangible since we cannot easily estimate them. For this reason, we will focus on calculating the financial benefit of reducing project costs. In order to identify the annual benefit, we decided to determine the expected total annual cost, estimate the percentage reductions of the cost when our information system is implemented, and then calculate the annual benefit. The expected annual cost was calculated based on the active projects on March 27, 2015. To take the data from projects active on a single date and extrapolate it to represent an annual amount is not an optimal estimation procedure, but it was the best available with the data we found online. To estimate the annual cost, we took the total amount for each of the projects, and divided each by their estimated duration. We estimate only about five percent of this amount can be affected through more efficient and effective use of the CA-PMM toolkit. Of this five percent, we calculated benefits by estimating increased productivity due to several key factors. Due to the new user interface, easier access, and collaboration, the time need to work on the tool kit should decrease, resulting in an increase in productivity of 0.25%. We expect that the enhanced user interface and central storage provided by the database should reduce errors, increasing productivity by an additional 0.25%. We also expect a 0.50% increase in productivity due to better planning and control as a result of the improved tool kit. Overall, this should result in an annual financial benefit of $677,360.85.

13

i. One Time Costs

Our team will develop the software for free so these costs will be zero. In addition, all servers will be leased so new hardware costs will also be zero. Site preparation will be zero dollars since the software will not be used in a particular location, but rather via the web over user’s devices. We will not have to invest in additional software either. There will be no upfront costs for this application.

i. Recurring Costs

The most expensive recurring cost will be the salary for the new employees who will maintain the information system. We expect this cost to be around $120,000 to cover each of their $60,000 annual salaries. User training will also be expensive. We calculated that there would be an average of 8.46 new projects per year (44 projects / 5.22 years average development). If project managers for these new projects have an average billable rate of $150 per hour, and the user training takes four

Annual Project Cost * 1,354,721,690.45$ Percentage Attributable to CA-PMM 5%Cost Attributable to CA-PMM 67,736,084.52$

Category In $US% Increase in Productivity

Cost reduction or avoidance -$ 0.00%Error reduction 169,340.21$ 0.25%Increased flexibility -$ 0.00%Increased speed of activity 169,340.21$ 0.25%Improvement in management planning and control 338,680.42$ 0.50%Other -$ 0.00%

Total Tangible Benefits 677,360.85$

Tangible Benefits

*Annual project cost is based on a calculation of the total annual cost of projects under construction on March 27, 2015. Since our sample only includes projects active on a single day, it is more likely to exclude short term projects. Since projects with shorter development periods have less risk, the tangible benefits associated with the sample selected should be relatively larger. Therefore, our estimation should be conservative since it may exclude projects that would have less tangible benefits.

Category In $USDevelopment costs -$ New hardware -$ New software -$ Site preparation -$ Other -$

Total Tangible One-Time Costs -$

Tangible One-Time Costs

14

hours, then the average annual cost of user training should be $5,076.90 ($150 per hour x 4 hours = $600 per project x 8.46 projects). The only necessary incremental storage will be to store a backup of the application, user documentation, and technical documentation. This storage should be minimal, so we estimate it to cost around $6,000 per year. Incremental communication will be necessary to provide support for the application. We estimate this cost to be around $7,000 per year. In addition, we expect to have about $40,000 per year to lease application, web, and database servers. Overall, the annual recurring cost will be $178,076.90.

C. NPV Analysis

For our net present value analysis, we chose a discount rate of 6.00%. This rate is appropriate for this project since it is low risk. We used the results of our cost / benefit analysis to perform this calculation. Based on this calculation, our project will result in cumulative discounted cost savings of $462,299.95 in the first year of implementation, and roughly $1,993,496.02 by the end of the fifth year after implementation. Even after discounting cash flows, the benefits outweigh costs both in the short term and long term.

Using the net present value, we can also calculate the Return on Investment by taking the cumulative NPV and dividing it by the cumulative PV of all costs. Even though this application would be used indefinitely, since there were no upfront cost and the annual benefits and costs never change the ROI will never change no matter how long the project lasts. The overall return on investment is 280.38%. This is an outstanding return.

Category In $USApplication software maintenance 120,000.00$ User training 5,076.90$ Incremental data storage required 6,000.00$ Incremental communications 7,000.00$ New software or hardware leases 40,000.00$ Supplies -$ Other -$

Total Tangible Recurring Costs 178,076.90$

Tangible Recurring Costs

15

Part VIII: Proposal Summary

In a request from the California Department of Technology, Team One has decided to create a web application and database in compliance to the standards of the state department. Of those standards, Team One will be implementing a web application where Project Managers will be able to create, access, and edit multiple projects. Project Managers will have access to create accounts, grant users access to their projects, and set authorizations. Users will have access to the web forms to update the content of the CA-PMM toolkit for their project. A database will be created to store information and reduce data redundancy. Finally, administrators will have full access to every account to assist users with needs that may arise. Due to insufficiencies with the current CA-PMM toolkit, Team One’s primary focus is to create a whole new web application and database that is sufficient, reliable, and easy-to-use. Team One has effectively analyzed both the business and system portions of the project and has determined the necessary steps to build an integrated database for the California Department of Technology.

Discount Rate: 8.00%

YEAR OF PROJECT >>> 0 1 2 3 4 5Discount Rate 100.00% 92.59% 85.73% 79.38% 73.50% 68.06%

Net economic benefit -$ 677,360.85$ 677,360.85$ 677,360.85$ 677,360.85$ 677,360.85$ PV of Benefits -$ 627,186$ 580,728$ 537,711$ 497,880$ 461,000$ Cumulative PV of Benefits -$ 627,186$ 1,207,914$ 1,745,625$ 2,243,505$ 2,704,505$

One-time COSTS -$ -$ -$ -$ -$ -$ Recurring Costs -$ (178,076.90)$ (178,076.90)$ (178,076.90)$ (178,076.90)$ (178,076.90)$ PV of Costs -$ (164,886.02)$ (152,672.24)$ (141,363.18)$ (130,891.84)$ (121,196.15)$

-$ (164,886.02)$ (317,558.26)$ (458,921.44)$ (589,813.28)$ (711,009.43)$

NPV -$ 462,299.95$ 428,055.51$ 396,347.69$ 366,988.60$ 339,804.26$ Cumulative NPV -$ 462,299.95$ 890,355.46$ 1,286,703.15$ 1,653,691.76$ 1,993,496.02$

ROI 280.38% 280.38% 280.38% 280.38% 280.38%

Economic Feasibility Analysis - Customer Tracking System ProjectCost Benefit Analysis using Present Value

0 1 2 3 4 5NPV $- $462,299. $428,055. $396,347. $366,988. $339,804.Cumulative NPV $- $462,299. $890,355. $1,286,70 $1,653,69 $1,993,49

$-

$500,000.00

$1,000,000.00

$1,500,000.00

$2,000,000.00

$2,500,000.00

16

A prototype has been constructed to demonstrate how the final product will function when the project is ultimately finished. The tools used in this end product include Microsoft Sharepoint and SqlServer. All the necessary tools Team One has used or plan on using require zero costs to the end users and should financially benefit the annual budget of the California Department of Technology. With the necessary tools, Team One has created a prototype version of the web application and database with the look and feel of the CA-PMM toolkit to perform the necessary functions previously mentioned. The new functionality will provide the end users with a web application that is simple to use and with a professional look. The final design and implementation will not be ready until the end of the Fall semester of 2015.

17

Appendix A: System Proposal

18

Part I: Service Request

A. Company Summary

Name: CA Department of Technology

Address: 1325 J Street

Suite 1600

Sacramento, CA 95814

Phone: (916) 319-9223

Contact: n/a

General Description:

The CA Department of Technology has the following mandated responsibilities:

●Advise the Governor on the strategic management and direction of the State’s information technology resources.

●Minimize overlap, redundancy, and cost in state operations by promoting the efficient and effective use of information technology.

●Coordinate activities of Agency Information Officers, agency Chief Information Officers, and the Director of OTech for purposes of integrating statewide technology initiatives, ensuring compliance with information technology policies and standards, and promoting alignment of information technology resources and effective management of information technology portfolios.

●Work to improve organizational maturity and capacity in the effective management of information technology.

●Establish performance management and improvement processes to ensure state information technology systems and services are efficient and effective.

The reorganization of the California Technology Agency into the California Department of Technology included the creation of the Statewide Technology Procurement Division, which manages procurement for the states IT projects.

B. Project Initiation Description

As of January 1, 2009, the California Department of Technology requires all IT Project Managers to use the California Project Management Methodology (CA-PMM). The CA-PMM toolkit is an excel

19

template that assists Project Managers in meeting the requirements of the CA-PMM. Our MIS 160 Professor, Spiros Velianitis, heard of some complaints from project managers about using this excel template, including the difficulty of sharing and accessing the tool kit. After reviewing the CA-PMM tool kit, he identified several issues and determined our class could create an effective solution to these issues. When he presented this potential project to the class, our team agreed to develop a software solution for this problem.

C. Business Drivers

1. Problems

A problem exists when there is a difference between the expected performance of software, and the relatively poor actual performance of the software. At this point, there are no identified problems with the CA-PMM tool kit since the software performs as expected.

2. Opportunities

An opportunity exists when there is a difference between the actual performance of software, and the potentially improved performance of the software. We identified several potential opportunities to improve the tool kit.

i. Accessibility

Currently, IT Project Managers have trouble accessing the correct version of the CA-PMM tool kit quickly and easily. As an excel file, the tool kit uses the file based approach to storage, and comes with all the disadvantages of a file based system. Examples of disadvantages include data redundancy, data inconsistency, data isolation, data atomicity, data dependence, data sharing, and data security. Each of these factors affect accessibility to some degree. Accessibility could be improved by changing from a file based storage system to an application with a database solution.

ii. Sharing and Collaboration

Sharing is also affected by the use of a file based system (discussed above). In particular, sharing is affected by the following disadvantages of the file based system: data sharing, data redundancy, and data inconsistency. Even if team members share the excel file using a cloud service (e.g. Google Drive, Dropbox), if they try to access the file at the same time they could run into issues merging the files when multiple versions of the same document are created. Synchronous collaboration would solve these issues, but the software providing synchronous collaboration with Microsoft Excel files (Office 365 and Google Sheets) also have reduced functionality, and would not meet the requirements of the CA-PMM tool kit.

20

iii. User Interface

Since the current toolkit is made in excel, there is plenty of room for improvement when it comes to designing the interface. Three areas of improvement include organizing, economizing, and communicating using a GUI interface. When it comes to organization, consistency and navigability could especially use some improvement.

3. Mandated Compliance

Compliance issues exist when the actual performance of the software does not meet mandated requirements. This project does not address any specific compliance issues, but by addressing the opportunities listed above, the software should assist project managers in meeting the CA-PMM requirements.

D. Anticipated Business Benefits

By improving the accessibility, sharing, and interface and moving from a file based storage system to a database storage system, we expect productivity to be significantly increased. Productivity is a function of both efficiency and effectiveness. Effectiveness is the successful completion of objectives, while efficiency is minimizing the resources needed to complete those objectives. For obvious reasons, improving accessibility and sharing will improve productivity when project managers need to use the tool kit on multiple devices, or when multiple users need to access the kit. In addition, allowing multiple users to easily access the tool kit will capitalize on the unique knowledge, skills, and experience of those members. By changing from a file based storage system, we can avoid the several disadvantages associated with such systems (data redundancy, inconsistency, isolation, atomicity, dependence, sharing, and security and program maintenance). By reducing the effort necessary to make sure the correct data is entered into the tool kit, we will significantly increase efficiency. In addition, we will reduce the risk that managers will rely on incorrect or out of date information, therefore increasing effectiveness.

E. System Capabilities

The new system needs to be accessible to many users on different devices in different locations. Multiple users will need to be able to access the system at the same time. Authentication and authorization will be necessary. It will be necessary for users to be able to create new projects within the system, as well as open and edit existing projects. An updated GUI is also a required capability. As mentioned before, we plan to address the organization of the user interface by improving consistency and navigability, though we also plan to address other factors related to organizing, economizing, and communicating on user interface.

We also have a wishlist for capabilities. It would be nice if we could make a tool for creating forms that could be sent to a client that would automatically update data in the system. Also, providing synchronous editing of a project would be a plus, though it may not be absolutely necessary.

21

F. Company Size and Locations

According to the California Governor’s Proposed Budget for the fiscal year ending June 30, 2016, the Department of Technology has 910.7 positions, and has total funds of $373,006,000.

G. Organizational Chart

The CA Department of Technology has eight departmental branches. See Figure 1 for an organizational chart of the Department of Technology, and Figure 2 for an organizational chart of the State of California. The Department of Technology is part of the Government Operations Agency. Our application will primarily serve the IT Project Oversight Division within the Department of Technology.

H. Transaction Types and Monthly Volumes

The monthly volume for this application is currently unknown, but we estimate that around five hundred projects will be managed on a monthly basis.

Part II: Goals and Objectives

A. Mission Statement

The IT Project Oversight and Consulting Division oversees the State’s IT project portfolio. To that purpose, we promote smart IT investments and effective project management practices. As a Capability Maturity Model Integration (CMM) certified organization, we standardize project management and offer advice on project management best practices.

B. Organizational Goals

1. Strategic Goals

Goal 1. Responsive, Accessible, and Mobile Government

Goal 2. Leadership and Collaboration

Goal 3. Efficient and Reliable Infrastructure and Services

Goal 4. Secured Information

Goal 5. Capable Information Technology Workforce

Goal 6. Responsive and Effective IT Project Procurement

2. Guiding Principles

Principle 1. Be Accountable

Principle 2. Be Service Driven

22

Principle 3. Collaborate & Cooperate

Principle 4. Understand Enterprise Value

Principle 5. Demonstrate Strong Leadership

C. Objectives

Objective 1. Increase the success rate of information systems projects by five percent, starting July 1, 2017.

Objective 2. Decrease the cost of completing information systems projects by ten percent, starting July 1, 2017.

Objective 3. Decrease the time needed to complete information systems projects by ten percent, starting July 1, 2017.

Part III: Feasibility Study

A. Operational Feasibility

When assessing the operational feasibility of an information systems project, it is important to have a clear understanding of the planned features of the information systems and their potential impact on business processes.

1. Functionality

In order to capitalize on the potential benefits listed in the opportunities section above (see Part I: Service Request, Business Drivers), including improving access, collaboration, and the user interface, we have identified several elements that need to be present in the new information system. Access to the application needs to be available over the web. In addition, multiple users will need to access the application at the same time. The information will need to be updated automatically, without the disadvantages of the file based storage system the excel tool kit relied on (data redundancy, inconsistency, isolation, atomicity, dependence, and sharing, and program maintenance). Authentication and authorization will also be necessary features.

Some optional (or wish list) features could potentially be implemented, but are not absolutely necessary for the information system to succeed in the organization. These features include creating desktop and mobile applications that sync with the online application. Also, allowing users to generate forms that could be sent to clients to fill out and update the database would be beneficial. A signoff and issue management feature could also be included to facilitate collaboration.

2. Impact on Business Processes

Making these changes to the functionality of the information system should not require substantial changes to business processes and structures, though it will require a few minor changes for

23

all project managers within the organization. Two ways the new information system will impact the organization’s processes include 1) the web application will require an internet connection, and 2) the flexibility provided by the excel application will be lost.

If the desktop application is not included in the system, then the web application will require a reliable internet connection to function. This could present a problem if the project managers visit client sites that do not have a reliable internet connection. However, this should not be too big of an organizational change since a reliable internet connection is also necessary for other applications a project manager will need to use.

Another issue is related to moving from excel. Excel is an extremely flexible application, and project managers could potentially edit the CA-PMM toolkit to perform their own analysis without leaving the program. They could not perform this type of flexible analysis in a web application. This should not impact the project managers activities too much, since they could open an excel spreadsheet separately to perform any of their own their own analysis if necessary.

3. Alignment with Organizational Goals

The functionality of the new application is in line with many of the Department’s goals. This includes promoting a responsive, accessible and mobile government, increased leadership and collaboration, providing efficient and reliable infrastructure and services, securing information, increasing the capability of their information technology workforce, and providing responsive and effective IT project procurement.

4. Operational Feasibility Summary

Since changes to the organization’s structures and procedures are not substantial and widespread, this project has low risk. In addition, the project aligns with organization’s goals.

Conclusion: The project is operationally feasible.

B. Technical Feasibility

1. Project Size

The project size is relatively small. There are only six members on the project team working part time to complete the project, the project duration is less than one year since it started in March 2015 and should be completed by December 2015, there should only be one organizational department involved when we do introduce the project to the CA Department of Technology’s IT Project Oversight and Consulting Division, and there will be no outsourcing involved.

24

2. Project Structure

Overall, the project structure should have a low level of complexity. The project is a renovation of an existing system with few changes to the requirements of the existing system. The requirements of the existing system are well defined, highly structured, and easily obtainable. We already discussed the organizational, procedural, and structural changes during operational feasibility. Users are already willing to accept the application and should be willing to participate in the development effort. We haven’t introduced the application to management, so we don’t know whether they will be committed to the new system. We already have an idea of the functionality users desire in the new application. Any further contact with users will be to clarify and make small adjustments to the functionality.

3. Development Group

The members of our group are already familiar with developing a web application from our experiences in MIS 120. The software we plan to use to develop the application include VB.NET and SQL Server 2008. We have extensive experience with Visual Studio after working with it in MIS 15 and MIS 120. We had some experience working with SQL Server 2008 in MIS 120. In addition, we should be getting much more experience in designing databases and working with SQL in MIS 150. In addition, the development team is familiar with the problems this information is faced with (e.g., poor user interface).

4. User Group

As IT project managers, the user group should be familiar with the information systems development process. In addition, many of them have proposed the change to a web application be made so they should be familiar with the application area. The use of the system will not change much. They will have to access the project over the web and create and manage the projects via the web application instead of with a file based storage system. They should be able to create and access their account fairly easily, and the project management functionality in the application should be easier than a file based storage system

5. Technical Feasibility Summary

The project size is relatively small and the project structure is not very complex. In addition, the development group and user group are sufficiently familiar with this type of project.

Conclusion: The project is technically feasible.

C. Economic Feasibility

1. Cost / Benefit Analysis

For the fiscal year ending June 30, 2016, the State of California budgeted expenditures of $373,006,000 for the Department of Technology. In addition, the Department of Technology is tracking active projects with a total expected cost of $4,624,072,501. Improving the CA-PMM promotes the

25

efficient and effective management of these resources, and could result in significant benefits. The estimated costs and benefits are broken down below.

i. Annual Benefits

Most of the tangible benefits related to the CA-PMM are cost reductions. The benefits of improved project outcomes are still intangible since we cannot easily estimate them. For this reason, we will focus on calculating the financial benefit of reducing project costs. In order to identify the annual benefit, we decided to determine the expected total annual cost, estimate the percentage reductions of the cost when our information system is implemented, and then calculate the annual benefit. The expected annual cost was calculated based on the active projects on March 27, 2015. To take the data from projects active on a single date and extrapolate it to represent an annual amount is not an optimal estimation procedure, but it was the best available with the data we found online. To estimate the annual cost, we took the total amount for each of the projects, and divided each by their estimated duration. We estimate only about five percent of this amount can be affected through more efficient and effective use of the CA-PMM toolkit. Of this five percent, we calculated benefits by estimating increased productivity due to several key factors. Due to the new user interface, easier access, and collaboration, the time need to work on the tool kit should decrease, resulting in an increase in productivity of 0.25%. We expect that the enhanced user interface and central storage provided by the database should reduce errors, increasing productivity by an additional 0.25%. We also expect a 0.50% increase in productivity due to better planning and control as a result of the improved tool kit. Overall, this should result in an annual financial benefit of $677,360.85.

Annual Project Cost * 1,354,721,690.45$ Percentage Attributable to CA-PMM 5%Cost Attributable to CA-PMM 67,736,084.52$

Category In $US% Increase in Productivity

Cost reduction or avoidance -$ 0.00%Error reduction 169,340.21$ 0.25%Increased flexibility -$ 0.00%Increased speed of activity 169,340.21$ 0.25%Improvement in management planning and control 338,680.42$ 0.50%Other -$ 0.00%

Total Tangible Benefits 677,360.85$

Tangible Benefits

*Annual project cost is based on a calculation of the total annual cost of projects under construction on March 27, 2015. Since our sample only includes projects active on a single day, it is more likely to exclude short term projects. Since projects with shorter development periods have less risk, the tangible benefits associated with the sample selected should be relatively larger. Therefore, our estimation should be conservative since it may exclude projects that would have less tangible benefits.

26

ii. One Time Costs

Our team will develop the software for free so these costs will be zero. In addition, all servers will be leased so new hardware costs will also be zero. Site preparation will be zero dollars since the software will not be used in a particular location, but rather via the web over user’s devices. We will not have to invest in additional software either. There will be no upfront costs for this application.

iii. Recurring Annual Costs

The most expensive recurring cost will be the salary for the new employees who will maintain the information system. We expect this cost to be around $120,000 to cover each of their $60,000 annual salaries. User training will also be expensive. We calculated that there would be an average of 8.46 new projects per year (44 projects / 5.22 years average development). If project managers for these new projects have an average billable rate of $150 per hour, and the user training takes four hours, then the average annual cost of user training should be $5,076.90 ($150 per hour x 4 hours = $600 per project x 8.46 projects). The only necessary incremental storage will be to store a backup of the application, user documentation, and technical documentation. This storage should be minimal, so we estimate it to cost around $6,000 per year. Incremental communication will be necessary to provide support for the application. We estimate this cost to be around $7,000 per year. In addition, we expect to have about $40,000 per year to lease application, web, and database servers. Overall, the annual recurring cost will be $178,076.90.

2. Payback Period / Break Even Point

Using the cost / benefit analysis from the prior section, we also calculated the payback. There are no benefits in year zero since the project is still in development. However this project will also have

Category In $USDevelopment costs -$ New hardware -$ New software -$ Site preparation -$ Other -$

Total Tangible One-Time Costs -$

Tangible One-Time Costs

Category In $USApplication software maintenance 120,000.00$ User training 5,076.90$ Incremental data storage required 6,000.00$ Incremental communications 7,000.00$ New software or hardware leases 40,000.00$ Supplies -$ Other -$

Total Tangible Recurring Costs 178,076.90$

Tangible Recurring Costs

27

no up front development cost. Since recurring annual benefits and costs start in year one of implementation, and annual benefits exceed annual costs, the breakeven point will be exactly the beginning of the application’s implementation.

3. Net Present Value (NPV)

For our net present value analysis, we chose a discount rate of 6.00%. This rate is appropriate for this project since it is low risk. We used the results of our cost / benefit analysis to perform this calculation. Based on this calculation, our project will result in cumulative discounted cost savings of $462,299.95 in the first year of implementation, and roughly $1,993,496.02 by the end of the fifth year after implementation. Even after discounting cash flows, the benefits outweigh costs both in the short term and long term.

Using the net present value, we can also calculate the Return on Investment by taking the cumulative NPV and dividing it by the cumulative PV of all costs. Even though this application would be used indefinitely, since there were no upfront cost and the annual benefits and costs never change the ROI will never change no matter how long the project lasts. The overall return on investment is 280.38%. This is an outstanding return.

Benefits of option 0 1 2 3 4Annual Benefits -$ 677,361$ 677,361$ 677,361$ 677,361$

Total Benefits -$ 677,361$ 677,361$ 677,361$ 677,361$ Costs of option 0 1 2 3 4

Initial Cost -$ -$ -$ -$ -$ Annual Recurring Cost -$ 178,077$ 178,077$ 178,077$ 178,077$

Total Costs -$ 178,077$ 178,077$ 178,077$ 178,077$ Net benefits/costs -$ 499,284$ 499,284$ 499,284$ 499,284$ Cumulative benefits/costs -$ 499,284$ 998,568$ 1,497,852$ 1,997,136$ Break Even Period in Years 1.00

Payback Analysis (CA-PMM Web Application)

28

4. Economic Feasibility Summary

Our application will have annual benefits of $677,360.85, initial costs of $- , and recurring annual costs of $178,076.90 . This results in a payback period / breakeven point of 1.00 year. The project will recoup its costs very quickly. After performing a NPV analysis, the cumulative net present value of the project for cash flows through the end of year five after the implementation is $1,993,496.02. Finally, we also calculated the Return on Investment. The overall ROI will be 280.38% regardless of the duration of the benefits of the project.

Conclusion: The project is economically feasible.

D. Schedule Feasibility

Since we were not contacted by the client, there is no particular deadline for this project. The deadline for our class will be December 2015. Our team is confident we can finish this project by that date. If we fall behind schedule, a group from the Spring 2016 class could potentially finish the project. The breakdown of the time necessary to complete major areas and meet milestone deadlines follows.

1. Planning

The planning phase is essentially complete after the submission of this feasibility study. We had to push back our milestone deadline for this phase since we had to reject our first potential project and choose a new one.

Discount Rate: 8.00%

YEAR OF PROJECT >>> 0 1 2 3 4 5Discount Rate 100.00% 92.59% 85.73% 79.38% 73.50% 68.06%

Net economic benefit -$ 677,360.85$ 677,360.85$ 677,360.85$ 677,360.85$ 677,360.85$ PV of Benefits -$ 627,186$ 580,728$ 537,711$ 497,880$ 461,000$ Cumulative PV of Benefits -$ 627,186$ 1,207,914$ 1,745,625$ 2,243,505$ 2,704,505$

One-time COSTS -$ -$ -$ -$ -$ -$ Recurring Costs -$ (178,076.90)$ (178,076.90)$ (178,076.90)$ (178,076.90)$ (178,076.90)$ PV of Costs -$ (164,886.02)$ (152,672.24)$ (141,363.18)$ (130,891.84)$ (121,196.15)$

-$ (164,886.02)$ (317,558.26)$ (458,921.44)$ (589,813.28)$ (711,009.43)$

NPV -$ 462,299.95$ 428,055.51$ 396,347.69$ 366,988.60$ 339,804.26$ Cumulative NPV -$ 462,299.95$ 890,355.46$ 1,286,703.15$ 1,653,691.76$ 1,993,496.02$

ROI 280.38% 280.38% 280.38% 280.38% 280.38%

Economic Feasibility Analysis (CA-PMM Web Application)Cost Benefit Analysis using Present Value

29

2. Analysis

i. Business Analysis

The milestone deadline for business analysis is April 15, 2015. This will be a difficult deadline to meet since our feasibility report was pushed out when we changed our project. Luckily, we have two people assigned to perform business analysis who think they can complete the activities in the required amount of time. The activities include conducting analysis, describing the user requirements, and defining infrastructure requirements. Unfortunately, none of these activities can be completed concurrently. As a result, we plan to work together on each activity to shorten the time needed to finish and move on to the next activity. Determining the conduct of analysis should take about three days. Identifying and defining user requirements and performing infrastructure analysis should take about two days each.

ii. Systems Analysis

The mile stone deadline for systems analysis is April 27, 2015. Activities related to this milestone include creating use case diagrams and activity diagrams for the existing system and the proposed system, as well as class diagrams and sequence diagrams for the proposed system. These tasks will be difficult to accomplish. However, we also have a full two weeks to complete the work and have two people who are confident they can complete the work. Other team members can be assigned to work on the systems analysis if necessary as well. In fact, we are planning on involving most our group in the systems analysis in some way so our entire group can have a clear understanding of the systems requirements during design and implementation.

iii. System Prototype and Interface

The milestone deadline for our system prototype and interface is May 6, 2015. We will have a total of four days after our systems analysis. We will not have much time to complete the activities related to this milestone, but most of the work will be guided by the activities from the systems analysis phase. Activities from this phase include prototyping the GUI interface, database, and reporting, as well as documenting installation and use instructions. Deliverables include a completed database (defined by UML diagrams from systems analysis), the completed main GUI interface and all sub menus and interfaces, a form and a report, and the installation and use documentation. We expect to be able to complete these requirements in the time allotted. We will also begin to consider the design of many of these deliverables during systems analysis, making it easier to meet this milestone deadline in such a short period of time.

iv. System Recommendation

The system recommendation can be completed concurrently with the system prototype and interface. The milestone deadline is May 7, 2015. Deliverables for this milestone include the Transmittal Letter, Executive Summary, Detailed Results of Analysis (updated Business Analysis and Systems

30

Analysis), Systems Alternatives, Systems Analysts’ Recommendations, Proposal Summary, and a Presentation. All of these deliverables can be worked on concurrently and will be broken up between four members of our group, two of which will also be working on the system prototype concurrently and can be flexibly reassigned. We expect the transmittal letter, executive summary, recommendations, and proposal summary to take one day each, the detailed results of analysis and systems alternatives to take three days each, and the presentation to take the full five days available. The presentation will be updated as work on the system prototype and system recommendations is completed.

3. Design and Implementation

Design and implementation will be performed during the Fall 2015 semester in short, incremental cycles providing changing features with each iteration. It is impossible to provide specific deadlines at this point. However, based on the preliminary system requirements, the size of the project, and the developer’s familiarity with the technology we will be using, we should be able to come up with a solution in the time allotted between September and December 2015.

4. Schedule Feasibility Summary

All activities from the planning, analysis, design, and implementation phases should be completed by their milestone deadlines. In addition, this project was not presented to the Department of Technology yet, so the project could be completed by the Spring 2016 MIS 161 class if necessary.

Conclusion: The project’s schedule is feasible.

E. Feasibility Summary

Based on the operational, technical, economical, and scheduling feasibility studies, the project is feasible.

Conclusion: The project is feasible

31

Figures

Figure 1. CA Department of Technology Organizational Structure

Figure 2. State of California Organizational Structure

32

Appendix B: Business Analysis

33

Part I: Conduct of Analysis

A. Analysis Methods Used

1. Documentation Collected

Team 1 examined hard documents in order to receive and analyze the information for this project. The information examined and analyzed is currently on the California Department of Technology webpage under the California Project Management Methodology (CA-PMM).

2. Conducting End User Interviews

Due to the nature of this project and the deadline required, team 1 did not possess the time and resources to conduct interviews and ask end user questions.

3. Survey Conduction

Surveys were not conducted by Team 1. The information provided by Professor Spiros and the hard documents examined by Team 1 were sufficient in order conduct and submit the necessary documentation.

4. Observation

Team 1 was not able to observe state workers at the California Department of Technology and other facilities implementing this project due to conflicting schedules and deadline requirements. However, the information provided by Professor Spiros and other hard documents found on the website allowed Team 1 to access critical information to bypass this step in the process.

5. Prototype Development

During this phase of the project, Team 1 focused attention primarily on the Software Specification Requirements (SRS) and Infrastructure Analysis. However, Team 1 was able to analyze the original system under the toolkit presented under the California Project Management Methodology section of the California Department of Technology website. The initial prototype Team 1 will present on May 4th is going to prepare, design, and construct during the design phase of this project.

6. JAD Sessions

Joint Application Design (JAD) sessions were not held to retrieve the information needed to continue with this project. Time restraints and conflicting schedules impacts the availability to meet and discuss this process. The users, managers, and Team 1 (the analysts) were not able to set aside a few days to hold intensive meetings to specify or review system requirements.

34

7. Examination of Outside Vendor Software

Team 1 has already established the software that will be used to prepare, design, and construct the prototype for this project. Therefore, Team 1 did not seek out and examine outside vendor software.

B. End Users Contacted

Team 1 accepted this project with the knowledge that this project needed to be constructed on an accelerated basis. In addition, the time restraint is also compounded with conflicting schedules of the team members and managers and end users to meet and discuss the system requirements. Because of this fact, Professor Spiros provided Team 1 with the resources and objectives that is required of this project for the California Department of Technology. Team 1 understands through Professor Spiros’s description of the project, as well as the documentation generously provided on the California Department of Technology website the necessary requirements and desirable qualities that need to be available for the end users when the project is ultimately completed. Therefore, Team 1 did not contact the end users to discuss this project.

C. Records, Forms, and Reports Analyzed

Team 1 analyzed a variety of records, forms, and reports solely provided by the California Department of Technology under the California Project Management Methodology (CA-PMM). The two documents where the majority of the information was collected were from the CA-PMM Reference Manual and the CA-PMM Template Instructions. The CA-PMM Reference Manual covers an overview of the methodology framework, project life cycle, and an in-depth analysis of the different stages which include the Concept stage, Initiating stage, Planning stage, Executing stage, and Closing Stage. Another key detail that is included is an overview of the toolkit used and the different templates used during the different stages. The other major documentation includes the CA-PMM Template Instructions. This document includes how to get started with the workbook, toolkit contents, workbook navigation, how to use the workbook, saving and exiting the workbook, and how to print the workbook. Other supporting documentation used by Team 1 includes the frequently asked questions, requirements summary, project status reports, and the training requirements. The frequently asked questions is a document responding to various CA-PMM-related questions. The requirements summary uses a table summarizing the California Qualified training and other CA-PMM requirements. Team 1 examined some portions of the Project Status Report are to be completed and forwarded to the California Technology Agency. Finally, Team 1 analyzed information pertaining to the training requirements include information for IT project managers, project team leads, executives, and sponsors, along with CA-PMM training information and recommended qualifications for IT project managers.

D. Processes Observed

Team 1 was not able to observe the processes first hand due to conflicts of time and scheduling. However, Team 1 knows the processes that need to be used and functionality of the system due to

35

information researched and provided from the California Department of Technology website and Professor Spiros.

E. Problems Encountered with Data Collection

Team 1 was not able to schedule appointments and meetings with managers, supervisors, and end users to discuss and gather data for the project. Therefore, Team 1 did not encounter any problems in conducting and gathering data.

F. Data Collection Instruments

Team 1 members extracted and recorded qualitative data describing the systems functionality in a google sheets document by examining and analyzing the current functionality recorded in the hard code documents provided on the California Project Management Methodology section on the California Department of Technology website.

G. Synopsis of Interviews

No interviews were conducted by Team 1 for this report. Due to previously listed constraints, Team 1 gathered necessary information from Professor Spiros and the hard documents obtained off the California Department of Technology website.

Part II: Software Requirements Specification (SRS)

A. External Interfaces

1. User Interfaces

The system presents to human with a display called a user interface. The users interact with the system by both visual and motion. The user interface could have a “creating account” tab, “log in” tab, “main menu” and other primary categories tabs.

2. Hardware Interfaces

For hardware to interact with the web application, it has to go through the operating system (OS). Because it manages computer hardware and software resources and provides services to the web application itself, the OS is compatible with different computer devices such as Windows and Macintosh.

3. Software Interfaces

Team 1 will be using a web application as software for the webpage. The webpage uses to supporting programming languages that the webpage has offered. Along with the supporting programming languages, there will be SQL server to manage the database, since SQL server primary function is to store and retrieve data as requested by the program in the webpage.

36

B. Functions

To properly assess the functions required of the information system, we designated classes of users and defined the functions for each class. The user classes we defined include: 1) Project Team Member, 2) Project Manager, 3) Project team members (includes project manager), and 3) Application Administrator. System wide authorizations will be defined and enforced for each type of user on a hierarchical basis (i.e., the Project Manager will have all of the Project Team Member’s system wide authorizations, and the Application Administrator will have all of the Project Manager’s system wide authorizations.

1. Project Team Member

i. Account Registration

Description: All users should be able to register for an account created for them by an existing Project Manager or the Application Administrator via the web. Having the Project Manager or Application Administrator the account should eliminate the creation of unnecessary accounts. Users should receive an email from the system after the Project Manager or Application Administrator creates an account (see below) with instructions to register. After following the instructions (either to follow a link or copy a key, navigate to a web page, and enter the key in a form), users will need to enter information on a registration form (e.g., required: user name, password, reenter password, email; optional: phone; possible: registration key, security questions). Data validation should be performed on each of the fields to make sure they meet requirements (e.g., input mask for email and phone, usernames and passwords meet requirements). Data validation could be performed after the user exits a field (for that specific field) or after the user clicks to submit (for all fields on the page). If the data validation fails, an appropriate message should appear on the web page and ask the user to reenter some information. If the data validation succeeds, then a verification page should be presented, asking the user to double check their information before submitting. If the user decides the information is wrong they should be able to edit the information (whether this returns them to the previous page or allows them to edit information individually). When the user verifies the information is correct, they are directed to a confirmation page which notifies them they are able to log in.

Dependencies: Create an account (Project manager).

Rationalization: Creating an account for all users will provide the authentication necessary to properly implement an authorization model for the application. Project Managers and Application Administrators could create authorizations [DS1] for types of users, or potentially for individual users if we discover this is necessary at a later phase. This is an essential part of the new application since the information system will be stored on an online database, instead of an excel file that the manager can easily manage by only sharing it with those who need access. In addition, one of the goals of the new application is to facilitate collaboration. Having these authorizations set and centrally stored will allow Project team members to easily view and edit what they are supposed to without compromising the system.

37

ii. Log In

Description: Users will need to log in to access the application. A login field should be available on the home screen for the web site, or navigation to a login screen should be available. Users will need to enter their usernames and passwords to access the site. When the user submits their information, data validation will occur on the username and password fields to check whether they are null or fail to meet requirements. If they do not meet requirements, the user needs to be notified and prompted to return to the login screen and retry. If they are successful, they will be granted access and directed to the application dashboard.

Dependencies: Account registration (All users).

Rationalization: This repeated authentication at each session will ensure only those users authorized to edit or view the information system or portions of the information system will be able to.

iii. User Name Reset or Retrieval

Description: The user should be able to reset or retrieve their user name should they forget it without having to log in to their account. The user would access a user name reset page from the home or login screen. There are a multiple ways this functionality can be achieved (e.g. email with a link, email with a verification code, user name reset form using an email and security question).

Dependencies: Account registration (All users).

Rationalization: One of the goals for our information system is increased accessibility. If the user forgets their user name, they would not be able to access their account. Having a reset page would increase accessibility by allowing users to reset their own user name. It would also maintain security by authenticating the user with some form of identifying information. This would also decrease the burden on application administrators, who would have to reset the user names if the users could not themselves.

iv. Password Reset or Retrieval

Description: The user should be able to reset or retrieve their password should they forget it without having to log in to their account. The user would access a password reset page from the home or login screen. There are a few ways this functionality can be achieved (e.g. email with a link, email with a verification code, password reset form using an email and security question).

Dependencies: Account registration (All Users).

Rationalization: One of the goals for the information system is increased accessibility. If the user forgets their password, they would not be able to access their account. Having a reset page would increase accessibility by allowing users to reset their own password. It would also maintain security by

38

authenticating the user with some form of identifying information. This would also decrease the burden on application administrators, who would have to reset the passwords if the users could not themselves.

v. Edit Account Information

Description: All users should be able to edit their basic account information (i.e., user name, password, email, optional phone, etc.). In order to do this, they should have to verify their information (even if they are logged into the web application already). After verifying their identity, they would be brought to a page where they would be able to edit their account information (e.g., either directly to a page where they could edit their account information, or a page where they could view their account information and select a button to edit all or part of their account information). After they enter the desired changes into a form, data validation should be performed on each of the fields to make sure they meet requirements (e.g., input mask for email and phone, usernames and passwords meet requirements). Data validation could be performed after the user exits a field (for that specific field) or after the user clicks to submit (for all fields on the page). Then a verification page should be presented, asking the user to double check their information before submitting information. If the user decides the information is wrong they should be able to edit the information (whether this returns them to the previous page or allows them to edit information individually). If the user did not edit their email, they should be directed to a confirmation page. If the user edited their email address, they should be directed to an email verification page asking them to visit their email with instructions to verify their email. When the user verifies their email (e.g., a link or a key to enter in the email verification page sent in the email) they are directed to a confirmation page.

Dependencies: Account registration (Project Team Member)

Rationalization: Project Team Member should be able to edit their own identifying information to keep it up to date and to change passwords to meet security standards. By having the user authenticate again, you ensure it is the user changing their own account information, and allow them to easily update their own information without contacting an Application Administrator.

vi. Work Paper Completion and Operations

Description: The work papers included in the CA-PMM tool kit can be very different, but have a common set of features that are reused. A common feature in all work papers is the ability to quickly navigate to and the previous and subsequent work papers. Some are simple text boxes that do not populate other cells in the current workbook. Others do simply populate other cells in the same work paper or in other work papers, and others are used in formulas to make calculations. These output calculations are sometimes used to produce graphics, such as charts. These charts and calculations will need to update as the information is entered into the web page. An example of a work paper with text box input, calculations, and graphical output is the complexity assessment. This takes estimates for various factors affecting business and system complexity, averages the values entered (won’t include values in the average if values are not entered), and displays the complexity on a graph with the average business and system complexity as the axis. The graphic helps the user decide which complexity zone

39

the project falls under, asks some questions with radio button answers, and then provides the recommended experience level for the project manager.

Dependencies: Create a project (Project Manager)

Rationalization: The tool kits work papers help guide project manager’s through the CA-PMM process. Improving the process of working on and using these work papers to manage the project will improve the outcomes of IT projects.

vii. Optional Feature: Work Paper and Section Signoff

Description: For each work paper within the tool kit, individuals should be able to sign off when the work paper is complete. Since the tool kit does have a multi-level hierarchical structure, it would be good if we could clearly show the hierarchy of the entire toolkit on a single page. Individuals responsible for a work paper could sign off on a work paper when it is substantially complete or updated. In addition, when a team member finishes up a section, they could sign off on the entire section as being completed. Ideally, every work paper and section could be displayed on one summary page that shows when it was signed off on.

Dependencies: Create a project (Project Manager).

Rationalization: Signoffs allow users to quickly organize and identify which sections of the toolkit need to be worked on, and allow managers to decide which work papers are ready to review.

viii. Optional Feature: Create Issues, Link Issues to Work Papers or Sections

Description: Individuals should be able to create multiple issues to be addressed. This would essentially replace the issue log in the existing CA-PMM. Issues are defined as “unanswered questions and differences of opinion”. The issue would have to be assigned to a specific “owner” who is responsible for resolving the issue by a due date. The complete listing of fields for the issue log includes the issue number, date opened, issue description, impact, raised by, best resolved by, action taken to date, owner, next steps, due date, and date resolved. Of course the creation of the issue would only require the issue number (most likely automatically generated), date opened, issue description, impact, raised by, owner, and due date to be answered, though every other field but date resolved could potentially be answered.

Team 1 can also consider adding a functionality to relate issues to multiple work papers and to multiple sections. Obviously, some issues for the project will not be related to the work papers in the CA-PMM, so this would have to be optional. If it is related to work papers in the tool kit this would add an extra layer of convenience. In this case, we could show issues both in an issue summary and in a hierarchical overview of the toolkit and work papers.

Dependencies: Create a project (Project Manager).

40

Rationalization: Signoffs allow users to quickly organize and identify which sections of the toolkit need to be worked on, and allow managers to decide which work papers are ready to review.

ix. Optional Feature: Edit Issue

Description: Users should be allowed to edit and update issues to keep them current. The every field but issue number may have to be corrected if a mistake is made, but some attributes will likely have to be updated, such as issue description, impact, best resolved by, action taken to date, owner, next steps, and due date.

Dependencies: Optional feature: Create issues, link issues to work papers or sections (Project Team Member)

Rationalization: As progress is made, new information comes to light, or estimates are adjusted, making it necessary to update these attributes.

x. Optional Feature: Issue Signoff

Description: Users should be able to sign off on a resolved issue. Either from a view showing the issue log (accessed from the project dashboard) or by selecting an issue from a list of issues associated with a document or section (accessed from an overview of the tool kit sections and work papers). The sign off should automatically update the date resolved attribute of the issue with the current system date.

Dependencies: Optional feature: Create issues, link issues to work papers or sections (Project Team Member)

Rationalization: Issue signoffs improve efficiency by allowing workers to indicate when an issue has been resolved, and allows managers to see when and who signed off on an issue.

xi. Optional Feature: Delete Issue

Description: Users should be able to select and choose to delete an issue from the issue log screen or from the issues associated with a specific work paper or section.

Dependencies: Optional feature: Create issues, link issues to work papers or sections (Project Team Member).

Rationalization: Sometimes, issues will be created by mistake. The creator of the issue will need to delete the issue so it does not crowd the issues needed to be reviewed by the project manager.

41

2. Project Manager

i. Create an Account

Description: A project manager and account administrator should be able to create an account for each team member. This action would have to be performed after the user logged in to the web application. Then the user would navigate to a page to create the account. The project manager or administrator would enter the team member’s email into a text box on the web form. When they submit, data validation would check to see if the field is null; input validation would ensure the email is entered correctly. If the email is entered incorrectly, a message indicating the email was not entered or is invalid would appear on the page and ask the user to reenter the email. If the email is correct, it would direct the user to a confirmation page and send an email to the team member. The team member would follow instructions on the email to activate the account (e.g. copy and paste a registration key or follow a link). See registration for all users above for complete activation of the account.

Dependencies: Assign team members to project management position (Application Administrator).

Rationalization: When a new member joins the team, they will need an account to access the tool kit. It is not necessary to contact an Application Administrator, since we do not expect the Project Manager to needlessly create accounts. This provides convenience for the Project Manager, who in their busy schedule might need to introduce the new member to the tool kit right away without waiting around for it to be created by an Application Administrator.

ii. Create a Project

Description: Project Managers should be able to create projects once they have logged into their account from the application dash board. They should be navigated to a page where they will fill in the information for a new project. This information includes the Agency, Agency Org #, Department, Department Org #, Technology Agency Project #, Project Name, Project Start Date, and Project Due Date. The agency name and number indicate the primary California State Agency for the technology project. The department name and number indicate the project’s specific department within the agency. The Technology Agency Project number uniquely identifies the projects managed by the department of technology. The application should check the referential integrity of the Agency Org Number and Department Organization Number to make sure these entities already exist in another table. Also, these values are mandatory and must be filled in. The technology agency project number must be checked for entity integrity, ensuring it can properly be used as primary key (must be a unique, non null value). Other typical validation checks can be performed on all fields at this point as well. If the validation fails, a message should appear on the page indicating the reasons it failed. If the validation does not throw an error, then a confirmation page should be displayed.

Dependencies: Assign team members to project management position (Application Administrator).

42

Rationalization: Project Managers should have the information necessary and requisite trust to create projects in the information system. By allowing Project Managers to create their own projects, the burden on Application Administrators decreases.

iii. Edit Project Information

Description: Project Managers should be able to edit project information once they have logged into their account from the application dash board and / or the project dashboard. They should be able to navigate to a page where they can edit information for existing projects. The project information includes the Agency, Agency Org #, Department, Department Org #, Technology Agency Project #, Project Name, Project Start Date, and Project Due Date. The agency name and number indicate the primary California State Agency for the technology project. The department name and number indicate the project’s specific department within the agency. The Technology Agency Project number uniquely identifies the projects managed by the department of technology. The application should check the referential integrity of the Agency Org Number and Department Organization Number to make sure these entities already exist in another table. Also, these values are mandatory and must be filled in. The technology agency project number must be checked for entity integrity, ensuring it can properly be used as primary key (must be a unique, non null value). Other typical validation checks can be performed on all fields at this point as well. If the validation fails, a message should appear on the page indicating the reasons it failed. If the validation does not throw an error, then a confirmation page should be displayed.

Dependencies: Assign team members to project management position (Application Administrator).

Rationalization: Project Managers should have the information necessary and requisite trust to create projects in the information system. By allowing Project Managers to create their own projects, the burden on Application Administrators decreases and the application’s usability is improved.

iv. Assign Team Members to Projects

Description: Project Team Members will be granted initial access (i.e., no special authorizations) to a project via an invitation from a Project Manager or Application Administrator. This could be accomplished in a few different ways. One example would be to access an invitation page from the project’s dash board and search for the user’s account to grant access. This would make the most sense since Project Managers will eventually set authorizations at the project level. In general, it makes more sense to add team members to a project at the same time, than to search for individual accounts in different views and add the projects to an account. After entering the team members, the entries would have to be checked for referential integrity (i.e., the user exists, or alternatively the project exists if the project is added to the user from the user account view).

Dependencies: Account registration (Project Team Member), Create a project (Project Manager).

43

Rationalization: It is important that Project Managers be able to grant users access to individual projects. They will make the decision to include the individual on the team, so they should also be able to grant access in the information system.

v. Assign Authorizations to the Project Team Member User Class or to Individual Project Team Members for Individual Projects

Description: Access project authorization settings page for an individual project from the project dashboard or from the application dash board. Set the authorization settings for the Project Team Member user class or to individual Project Team Member’s assigned to the project to either view or edit and submit the page.

Dependencies: Create a project (Project Manager), Assign team members to projects (Project Manager).

Rationalization: Assigning authorizations to an entire project will be more convenient than setting authorizations for individual work papers. This will allow the project manager to select project team members who will edit information in the tool kit, and still allow others to view the tool kit even if they should not be editing it.

vi. Assign Authorizations to the Project Team Member User Class and to Individual Project Team Members for Individual Work Papers

Description: Access the work paper’s authorization settings page for an individual work paper from the project dashboard. Set the authorization settings for the Project Team Member user class or to individual Project Team Member’s assigned to the project to either view or edit and submit the page. Work paper authorizations should override project wide authorizations for the individual work paper.

Dependencies: Create a project (Project Manager), Assign team members to projects (Project Manager).

Rationalization: Assigning authorizations to a work paper will provide more precise authorizations than project wide authorizations. For this reason, we can assume that the authorizations for an individual work paper should override project authorizations for the user or user class.

vii. Optional feature: Review Signoff

Description: A work paper sign off should indicate that a work paper or section is ready to review. The work paper or section may be prepared and reviewed by the project manager. Once the project manager is satisfied that the work paper is completed or updated correctly, they should perform a review sign off. For example, we might make it so the project manager can sign off on the work paper or section from the work paper summary on the project dashboard.

Dependencies: Optional feature: Work paper and section signoff (Project Team Member).

44

Rationalization: Implementing a review procedure helps managers to keep track of the work they have actually checked, which should improve the quality of the work performed on the CA-PMM.

3. Application Administrator

i. Delete and Edit Account Information for All Users

Description: An Application Administrator should be able to access and edit the account information for all users. They should be able to do this using some identifying information to find the account, and using some form of authentication to verify it is the correct user if the user requests the account be changed.

Dependencies: Account registration for the Project Team Member and Application Administrator (Project Team Member).

Rationalization: The Application Administrator needs to fix issues if the user cannot access and fix issues with their account information on their own.

ii. Delete and Edit Projects Created by Other Users

Description: An Application Administrator should be able to access and edit the projects for all users.

Dependencies: Account registration for the Project Team Member and Application Administrator (Project Team Member).

Rationalization: The Application Administrator needs to access and edit the project if the Project Manager is not available. This is especially true if the Project Manager has left permanently and a new Project Manager needs to be assigned.

iii. Assign Team Members to Project Management Position

Description: The Application Administrator will be responsible for granting Project Manager status to certain accounts. There are different ways this can be achieved. For example, the Application Administrator could access a page where they would search for the Project Team Member’s account and grant access, or we could make it so the Application Administrator accesses a summary of the user’s account and chooses to grant access from that page. Either way, the Application Administrator should have be required to retrieve their password to authenticate themselves to decrease the risk that someone else could grant Project Manager status without legitimate authorization.

Dependencies: Account registration (Project Team Member).

45

Rationalization: Granting Project Manager status is an important function for the application. They will be primarily responsible for the completion of the toolkit, and need to have special authorizations to complete their work.

Note: From the documentation we have analyzed, we see no reason to require that a project manager be assigned to a specific project before having project manager status. For this reason, we decided to not include as a prerequisite for this functionality that a project manager be assigned to a project. This also allows project managers to create projects, since they do not have to be part of the project before having project manager status. This appears counter intuitive, since project managers must manage projects. However, considering that project managers are responsible for initiating projects, it makes sense to organize the information system in this way so that a project manager can create the project.

C. Usability Requirements

1. Usability Success Factors

i. Consistency

Consistency will be very important for this application. This application will be referred to often throughout the life of the project, and the amount of content in this application is relatively large. If the format of each page, methods of navigating the application or titles and terminology are inconsistent, the application will be virtually unusable. The user could not possibly remember how to use every single part of the application, or refer to a manual every time something has to be done. We have to make sure to follow a set of rules that the user can learn to help them figure out what is supposed to be done in different areas of the application.

In addition, consistent response time will be important. Performance requirements will be discussed later, but right now it is important to mention that users will be confused if sometimes the response time is short, while the response time at other times it is long. For example, it might break their work flow if the response time goes from under a second to five seconds at other times.

ii. Efficiency and Ease

Decreasing the cost and time to implement information system projects is a key business objective for our application. For this reason, improving efficiency and ease will be instrumental in improving the information system. Fortunately, the forms for the information system already exist and are clearly documented. These forms need little to no improvement since the information is grouped and ordered appropriately (formatting is a different issue, see below). One thing that could be improved on the forms is making sure that relevant outputs from other forms (or other places on the active form) are available, or even automatically generated if possible. The existing system accomplishes this in some cases, but not always (which also raises an issue with consistency). I also see potential to increase the ease of navigating the system. Currently, you can sort of step into the system one hierarchical layer at a

46

time. Something that would allow you to see every section and work paper simultaneously, and potentially the date completed if our optional work paper sign off feature is included, would greatly increase the efficiency and ease of navigating the system.

iii. Format

In this section, I will reemphasize the importance of consistency for usability. Users cannot memorize how an entire system works, but they can memorize rules that will help them figure out how to navigate and use the system. Consistency in formatting is essential to help users identify types of features in each view of the information system. Also, it should generally enhance the user’s ability to view and interpret the data by making sure important data is not “buried” in the interface. I think the CA-PMM has plenty of room for improvement when it comes to the format of each work paper. It will be important to be able to quickly change and view the changed format of certain elements on all of the pages (e.g., using a Cascading Style Sheet). This way, elements will be presented uniformly and can be changed quickly on all pages if desired.

iv. Flexibility

Flexibility will not be a major concern for the application since most of the requirements for the CA-PMM tool kit are clearly defined. However, the toolkit does allow managers to make changes if needed, which would be a loss of functionality at this point. If we determine that this feature is needed at a later point, we could potentially include some features that would improve flexibility. For example, perhaps building work papers with field titles. This would also provide structure for the process of editing a form. Or perhaps allowing users to move fields within a form and add types of fields. If these features are required, we would have to return to the feasibility study report to analyze whether it is possible for our team to add these features.

2. Usability Characteristics

i. User

Users should be familiar with the concepts in this tool kit. Although we should make an effort to simplify using the toolkit, we should also make sure to include the features and flexibility that an educated user would need to be effective in preparing the tool kit. Documentation and user training for the existing system adequately informs the type of people who will be using this system about the business and project management concepts in this system. We should make sure to include these concepts in our training to make sure users are prepared.

ii. Task

Task demands such as time pressure, cost of errors, and work duration (fatigue) decrease usability. Unfortunately, complying with the CA-PMM increases these task demands. For this reason, we feel like we could have a strong impact by decreasing the stress associated with these task demands. For example, we can help users to decrease their time pressure by identifying if and when portions of the

47

tool kit have been completed. This way they will know that the work papers do not have to be completed again. The cost of errors in the system will still be there, but we can minimize errors by centrally storing and updating the system. Work duration can be decreased by automatically populating and calculating the values for other fields.

iii. System

The information system will be made available via the users own hardware via their web browser. The user should be familiar with using their own mouse, keyboard, operating system, and browser, which will increase usability. The functionality of web applications over a browser is generally lower than that of a desktop, which may decrease usability in some ways. This is especially true when it comes to flexibility. However, as discussed before, there is not usually a need for flexibility with the CA-PMM toolkit, and the need to centrally store and update the toolkit should have a greater net increase on the environment. Also, there will be increased flexibility when it comes to which system the user will be able to work on. The user could potentially switch to a different device if the one they are using has issues without transferring the file.

iv. Environment

One very important environmental factor is that the users will often be at client locations. At a client location, it is often important to have quick access to information in the tool kit just in case the client has a question, so it is important that the project team member be able to access the application and locate the relevant information quickly. The fact that this is a web application implies that the user will be able to access the web application. If the internet connection is slow, then unfortunately there is nothing we can control to decrease the time taken to access the application. The application’s GUI navigation also needs to be clear and concise to help the user locate relevant information quickly and easily.

D. Performance Requirements

The requirements in this section provide a detailed specification of the user interaction with the software and measurements placed on the system performance.

1. Access and Save Files

Title: Access and save information to/from the server.

Description: Accessing and storing information from the server should be fast, user friendly, and easy to understand.

Performance: 95% of data retrieval and storage shall take 5 seconds or less.

48

2. Links Between Views

Title: Links between project views.

Description: Links between forms of project should be immediate and seamless.

Performance: 100% of all links in web application shall be seamless and require no extra time for loading.

3. Collaboration Response Time

Title: Collaboration between users.

Description: Updates to retrieved project files should save to the database upon click of the save feature and should be available immediately to other users accessing the project.

Performance: 100% of all saved material should be available immediately upon saving in under 5 seconds to specified users collaborating on the project.

4. Update Log

Title: Each save prompts new update log entry.

Description: Every save and change to the current document shall provide a new time/date stamp to the update log along with a short description of changes made, and by whom.

Performance: 100% of all saves automatically log new entry to the updates log available for users to see upon updating.

5. System Dependability

Title: System dependability requirement.

Description: The system should be accessible any time. If the system loses connection to the Internet or database, the user should be informed.

Performance: 100% of the time the user should be informed of system connections lost.

E. Logical Database Requirements

The logical database requirements for the CA-PMM web application are fairly simple and are designed that way to ensure higher reliability and fewer problems. There are generally 500 projects a year, so allowing from 2000-2500 accounts covers the minimum accesses needed and allows room for growth. For authorization and permissions, we plan to use three different user authentication levels. The team member level of user authentication is the most basic of access permissions. They have

49

permission to read and edit only the documents that the project manager granted them access to. The second user authentication level would be the Project manager permission level. This level has the rights to create a new project, grant team member permissions, as well as all permissions that come with the team member level. The administrator level permissions include all of the permissions from the Project manager level as well as the ability to access all projects, and account information for administrative purposes.

F. Design Constraints

The primary design constraints with the CA-PMM web application are making the app more efficient and more user friendly for information sharing and ease of collaboration. Since the current CA-PMM is relatively simple and easy to use, we want to emulate the same design to make it easier for current users of the software to be comfortable with the new software. Creating a user interface which is both effective and easily navigable will pose a difficult challenge. During the process, if we decide the current software could be improved by design, we will change our design to better fit the user need. Other constraints such as limited memory and processing power of mobile devices and browser compatibility are also worth considering. The new CA-PMM is meant to be quick and responsive while also easily sharable for collaboration, each feature must be designed and implemented with efficiency in mind.

G. Software System Attributes

The graphical user interface of the CA-PMM web application is to be designed with usability as the first priority. The app will be presented and organized in manner that is both visually appealing and easy for the user to navigate.

To ensure reliability and correctness, there will be zero tolerance for errors in the algorithm that allows connectivity with the web server for ease of collaboration and sharing between devices. To maintain flexibility and adaptability, the app will take into account situations in which a user loses internet connection or for whatever reason cannot establish a connection with the server. These users will still be able to use the application, but any changes made in the document while disconnected will be cached until the connection is restored. The users will need to be vigilant in saving their work to ensure the document gets updated to the server should an outage occur.

The software will feature user accounts for authentication when working on projects and collaborating with a key feature for the Project Manager to also be an administrator of the document who can assign privileges for users in a work group on a project. This feature will enhance security of documents for unauthorized users and prevent malicious access while ensuring data privacy.

Portability of the web application is meant to be a high priority as this is the largest advantage over the current implementation of the CA-PMM. The web application will be host-dependent on the server and uptime of the server is a high priority to ensure reliability to access of information.

50

Part III: Infrastructure Analysis

A. Hardware

The California Project Management Methodology is currently running on Microsoft Excel application, so it only requires a computer with Microsoft Excel installed.

The new proposal system is web application that requires a Web server and a database server. All of these servers will be virtualized using Microsoft Windows Server located in Dr. Spiros’ office at Sacramento State University. It also requires a domain name, internet connection and a computer to interact with the system.

B. Software

In this case, we will be using IIS Web server. IIS is Microsoft Web server role that is included with all versions of Windows operating system. The Web server was redesigned in IIS to enable you to customize a server by adding or removing modules to meet your specific needs. Modules are individual features that the server uses to process requests.

Additional to IIS Web server, we will be using Microsoft SQL server 2008. It is a relational database management system whose primary function is to store and retrieve data as requested by the web application. For each user, all information of each project related to that user will be stored in a relational database. Every time a user add or change any detail of his/her project, it will be updated to the database. In this way, the system ensures concurrency of data and improves synchronization if two or more people are working on the same project.

C. Networking

First of all, both user side and server side need connection to the Internet.

In order to access into the web application and the database, users will need to connect to the network of Sacramento State University using Virtual Private Network (VPN).

VPN enables a computer or a device that is not in Sacramento State University network to securely send, retrieve data, and interact with Windows server located on campus.

D. Standards

The standard for the proposal system infrastructure is based on the 3-tier architecture.

The top most level of the system is application/presentation layer. In this case, the web browser such as Internet Explorer, Firefox, Safari and Chrome are the main applications used in the system. This layer allows users to use the CA-PMM web application to manage their work. It will be interact with the middle layer/ business layer, which defines all the control access and business rules. This layer

51

coordinates the application, processes commands, makes logical decisions and evaluations, and perform calculation. The last layer is data layer which contains the data access methods and database. Information is stored and retrieved from the database or file systems. The information is then passed back to the middle layer for processing, then eventually back to the users. For example, when a project manager uses their account to log into the system, the control access layer takes the information to verifies the authentication and authorization of this user by accessing to the data access layer and compare if the information is matched, then it will be processed in the middle layer and pass the result back to the user.

Please see figure 2 for a graphical representation of the differences between the three layers.

52

Figures

Figure 1. CA-PMM Summary

53

Figure 2. Three Tier Architecture

54

Appendix C: Systems Analysis

55

Part I: Use Case

A. Use Case Diagram

56

B. Use Case Descriptions

1. Registration

Actors Team Member, Project Manager, Application Administrator

Level White

Stakeholders Team Member, Project Manager, Application Administrator

Precondition - Create an account (Team Member needs invitation email from Project Manager)

- Account Registration

Minimal Guarantee The users are notified that their registration failed.

Success Guarantee The users successfully register and can now log in to the system.

Trigger Project Manager identifies the need to add a project team member and initiates account creation and registration.

Account Administrator is contacted by a Project Manager to add a project team member.

Account Administrator identifies the need to add another Account Administrator.

Main Success Scenario -The users successfully register.-Allows the user to log in to their newly created account.-Registration stores important data about the user in their

account information.-Requires the user to create a username / password combination

that uniquely identifies them, and that prevents unauthorized access to their account.

Extensions 1a. Users can’t register into the system 1a1. Users fail to created username and/or password 1a2. Users reset the system and figure out another way to

enter the username and/or password 1a3. System crashed when the users are registering

57

2. Login

Actors Team Member, Project Manager, Application Administrator

Level White

Stakeholders Team Member, Project Manager, Application Administrator

Precondition - Create an account- Account Registration

Minimal Guarantee Users will not be able to log in.

Success Guarantee Users successfully log in to their own account and can use the system

Trigger Based on their role, users will identify the need to log in.For example, project managers and team members will log in

when they need to make adjustments to the CA-PMM toolkit.The application administrator will log in when they come to

work, since their primary job responsibility is managing the application, which is performed using the application.

Main Success Scenario Users login successful, giving them access to the application’s functionality.

Users are logged into the correct view of an information system. They are not logged into another users view.

Extensions 1a. User errors 1a1. The system can’t recognize the username and/or

password 1a2. The users reset the password and username 1a3. The users try to log back in with a different username

and/or password

58

3. Edit personal account

Actors Team Member, Project Manager, Application Administrator

Level Blue

Stakeholders Team Member, Project Manager, Application Administrator

Precondition - Create an account- Account registration

Minimal Guarantee System will not let the users edit their personal information.

Success Guarantee The users can edit their own account information.

Trigger User notices their account information is incorrect or out of date.

Main Success Scenario The users edit their information and receive a confirmation that their information has been successfully updated.

Extensions 1a. Website crashed 1a1. Users exit site 1a2. Users refresh the site 1a3. Users log back in 1a4. Users take actions to edit their information

59

4. Edit / Delete All Accounts

Actors Application Administrator

Level Blue

Stakeholders Project Manager, Team Member

Precondition - Log in as application administrator

Minimal Guarantee Admin cannot edit or delete any account

Success Guarantee Admin are able to edit or delete any account

Trigger The Project Manager requests that an account for one of their Team Member’s.

Application Administrator is notified that the Project Manager’s account information must be changed by a new Project Manager. In particular, this is relevant to changes in account authorizations when a Project Manager leaves the Project.

Main Success Scenario Admin can view / edit / delete any account as requested from Project Manager or Team Member.

Extensions 1a. Admin fails to view/edit/delete an account 1a1. System fail to support the changes that admin wants to

make 1a2. log back out and refresh

60

5. Create a project

Actors Project Manager, Application Administrator

Level Blue

Stakeholders Project Manager, Application Administrator

Precondition - Create an account- Account Registration- Log in as Project Manager or Application Administrator

Minimal Guarantee Manager cannot create a new project.

Success Guarantee Manager can create a project.

Trigger Project Manager wins a bid to work on a new project for the CA-Department of Technology.

Main Success Scenario - Manager successfully create a new project- Manager places the order of the project tasks- Manager assigns which task to team member

Extensions 1a. Manager can’t create the project 1a1. Creating the project is not availableManager has to reset the system to be able to creating the

project 1a2. Manager can’t change role to project manager 1a3. Manager contact Application Administrator

61

6. Archive a Project

Actors Project Manager, Application Administrator

Level White

Stakeholders Project Manager

Precondition - Log in as Project Manager, Application Administrator- Select a project

Minimal Guarantee Manager cannot archive the project

Success Guarantee Manager successfully archive the project

Trigger The project ends and CA-PMM toolkit is completed.

Main Success Scenario - Manager can archive a project- Manager can get access into the archive

Extensions 1a. Document can’t be archive 1a1. check if the project has been finished 1a2. check if the user log in as Project Manager 1a3. contact Application Administrator

62

7. Assign account to a project

Actors Project Manager, Application Administrator

Level White

Stakeholders Project Manager, Team Member

Precondition - Create an account- Account Registration- Log in- Change role to project manager

Minimal Guarantee Manager can’t send invitation to team member

Success Guarantee Manager should be able to send invitations to a registered

Trigger Manager identifies team members who need to work on the tool kit for a particular project.

Main Success Scenario - Manager successfully assigns accounts to a project, allowing users to access the project’s toolkit.

Extensions 1a. System can’t recognize 1a1. System won’t be able to recruit the team member

for the manager 1a2. Manager is not able to identify his or her team

member 1a3. Manager can’t assign a specific task 1a4. Team member cannot receive the tasks that the

manager assign 1a5. Manager has to reset the system to make it work

63

8. View project

Actors Team Member, Project Manager, Application Administrator

Level Fish

Stakeholders Team Member, Project Manager, Application Administrator

Precondition - Create an account- Account Registration- Log in

Minimal Guarantee Users cannot view the project.

Success Guarantee Users can fully view the project.

Trigger Users identify the need to retrieve information stored in the application.

Main Success Scenario - Users can view all of the project.- Users can navigate different views of the project to easily

and quickly access the data they need during a session.

Extensions 1a. Users can’t view the project 1a1. Users re-enter their username and/or password 1a2. Users refresh the site 1a3. Users have to create another log in to view the project

64

9. Edit project

Actors Team Member, Project Manager, Application Administrator

Level Blue

Stakeholders Team Member, Project Manager, Application Administrator

Precondition - Create an account- Account Registration- Log in (Team member need to have Project Manager

permission)- Edit project information

Minimal Guarantee Users cannot edit the project

Success Guarantee Users can edit the project.

Trigger Users identify the need to edit data in the CA-PMM.

Main Success Scenario - Users can edit the tasks of the project.- Users can change the settings of the project.- Users are able to save changes to the project.- Edits are stored in a fashion that others accessing the

database will see the edits.

Extensions 1a. Users can’t edit the project 1a1. Check permission 1a2. System cannot recognize the role of the users to let

them fix 1a3. Users will have to stick with the original project

because there is no editing is allow

65

10. Store / retrieve data from database

Actors Team Member, Project Manager, Applicant Administrator

Level Kite

Stakeholders Team Member, Project Manager, Applicant Administrator

Precondition - Create an account- Account Registration- Log in

Minimal Guarantee The database cannot store or retrieve necessary data.

Success Guarantee The database successfully stores and retrieves the correct data.

Trigger This process is activated by other use cases that need to retrieve, insert, update, or delete data from a centrally stored data base.

Main Success Scenario - Database has been safely kept and store- Users can now store the database

Extensions 1a. Database cannot store or retrieve 1a1. The database does not have enough storage. 1a2. Data input violates a database constraint. 1a3. The database overloads.

66

Part II: Activity Diagrams

A. Registration

67

B. Log in

68

C. Edit Personal Account

69

D. Edit / delete all accounts

70

E. Create project

71

F. Archive project

72

G. Assign Account to a Project

73

H. View Project

74

I. Edit Project

75

Part III: Class Diagram

76

Part IV: Sequence Diagram