CS577a Fall 2015 Team 2 FCR ARB Presentation -Sultan Alsarra -Aref Shafaeibejestan -Adil Cem Albayrak -Mohammad Almunea -Charles Reitz -Julapat Julnual -Andrea Brown -Travis Weaver

Outline :: Remote Team Members :: Operational Concept Description :: Win Win Agreements/Requirements :: Prototype :: Architecture :: Life Cycle Plan :: Feasibility Evidence :: QFP Team 2@CS577a Fall 2015

Remote Team Members https://stocksnap.io/photo/69TMH4ITIE

Team’s Strengths Operational View Technical View Quality product/project is shared goal 5 members have identical class schedules, so meeting is easier 8 team members is more than typical Some team members have combined experience in both Android and iOS development At least one team member is an experienced web developer Several members taking 571 (Web Technologies) Team 2@CS577a Fall 2015

Team’s Weaknesses Operational View Technical View Solutions Team formed out of desire to work with others who will take 577b, rather than skills or cohesion Only a member or two have experience with backend server/DB mgmt, config, security, etc. Only a couple members (out of 8) with experience in app development Skill range is incidentally broad One member is taking 585 and others have taken at least a DB course in their undergraduate studies. Back-end work should be less than front-end Experienced app developers can spend more time teaching the rest Team 2@CS577a Fall 2015

Technical Concerns & Solutions :: Minimal experience developing front to back solution. Mitigation Combine team member front- and back-end experiences to work together to design communication between application and server. :: Can be difficult to make identical-enough iOS and Android versions of an app. Mitigation Collectively decide on UI features beforehand to ensure they are available on both platforms. Team 2@CS577a Fall 2015

Operational Concept Description http://www.lgi-consulting.com/wp-content/uploads/2013/09/innovation-849x539.jpg

System Purpose The primary purpose of the PicShare application is to make sharing pictures easier than it is today. PicShare gives the user the ability to share pictures in three different ways: 1- “near-by” location. 2- Post pictures to public events using hashtags. 3- Post pictures to a private event using hashtag and password. Team 2@CS577a Fall 2015

Program Model Assumptions: People are willing to share their pictures. People have smartphones with camera and Internet connection. Stakeholders (Who is accountable for the initiatives) Initiatives (What to do to realize benefits) Value Propositions (Benefits i.e Why) Beneficiaries (Who derives value) Maintainers Developers Users Owner Design & Develop the new system Marketing campaign Proper Training and knowledge transfer Maintain the System Survey and User Testing Increase efficiency of sharing pictures. Improve user experience by allowing users to create/post different types of events (public, private, location). Easier picture sharing options. Cost (cost factors) Development Cost Maintenance Cost Advertising COTS (server, ..) Benefits Increase number of users on the app. Increase number of events. Team 2@CS577a Fall 2015

Benefit Chain Diagram Team 2@CS577a Fall 2015

System Boundary & Environment Team 2@CS577a Fall 2015

Element Relationship Diagram Team 2@CS577a Fall 2015

Core Capabilities Capability Goals Priority Level OC-1 Use Hashtag: User can post pictures with a hashtag that indicates a public event Must Have OC-2 Login with Facebook:User can login using facebook OC-3 Use Location: User can post pictures to the nearby location OC-4 Delete Picture: Users can delete pictures that they posted. Users can also delete pictures of their private events. OC-5 Search Events: User can search events by their name (hashtag). OC-6 Browse Event’s Pictures: User can browse pictures associated with an event and sort them by like or date. OC-7 Create/Delete Private Event: User can create/delete a private event that only people with password has access to it. OC-8 Report Picture: Users are able to report inappropriate pictures. Mid Priority OC-9 Save picture to Device: User can save the picture to his/her own device. OC-10 Like/unlike Picture: Users are able to like/unlike a picture OC-11 Take Picture or Choose from Gallery: Users can decide whether to take a photo or choose it from gallery when adding a picture. OC-12 Choose Add Picture Type: When user create a private event they can choose if users can upload pictures, or only post pictures captured live. OC-13 Administrator: Admin can control and supervise user’s content. Wish List Team 2@CS577a Fall 2015

