DCR ARB. Construction Meeting Minutes App Team 6

Transcription

1 DCR ARB Construction Meeting Minutes App Team 6

2 Team Members and Roles Pradeep Muruganandam - Prototyper and Quality Focal Point Dennis Evans - System Architect, Project Manager Pavan Lingambudhi Seshadri Vasan - Requirements Engineer Sideok You - Feasibility Analyst Shengyi Chen - Operational Concept Engineer Nguyen Tran - IIV & V Qichen Gu - LifeCycle Planner

3 Acceptance Test Plan and Cases Test plan: Developed unit test for all core functionalities of the app Followed value-based prioritization, focus on covering Minimum Marketable Features on top of the priority list of test cases provided by client Test cases: There are a total of 9 core test cases that had been extensively tested and verified that they all work as expected

4 Test Cases table List of Test Cases TC-01 Login functionality TC-02 Signup/Edit contractor information TC-03 Create new project TC-04 Create new meeting TC-05 View/Edit meetings TC-06 Generate reports and s TC-07 Generate and edit task list for contractors TC-08 Task comment by contractor TC-09 Backend GAE functionalities

5 Team s strong point Operational view: Well corporated - everyone is involved Plan things ahead of time Good communication among team members and with client Regularly engage client in our developing and testing process to receive feedback Technical view: Talented individual, yet all work together as a team Proficient in Android development, backend database, UI design Good knowledge of system architecture, general computer science algorithm and data structure

6 Team s weak point Operational view: Team member comes from different background Technical view: Need more experience regarding scalability of the application. Improve knowledge in offline local storage for Android app

7 Overall Project Evaluation Very interesting project which requires each of us to extensively learn new things such as GAE integration into Android app, database design, communication protocols, file format, and Android app development All team members contribute their work and effort to the project in order to make it successful Our client is really helpful in providing us feedback and guiding us through the app UI design and functionalities Overall, we have had a great semester with excellent experience in developing a Android application which is going to be used by real users

8 OCD - System Boundary Diagram

9 OCD - Desired Capability - User can login Manager can approve signup Manager can approve comment User can generate logs User can send notification User can post on Discussion Manager can create Project, Task and Meeting Manager can assign Project, Task and Meeting Manager can delete Project, Task and Meeting Manager can view all Project, Task and Meeting Contractors can view Project, Task and Meeting Assigned to them Contractors can report progress Contractors can edit profile User can search meeting by topics User can edit task categories

10 OCD - Capability Goals - The system is capable of generating the logs once User types them for any meeting The system is capable of send request of signup from Contractors to the Manager s account The system is capable of generating the discussion once User posts it The system is capable of creating project, task or meeting and adding it to the DB once Manager creates it The system is capable of assigning project, task or meeting to the Contractors The system is capable of searching project, task or meeting by its topic The system is capable of deleting project, task or meeting by its topic The system is capable of storing and keeping every history of project, task or meeting record to the DB The system is capable of generating notification to the Contractors once the meeting is assigned to them The system is capable of generating Discussion Post The system is capable of storing and accepting changes of task categories The system is capable of storing and accepting changes of contractors profiles The system is capable of storing and accepting changes of progress of every project, task or meeting

11 OCD - Top-Level Scenarios

12 Recap of Prototypes from FCR UI Prototype Using Balsamiq Developed a UI prototype using Balsamiq to act as a baseline for application screens Presented demo to client and implemented updates based on feedback Datastore Prototype Single developer implemented a Google App Engine Program to prototype storing and retrieving data from the Cloud Datastore Prototype only involved the backend as the App Engine Program did not interface with an Android Device Used Objectify API to store and retrieve objects from Cloud NoSQL Datastore Balsamiq Dashboard

