Version History Date Author Version Changes made Rationale 10/10/12 MM 1.0 First Version VC Package 10/15/12 MM 1.1 Section 1 and 5 completed FC Package 10/22/12 MM 1.2 Bugs fixed Response to Evaluation of VC Package 10/30/12 MM 1.3 Section 2-4 completed Bugs fixed FCR ARB 11/05/12 MM 1.4 Section 2, 2.2, 2.3, 3 Fixed FCR ARB Comments 11/09/12 MM 1.5 Benefits in Program Model Updated with more realistic concepts (Section 2) Section 2.2, 2.3 updated in regards to the new benefits. Instructor’s Comment 11/26/12 MM 1.6 Bugs fixed New feasibility evidences added (Pulling information from PubMed module ) Bugs fixed based on TA Comments We have provided some feasibility evidences about our most risky module (Pulling information from PubMed module)
Business Case Analysis Assumptions People are willing to use an electronic system for collaboration Increased collaboration improves research Stakeholders (Who) Initiatives (What) Value Propositions (Why) Beneficiaries (For Whom) Developers PTS marketing team PTS research team Web master Database administrator Develop System Market the project and get people to sign up. Promoting success stories. Collect statistics on injuries Train the web master. Increase research collaborations between members of PTS. Improve education and research. Reduce number of injuries for children. Reduce the burden on hospitals and clinics. Members of PTS The medical field Children Parents Hospitals, Clinics, Society Cost Development Personnel Training (Developers, Webmaster) Maintenance Infrastructure expenses (e.g. Web Hosting/Server) Benefits Number of members’ published papers (Rational: This project is supposed to facilitate researchers (members) collaboration. So if in the future we find that the number of published paper increased, it means that this project has been useful. Hours that each member spend for researching
Cost Analysis Personnel Costs Table : Personnel Costs Activities Time Spent (Hours) Development Period (24 weeks) Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks) Client: Meeting via email, phone, and other channels [3 hrs/week * 12 weeks * 1 people] 36 Client Representatives (Webmaster): Meeting via email, phone, and other channels [1 hrs/week * 12 weeks * 1 people] 12 Architecture Review Boards [1.5 hrs * 2 times * 2 people] 6 Development and Operation Phases: Time Invested (CS577b, 12 weeks) Client: Meeting via email, phone, and other channels [5 hrs/week * 12 weeks * 1 people] 60 Maintainer (Webmaster): Meeting via email, phone, and other channels [3 hrs/week * 12 weeks * 1 people] 36 Architecture Review Boards and Core Capability Drive-through session [1.5 hrs * 3 times * 2 people] 9 Deployment of system in operation phase and training - Installation & Deployment [3 hrs * 4 times * 2 people (Client & Webmaster)] - Training & Support [2 hrs * 8 times * 2 people (Client & Webmaster)] 56 Total 215 Maintenance Period (1 year) Maintenance [3 hr/week * 52 weeks] 156 COTS Support [1hr/week * 52 week] 52 Total 208 Hardware and Software Costs Table : Hardware and Software Costs Development & Operation Type Cost Rationale Hardware – Web Hosting and Domain Server $250/year A new web server is needed to serve our application, database and domain name.
Benefit Analysis Table : Benefits of PTS System Current activities & resources used % Reduce Time Saved (Hours/Year) Increase collaboration (reduce time that each member needs to spend on researching) 10% 500 Improve research quality (Increase the number of members’ published papers) 10% 500 Total 1000 ROI Analysis Table : ROI Analysis Year Cost Benefit (Effort Saved) Cumulative Cost Cumulative Benefit ROI 2013 215 0 215 0 -1.00 2014 208 1000 423 1000 1.36 2015 228.8 1000 651.8 2000 0.53 2016 251.68 1000 903.48 3000 0.10 Figure : ROI Analysis Graph
Process Feasibility Based on our project’s non-conformity points and comparing them to all 4 process patterns, we can see that the number of non-conformity points in Architected Agile process pattern (4 points) is less than other patterns. It means that our project is more follow Architected Agile process pattern. On the other hand the importance of these 4 points is medium. So from all of these factors we can find that we should follow Architected Agile process. Table : Rationales for Selecting Architected Agile Model Criteria Importance Project Status Rationales 30 % of NDI/NCS features 2 1 Using one COTS that is small part of the whole project. Single NDI/NCS 1 0 There is no single NDI/NCS that satisfies a complete solution. Unique/ inflexible business process 2 2 The system business is not very unique and the requirements can change in the future. Need control over upgrade / maintenance 3 4 Because this system works with a lot of information which are stored in the database, it should be upgraded regularly. Rapid deployment 1 1 PTS is a non-profit organization and also there is no deadline for delivering the system (except 577 milestones). Critical on compatibility 3 4 However we use only one COTS, it should be fully integrated in to the system. Internet connection independence 2 1 It is a web application. Need high level of services / performance 2 1 The levels of service are not high. Need high security 2 1 There is no sensitive information. Asynchronous communication 1 1 All communications in the system should be synchronous. Be accessed from anywhere 3 4 It is a web application. Critical on mass schedule constraints 2 2 Schedule is important in our project. Lack of personnel capability 2 3 The webmaster probably has little experience about database maintenance and optimization and also web application developing
Risk Assessment Table 9: Risk Assessment Risks Risk Exposure Risk Mitigations Potential Magnitude Probability Loss Risk Exposure Inability to connect to PubMed will fail the project. 8 4 32 Test PubMed API and Alert System COTS products chosen do not meet the needs of the users. 4 7 28 Get client and board feedback, COTS assessment, Prototyping COTS which are not able to talk to each other will produce extra rework. 2 3 6 COTS assessment, Test Demo versions, Prototyping Staffing unavailability (database manager, moderator) would increase system downtime. 4 4 16 Get client and board feedback, Business Case Analysis Lack of developer skills would increase lifecycle plan. 3 5 15 Training, Consider other programming language Current host database size limitation will produce extra effort (server changing). 2 3 6 Estimate Database size, Work with limitation, Consider other host services Client will not be satisfied if response time does not meet target. 6 3 18 Consider Solr, Lucene solutions, Prototyping