Goals and Constraints Organizational Goals: OG-1: Simplify sharing pictures from smart phones. OG-2: Share location based pictures. OG-3: Share public and private hashtags with friends and families. OG-4: Increase efficiency of sharing pictures. OG-5: Improve user experience by allowing users to create/post different types of events (public, private, location) Constraints: CO-1: Android and iOS as an Operating Systems: The new system should work on both iOS and Android operating systems. CO-2: Facebook Login: The user should be able to use the application using his Facebook credentials. CO-3: Zero Monetary Cost: The Chosen NDI/NCS must be free. CO-4: Linux as an Operating System: the available back-end server is linux. CO-5: Free Database System. Team 2@CS577a Fall 2015

Win Win Agreements Win Win Agreements http://psytreasure.com/wp-content/uploads/2014/11/Handshake.jpg http://www.sixsigmainstitute.org/wp-content/uploads/2014/05/Win-Win-situations.jpeg

Win Win Agreements Event Management Win Condition Description WC_3579 As a user, I can use a hashtag for a picture taken in a special event such as a basketball game, so the people who missed the event will see what they missed. WC_3585 As a user, I can reserve my event's hashtag for a limited time (one week), so I and event attendees can use the hashtag to post pictures of the event. WC_3603 As a user, I can shut down my own event, so that I can remove my event and all pictures in the event before reserved time is up. WC_3621 As a user, I can set up a private event that only invited people can see and access via password, so that I can ensure only the people I want to participate may participate. WC_3627 As a user, I can save the hashtags to save time searching for them later and see my history of hashtags. Team 2@CS577a Fall 2015

Win Win Agreements Picture Management Win Condition Description WC_3580 As a user, I can take many pictures to introduce my geo-location, so the tourists using the app will search the location and see what’s there. WC_3591 As a user, I can delete pictures that I posted, so they are no longer accessible. WC_3599 As a user, I can report any inappropriate picture, so that it will be removed from the event. WC_3600 As a user, I can moderate the pictures in an event that I created, so that pictures that I don't like will be removed from the event. WC_3619 As a user, I can take a photo from the PicShare app or choose a picture from my gallery, so that I can take a picture from another app. Team 2@CS577a Fall 2015

Win Win Agreements Picture Management (2) Win Condition Description WC_3623 As a user, I can save one or many pictures from an event/hashtag to my phone so that I can keep the photos after the event/hashtag expires. WC_3634 As a user, I can choose if users can upload pictures, or only post pictures captured live, which would give me more control over content in my private events. WC_3637 As a user, I can sort the view of pictures either by date posted or by popular, so I can have more control over picture viewing. WC_3751 As a user, I can like a picture. Team 2@CS577a Fall 2015

Win Win Agreements Profile Management Win Condition Description WC_3583 As a user, I can create my login with specific username and password or Facebook account, so I can use them to login to the application. WC_3584 As a user, I can login to the application using my registered username or my Facebook account, so I can use the application with my own profile. Team 2@CS577a Fall 2015

Prototype https://stocksnap.io/photo/UM62EOZSRC

Prototype :: Facebook Login Integration :: Server side event management :: User Interface Team 2@CS577a Fall 2015

Prototype : Facebook Login Integration Why? :: Facebook Login is a desired feature of our application :: Facebook is an external system, using their API leads to a risk Mitigation :: Gather API information, make sure it provides all information we need :: Buying information by building an interoperability prototype Team 2@CS577a Fall 2015

Prototype : Facebook Login Integration Login Page :: Login with “Login with Facebook” with Facebook API Team 2@CS577a Fall 2015

Prototype : Facebook Login Integration Main Page :: Fetch user information (name, e-mail, profile picture) :: Log out with “Log out” button Team 2@CS577a Fall 2015

Prototype : Server side event management Why? :: Limited experience in building an end-to-end system: back-end server to front-end application Mitigation :: Algorithms Team 2@CS577a Fall 2015

Prototype : Server side event management Team 2@CS577a Fall 2015

Prototype : Server side event management Team 2@CS577a Fall 2015

Prototype : User Interface Why? :: Clarify User Interface of the application with the owner Mitigation :: Buying information by building GUI prototype Team 2@CS577a Fall 2015