13 Prototype - Study on Offline Storage Explored options to incorporate the offline storage in the mobile application. Came up with the options suitable for our use case - storing on the device s internal memory where only the current application will be able to access what it stores in a private file. Using openfileoutput() system call, we could access a storage entity in phone s internal memory and use write() to store the needed information in it. We need to write code to sync this last stored state with the central server for the last updated Meeting or minutes. Data retrieval using openfileinput() and the read() calls.

14 Prototype Updates UI Prototype of Android Screens Identified and implemented core screens into the project and presented during prototype presentation Android screens shown to client who identified updates to be made Prototype acts as a first draft of the UI screens. Screens will be improved in iterations and presented to the client for feedback to help assure the end product has a suitable UI which is one of the project s top priorities. In the later stages, we plan to survey the client and users in order to obtain satisfaction metrics that can be used to improve the UI. Navigation Flow of Application

15 Prototype Updates Android Datastore Prototype Datastore Prototype Components Expanded upon the first datastore prototype by implementing an Android prototype that communicated with a Google App Engine server via Cloud Endpoints API to store and retrieve data from Google s NoSQL Cloud Datastore through the Objectify API. Google App Engine Backend was redone from scratch by two separate developers from the first datastore prototype in order to gain valuable experience. Signup, Login functionalities are implemented. Parse Push Notifications Parse Push Notification Prototype Screenshot on Android Studio Emulator Based on feedback that the team received during the second prototype presentation, we decided to implement an app notification prototype for the DCR. Notification prototype done using Parse s Push notifications. Push notifications are a way to contact users that are not logged into the Android app Notifications can be sent to all users, a group of users, or selected individuals

16 Requirements Reduce Time Delay: (Reason)Using the current system, the stakeholders have to enter the data twice, once manually and then once into the single system in the office. This time can be used more productively. Improve Productivity: (Reason)To make decisions one has to study the previous data in the form of data logs entered into the database, which can only be accessed at the office. So making quick decisions is not easy and the process is slow. Reduce Paperwork: (Reason)Currently, data is recorded manually in sheets. These can be lost thus leading possibly to loss of important facts and messages and large paperwork can lead to disorganisation which can cause a lot of confusion regarding work flow.

17 Features - Prototype Mapping Easy Access to Logs and Data (LD) Easy to use Interfaces (EI) Report Generation Prototype Meeting Minutes Management(M3) Android - Google App Engine Prototype User Management(UM) Notification Prototype Notifications(N) Legend: Covers this feature All that remains is the integration of the prototypes into the application and its testing

18 Requirements - Feature Mapping Reduce Time Delay Easy to use Interfaces (EI) Meeting Minutes Management (M3) Reduce Paperwork Notifications(N) Improve Productivity Easy Access to Logs and Data (LD) User Management(UM) : This feature is important in order to fulfill the goals of this product as each employee will access the features of this application on the basis of the administrator privileges

19 Architecture - Updated Use Case

20 Architecture - Software Components

21 Architecture - Deployment Diagram Software designed using three-tier architecture pattern. Presentation tier Android UI Screens Logic tier User Management Meeting Management Data tier Android Cloud Endpoints Google App Engine Program NoSQL Google Cloud Datastore

22 Architecture - Meeting Management Class Diagram

23 COTS/Reuse Items Pdf Generation Library itext Parse Push Notifications Free open source pdf writing tool Allows us to generate pdfs from the Android application Push Notifications Used to export meetings Alternative: PDFTron Powerful high quality pdf-rendering library for Android Requires paid license Notify users of events when a user is not actively using the Android Application Wrapper for Google Cloud Messaging service, providing a level of abstraction that makes push notifications simple and easy to use Alternative: Google Cloud Messaging Key advantage - no 1,000 result limit for a single query

24 COTS/Reuse Items Platform as a Service Google App Engine Alternative: Ragic! Net centric service that lets you build and run applications on Google s infrastructure. Supports multiple languages (Java, PHP, Python, GO) Google Cloud Datastore Schemaless NoSQL database integrated with GAE through Objectify API Free to use with 1GB storage limit Spreadsheet like interface that requires zero coding on backend Free version has 1,000 record or 100MB limit Alternative: Amazon Web Services Mobile Hub Mobile service built on AWS cloud backend that is rich in features Most features are free to try with defined limits but for only 12 months Current version is beta