Prototype : User Interface Explore - Nearby screen :: Default after login screen :: List all nearby pictures with their posted user, location, and likes Team 2@CS577a Fall 2015

Prototype : User Interface Explore - #Event screen :: User input #Event name in search box :: List all nearby pictures of #Event with their posted user and likes Team 2@CS577a Fall 2015

Prototype : User Interface Live Demo https://ninjamock.com/s/WRCBT Team 2@CS577a Fall 2015

Architecture Architecture https://sourcemaking.com/files/sm/images/arch2.jpg http://www.epaymentbiometrics.ensicaen.fr/wp-content/uploads/2015/04/Fotolia_11376759_M.jpg

Top Level Physical Architecture Team 2@CS577a Fall 2015

Top Level logical Architecture Team 2@CS577a Fall 2015

System Context Team 2@CS577a Fall 2015

Use Case Diagram Team 2@CS577a Fall 2015

Use Case List # Use Case Name UC-1 Login UC-9 View Specific Picture Logout UC-10 Like Picture UC-3 Register UC-11 Unlike Picture UC-4 Create Private Event UC-12 Report Picture UC-5 Delete Private Event UC-13 Save Picture to Device UC-6 Search Events UC-14 Browse Event’s Pictures UC-7 Add Picture UC-15 Sort Pictures UC-8 Delete Picture UC-16 View Nearby Pictures Team 2@CS577a Fall 2015

Artifact and Information Diagram Team 2@CS577a Fall 2015

Life Cycle Plan https://www.mindflash.com/wp-content/uploads/2014/09/Learning-Plans.jpg

Life Cycle Plan Purpose: Managing the project team while they work on each phase of the project’s life cycle. Development Strategy: Architected Agile. Duration: Two Semesters (24 weeks) Team: Consists of 8 team members. Assumptions: All team members will continue on to 577B. Team 2@CS577a Fall 2015

Life Cycle Plan Let’s Meet The Team: Member Strengths Rigo Being a Cool Owner Aref Architecture, UML Modeling Adil Requirements Engineering, UML Modeling Mohammad Operational Concept Engineering Jul Prototyping, Testing Charles Travis Quality Focal Point Andrea Feasibility Analyst, IIV&V Sultan Management, Life Cycle Planner Team 2@CS577a Fall 2015

Life Cycle Plan Foundation Phase: Duration: From 10/27/15 to 12/7/15 Activities: Assess Project Status Manage Project Quality Progress on Prototyping Develop Software Architecture Milestones: Development Commitment Review Development Commitment Package Team 2@CS577a Fall 2015

Project Plan Project Plan: Team 2@CS577a Fall 2015

Life Cycle Plan Artifact deliverable in Foundation Phase: Jira Due date Format Medium Jira Every Monday website Progress Report Biweekly .xls Soft copy Project Plan .mpp Progress on Prototype Presentation Slides 11/06/2015 .pdf Development Commitment Presentation Slides 12/02/2015 Draft Development Commitment Package .doc, .pdf Development Commitment Package 12/07/2015 Team 2@CS577a Fall 2015

Life Cycle Plan Project Scale Factors: Scale Driver Value Rationale Precedentedness (PREC) Low Most of the team is not familiar with mobile app development. Only two of the eight members have developed mobile apps before. Development Flexibility (FLEX) High Owner is flexible and open to input and suggestions from team members and wishes general conformity with his requirements. Risk Resolutions (RESL) Risk Elimination is feasible for project and most can be mitigated by buying information and prototyping such as the Facebook API. Team Cohesion (TEAM) Very Team chemistry is very good with seamless interactions and communications between members. Members also are highly cooperative and have a good understanding of the project. Process Maturity (PMAT) NOM Team has an okay understanding of CMM Maturity but has no expertise. Team 2@CS577a Fall 2015

Life Cycle Plan COINCOMO Estimate: Team 2@CS577a Fall 2015

Life Cycle Plan Estimation: Number of SLOC: 5041 Effort needed (Pessimistic): 11.18 person-month Each Member Works: 18hrs/week for 12 weeks of development Total Time Spent by Members: A: 18 hrs/wk × 8 members × 4 weeks = 576 hrs/month B: 18 hrs/wk x 8 members x 12 weeks = 1728 total hours Number of time Needed: A: (11.18 person-month × 152 hrs/person-month) ÷ 576 = 2.9 months B: 11.18 person-month x 152 hrs/person-month = 1699 total hours Is it possible: Yes, for one application, since it will take us 2.9 months or 12 weeks to finish (1728 hrs> 1699 hrs) and that’s in the worst case scenario. Team 2@CS577a Fall 2015

Feasibility Evidence http://muslimlifehackers.com/wp-content/uploads/2014/07/8226451812_88007f08df_b.jpg http://m.c.lnkd.licdn.com/mpr/mpr/p/6/005/083/203/1cd1e0a.jpg

Personas

Freshman student - Lena Profile: Age: 18 Gender: Female Hometown: Boston, MA Occupation: Student Description: Lena is a new freshman USC student. She moved from Boston and lives in a dorm on campus. Goals & Aspirations: Meet other students and make new friends. Attributes: Curious and outgoing User Scenario: Lena plans to be involved in student activities. She wants to find out what activities are going on around her. Information Sources: Facebook Twitter Snapchat Team 2@CS577a Fall 2015

Graduate Student - James Profile: Age: 25 Gender: Male Hometown: Houston, TX Occupation: Student and TA Description: James is a graduate student at USC. He goes to every home football game. Goals & Aspirations: Take advantage of all the student activities in his last year at USC. Attributes: Energetic and passionate about school spirit. User Scenario: Because this is his last year, James wants to make sure he has pictures capturing one of his favorite student activity; enjoying a USC football game with friends. Information Sources: Facebook Twitter Snapchat Instagram Team 2@CS577a Fall 2015

Organization President - Sandeep Profile: Age: 32 Gender: Male Hometown: Seattle, WA Occupation: HR Manager Description: Sandeep is an HR manager for an engineering company. He is also the president of a volunteer service organization for the homeless. Goals & Aspirations: Bring awareness of ways people can help the homeless. Attributes: Helpful, kind, and enjoys volunteering User Scenario: Sandeep plans to work with city officials on events to help the homeless epidemic in Seattle. He has a website for his organization that needs to be updated with pictures from recent events. Information Sources: Facebook Twitter Google Team 2@CS577a Fall 2015

Wedding Planner - Nicole Profile: Age: 40 Gender: Female Hometown: Atlanta, GA Occupation: Wedding Planner Description: Nicole is an established wedding planner in Atlanta. She always knows the latest wedding trends and her customers love her work. Goals & Aspirations: Expand her customer base so low-budget weddings can also be successful. Attributes: Hard-working and organized User Scenario: Nicole plans to expand her customer base by using more DIY and low-cost services to replace professional services like photography, cake decorating, and venues. Information Sources: Facebook Twitter Instagram Pinterest Google Team 2@CS577a Fall 2015

Major Risks

Major Risks Risk Description Risk Mitigation Inaccurate understanding of software requirements Meet owner with specific questions. Prototype, verify win conditions with owner, and create OCD Personnel shortfalls Build morale and learn from experienced team members Server-side management technology ambiguity Self-learning or learn from other teammates and prototype Lack of involvement by success-critical stakeholder Proper communication with owner, incremental development, and weekly updates/meetings Requirement changes Design to cost and incremental development Human-System integration shortfalls Prototype, incremental development, surveys, and interviews Unrealistic schedule and budget Analyze feasibility, create project plan, design to cost, incremental development, and software reuse Architecture/reuse/non-development item conflict Prototype, incremental development, and research the API Gold plating Prototype, design to cost, and incremental development Team 2@CS577a Fall 2015

Business Analysis

Personnel Costs Activities Time Spent (Hours) Development Period (24 weeks) Valuation and Foundation Phases: Time Invested (CS577a, 12 weeks) owner: 1st WinWin session 1.5 owner: 2nd WinWin session owner: meeting via email, phone call, and other means [1hr/week * 12 weeks * 1 person] 12 Architecture Review Boards [1.5 hrs * 2 times * 1 person] 3 Team 2@CS577a Fall 2015