25 Life Cycle Plan Strategy: NCS-intensive NCS: Google App Engine for database storage & itext open source library for Report Generation in PDF format Platform: Android Application IDE: Android Studio Language: Java & XML 25

26 Life Cycle Plan Requirements upgrade from FCR ARB: 1. Requirements added: PDF Report Generation. 2. Requirements changed: Notification was optional, but is now a minimum marketable feature which will be implemented in the next semester. Offline Storage was optional, but now is a minimum marketable feature which will be implemented in the next semester

27 Plan for CSCI 577b Construction Phase: Integrate notification feature into the product Implement the two additional requirements Offline Storage, Pending Task Item Testing Run all the test cases mentioned in the earlier slides Transition: Time Cost for this phase is small as the client has given detailed description of the expected product. Functionalities are built according to the business logic. Our client will test the product weekly to give her feedback and opinion Note: The current UI has satisfied our client.

28 Team members and roles in the Construction Phase Dennis Evans - Developer, Project Manager Pavan Lingambudhi Seshadri Vasan - Developer Sideok You - Developer DEN student - Tester

29 Team members and roles in the Transition Phase Dennis Evans - User training (including our client), Project Manager Pavan Lingambudhi Seshadri Vasan - Manual writing Sideok You - Maintainer training DEN student - Tester Client - May train additional users

30 Iteration Plan - Construction Phase - Developer Capability Priority Iteration Notification Prototype & Report Generation Prototype Integration High 3 Pending Task Item Medium 3 Offline Storage Medium 4 Bug fixing High 3, 4

31 Iteration Plan - Construction Phase - Tester Test Case ID Test Case Name Priority Iteration TC-01 Login functionality High 3 TC-02 Signup/Edit contractor information High 3 TC-03 Create new project High 3 TC-04 Create new meeting High 3 TC-05 View/Edit meetings High 3 TC-06 Generate reports and s Medium 4 TC-07 Generate and edit task list for contractors Medium 4 TC-08 Task comment by contractor Medium 4 TC-09 Backend GAE functionalities High 3,4

32 Project Schedule

33 Schedule Diagram

34 COCOMO estimation: work done in the 1st semester

35 COCOMO estimation: work to do in the 2nd semester

36 COCOMO summary Pessimistic estimation needs extra 3.6 person month in the 2nd semester Have 3 * 1.6 = 4.8 person months The remaining available person months can be applied to enhance the testing.

37 Feasibility Evidence Contents - Refined business case - Major risks - General discussion

38 Feasibility Evidence - Refined Business Case Assumptions 1. Everyone has an android smartphone 2. Paperwork takes time 3. Internet access is available via WiFi or data network 4. The mobile has an ability to synchronize all data 5. Managers and employees are familiar with using Web App Stakeholders 1. Project Owner 2. Representative 3. Manager 4. Contractor 5. Developer 6. Maintainer Initiatives 1. New DB on any type of DB 2. Portable mobile application 3. Proper training documentation 4. Notification interface 5. design & develop new system Cost 1. Software costs: Google App Engine for storing data(db) and accessibility via Internet. Parse for push notification. Value Propositions 1. Make it more convenient for App user 2. Reduce time delay 3. Improve productivity 4. Reduce paperwork Benefits 1. Document maintainability 2. Increase productivity 3. Eliminate paperwork 4. Decrease time to update meeting 5. Create easy notification to users Beneficiaries 1. Manager 2. Architect 3. Contractor

39 Cost Analysis - personnel costs 39