Personnel Costs Activities Time Spent (Hours) Development and Operation Phases: Time Invested (CS577b, 12 weeks) owner: meeting via email, phone call, and other means [1hr/week * 12 weeks * 1 person] 12 Architecture Review Boards and Core Capability Drive-through session [1.5 hrs * 2 times * 1 person] 3 Deployment of system in operation phase and training Installation and deployment [3hrs * 2 times * 1 person] Training and support [2hrs * 2 times * 1 person] 6 Total 39 Team 2@CS577a Fall 2015

Hardware and Software Cost Type Cost Rationale Hardware cost (HostGator) $160/month owner-chosen hosting for development on a Linux server. Development cost $99/year Apple Developer Account Ownership cost Team 2@CS577a Fall 2015

NDI Analysis Why? Free Familiarity NDI/NCS Product Purpose MySQL DBMS Git COTS repository HostGator Server host Android & iOS SDK Mobile Development Environment Tool Why? Free Familiarity Team 2@CS577a Fall 2015

Quality Focal Point http://writtent.com/blog/wp-content/uploads/2014/05/quality-approved.jpg

Traceability Matrix OCD Requirement Use Case OC-1: Use Hashtag WC_3579 UC-7 OC-2: Login with Facebook WC_3583 UC-3 WC_3584 UC-1 OC-3: Use Location WC_3580 OC-4: Delete Picture WC_3591 UC-8 OC-5: Search Events WC_3627 UC-6 OC-6: Browse Event’s Pictures WC_3637 UC-14 UC-9 OC-7: Create/Delete Private Event WC_3585 UC-4 WC_3621 WC_3603 UC-5 OC-8: Report Picture WC_3599 UC-12 OC-9: Save Picture to Device WC_3623 UC-13 OC-10: Like/Unlike Picture WC_3751 UC-10 UC-11 OC-11: Take Picture or Choose From Gallery WC_3619 OC-12: Choose Add Picture Type WC_3634 Team 2@CS577a Fall 2015

Quality Management Strategy Defect Prevention: Strategy Priority Level Description Good Coding Practice Med Personal It is the personal responsibility of each team member to follow language specific best practices when contributing to the project.   Version Control High Personal - Team Use git version control tool. Prevent defect injection from manuel code integration, ensure all team members working from valid branch. Peer Review Sub Team - Team Whenever possible, peer review code to ensure best practices have been followed and to identify defects. Prototyping Prototype design to refine and validate win-win requirements. Win-Win Team Ensure win-win methodology is followed to prevent defects from bad requirements and requirement misunderstandings. All success critical stakeholders must intimately understand each requirement and its implications. Team Status Minimum one weekly team status meeting/update to set weekly expectations and communicate anticipated effort. Cut down work duplication, rework, and defects. ARB Preparation and participation in the Architecture Review Board process will aid in catching misunderstood requirements and other defects. Team 2@CS577a Fall 2015

Quality Management Strategy Defect Detection: Automated Analysis Review Testing Basic compiler capabilities Basic requirements and design consistency and traceability checking Peer Review ARB Unit Test Integration Test System / End-to-End Test Team 2@CS577a Fall 2015

Quality Management Strategy Defect Removal & Tracking: Defect tracking system used will be Jira. The IIV&V personnel, QFP, and Project Manager (PM) will collaborate to maintain defects in Jira. Reports will be generated bi-weekly by either the IIV&V, QFP or the Project Manager for the recurring project reports. All responsible personnel will maintain current status in Jira as updates become available. Team 2@CS577a Fall 2015

Defects & Technical Debt Current defects: (As of Week 5 Project Status Report) Technical Debt: - None incurred so far Avoidable Defects Unavoidable Defects Concerns We were late to start second win win meeting due to room being used by other team Owner is very busy during FCR ARB week, so it was difficult to set up an appointment There is no clear understanding on server technology we are going to use Could not set up connection probably with den students during second win win meeting Some of photo specs and resolutions of system are unclear Team 2@CS577a Fall 2015

“Q & A” Do you have any question? Let’s ask us.