40 Cost Analysis - hardware and software costs Type Software - Google App Engine Cost 1. Outgoing Network traffic: $0.12/GB Incoming Network Traffic: Free Datastore Storage: $0.18 /GB per month Database read & write: free for small (under 100,000 operations) Cost is different depending on what resources are using. However, it is much cheaper than other service provider. Also, incoming network traffic is free and Operations of read and write are free if it is under 100,000 operations. 1. Push notification is free under 1,000,000 unique recipients. Parse is providing push notification freely if recipients are under 1,000,000. One million is enough number for us. Also, it provides API for communicating smartphone and push server easily Parse Rationale 2. $ 0.05 per 1000 unique recipients if recipients are over 1,000,

41 Benefit Analysis Current activities & resources used % Reduce Time Saved (Hours/Year) 90% % % 49.4 Searching for a particular topic in one project Manager, Architect, and Contractor( 126 meeting lists* 10 minutes * 4 projects/year = 5040 mins) Tuning the Notification and Messaging Manager, Architect, and Contractor( 2 meetings * 30 minutes * 52 weeks = 3120 mins ) Typing and storing the meeting minutes Manager, Architect, and Contractor( 2 meetings * 30 minutes * 52 weeks = 3120 mins ) Total

42 ROI Analysis Year Cost Benefit (Effort Saved) Cumulative Cost Cumulative Benefit ROI

43 ROI Analysis Graph 43

44 Feasibility Evidence - Major Risks Risks Risk Mitigations Risk Exposure Potential Magnitude Probability Loss Risk Exposure 1. Google App Engine may stop running service Find another service such as AWS. Backup the data every month. Using cloud storage or local storage in our client s company. 2. Unstable Internet connection issue (synchronization) Save all data in the local memory, and synchronize it after internet connection is available. 3. Security issue for important data such as user password or data Using secure protocol or hash function in order to store securely. 4. Cost effective solutions Looking for solutions which freely provide functionalities that we need.

45 Feasibility Evidence - General Discussion 1. New NDI which is called Parse is added. a. b. Parse provides free push notification under 1,000,000 unique recipients. interoperability is fulfilled with Android application. 2. Cost analysis a. Software costs i. Storage 1. When the amount of free storage provided by Google exceeds, it causes a cost. ii. Push notification 1. If users of application over 1,000,000, it causes a cost.

46 Quality Focal Point The application was tested for the functionality for the features that were implemented and got to check on different inputs in them. They were also integration tested once new features were added to ensure that it does not break the earlier working functionality by running old tests. Test cases were developed with detailed input, output, pre & post conditions to be ensured while testing the scenario. Some test cases, not exercised are to be tested once the feature is integrated with the main Android application (in next semester).

47 Test Cases table - List of Test Cases TC-01 Login functionality TC-02 Signup/Edit contractor information TC-03 Create new project TC-04 Create new meeting TC-05 View/Edit meetings TC-06 Generate reports and s TC-07 Generate and edit task list for contractors TC-08 Task comment by contractor TC-09 Backend GAE functionalities

48 Traceability Matrix Feature Category Test Cases covering Functions User Management TC-01, TC-02 Login, Signup, Edit Meeting Management TC-03, TC-04, TC-05, TC08 Create Meeting, Edit Meeting, View., etc Generate Logs, Reports TC-06, TC-07 Generate PDFs and reports Backend compatibility TC-09 Testing of APIs

49 Technical Debt Integration of Notification prototype and handling it s shortcomings. We have a prototype using the Parse API to notify the devices registered to the central Parse server and assigned a Parse API key. It will intimate the user when the app is installed in the phone and running in background. We will not know if the API delivered the notification to the user and user was able to see it. So, need to implement a solution where user notifications are continuously synced with central notification records table.

50 CS577b Planned Testing Load Testing using BlazeMeter(jMeter). Alpha / Beta testing among the user base before launching full scale. User functionality acceptance testing. User usability UI fine tuning based on corrections.

51 Questions and Feedbacks