Software Capstone week 5

Week 5

Contents 1. Project Outline 4 2. Development Methodology 7 3. Requirements 9 3.1 Requirements Gathering Process 9 3.2 Project Requirements 10 3.3 Requirements Analysis 11 4. App Design 12 4.1 Music App Architecture 12 4.2 Major Application Components 13 4.3 Class Diagram 14 4.4 Use Case Diagram 15 4.5 Main Screen 16 4.6 Data Management 17 5. Development and Testing 18 5.1 Coding Agile Development 18 5.2 Key Processes 18 5.3 Testing Phases 20 5.4 Test Cases 21 6. Project Schedule 23 6.1 Master Schedule 23 6.2 Gantt Chart 25 6.3 Network Diagram 25 7. Risk Analysis 26 7.1 Risk Assessment 26 7.2 Mitigation Strategy 26 References 26

The project that we have chosen is a mobile application for music to expand the streaming music that is already available on the website. The application will have two options for the user to choose from. The first option will be a no cost listening option, which will have ads associated with it. This option will be a radio stream that will allow the user to listen to random songs based on the interests that they choose. The second option would be an ad-free paid subscription where the user can pick specific songs to add to their playlist for their listening pleasure.

The application will be developed to work on the Android 4.0+ operating system along with iOS 6.0+ and Windows 8.x+ phones. It will include integration for social media so that users can post their playlists and what they are listening. They will be able to share the playlists with their friends and family.

The application will be only need the UI developed as it will integrate with the backend that is already developed for the website. The budget for the project is estimated to be $300k with an expected timeline to be between 60 and 90 days. This will be finalized once the schedule is created and released.

The project will be broken down into 5 phases.

1. Initial pilot application. At this phase the application will allow users to create accounts, and have the majority of the front end laid out, but not completely functional.

2. Radio Module. This will be the development of the search functionality to allow users to search through the database of songs and artists and begin to find music for which they wish to listen.

3. Subscription Module. This will allow users to use the Radio Module above and save the songs to playlists and add music to the library.

4. Social Media Module. This will allow users to begin posting information on what they are listening to their social media networks.

5. Project Close. This will be the final release of the completed application.

Each of these phases corresponds to a cycle in the software development methodology that we have chosen to use for this project.

We must consider a number of things while developing this software and looking into developing the requirements. One of which is the legal aspect of allowing users to access music for which we are currently licensed to use on a mobile device versus in their PC web browser. We will have to investigate and potentially modify any agreements we have with the various music labels to ensure that our end users have access to the most music. If we are unable to provide a wide range of music, especially for what is currently popular, users will not purchase and use the application, and the investment into the project will have ultimately been a waste.

A second piece to look at will be the user interface itself. We should be sure to ensure that the interface is usable by all levels of user. It should be simple and intuitive, but also cater to those who may have visual or auditory difficulties. For the visually impaired we can include large text and album pictures to go along with each artist so the user can easily read and identify what it is they are looking for. For those with auditory impairments we can include Bluetooth connectivity to connect to external speakers and devices that are Bluetooth enabled to enhance their listening pleasure.

The development methodology being used for this project is a form of Agile software development called Iterative development. This type of a software development methodology works on cycles. These cycles are broken down into several steps. They are as follows:

1. Inception

a. Planning

b. Gathering Requirements

2. Elaboration

a. Analysis

b. Design

3. Construction

a. Code Review

b. Testing

4. Transition

a. Acceptance

b. Deployment

The inception phase identifies the scope, all requirements both functional and non-functional, and a high level overview of risks. Next, the elaboration phase creates the architecture that helps to alleviate the risks identified in the inception phase and also will fulfill the non-functional requirements. Then the construction phase fleshes out the previously generated architecture using the functional requirements as an outline of what the expectations are. Lastly, the transition phase delivers the finalized and fully tested code into production and moves forward to the next cycle.

This type of software development methodology will allow us to break down the software being developed into several individual pieces of functionality that will have to be created for the project. This will allow us to create each piece and then build upon the previously created code for each cycle, until a fully functional and robust application is delivered (Duval, 2007).

The requirements gathering process will consist of a multiphase approach that will include questionnaires, meetings, and visual tools. Using a multiphase approach will aid the development team in understanding the project and business. The goal will be to get information from each level of the business to gather important requirements that must be included in the project. Below are the steps this project will take to elicit and gather requirements.

Steps for elicitation and requirements gathering

1. Questionnaire: Step 1 will be the project questionnaire and will focus on business requirements, process requirements, and the music app requirements. Business requirements will focus on business methodology, business tolerance, and performance requirements. Process requirements will cover the business’ operational processes and their definition. The last item will be product requirements and will point to functional and non-functional requirements. Included in the product requirements will be portability, system interface, and what the impact of a system failure would be (Seilevel, n.d.).

2. UML tools: The next step is to create UML tools like use cases, class diagrams, and sequence diagrams made from the initial questionnaire. The UML tools will be used to elicit and gather more requirements. They aid the requirements processes by describing usability and flow of the system.

3. Meetings: The last step will be the meetings that will bring stakeholders together, and individually, to gather as many requirements as possible. The meetings will consist of brainstorming and analysis meetings. Included tools will be results from questionnaires, UML documents, white boards, and storyboards or mockups. The tools will aid discussion and allow the meetings to progress more quickly (Seilevel, n.d.).

The requirements listed in section 3.2 cover the most important requirements for this project. During analysis of the requirements the team found that all of the major categories for the app have been covered. The major categories include user interface, performance, reliability, supportability, and security. User interface requirements are shown in the touch screen support and ADA compliance. Performance has been covered by app size, run size, and search time. Also, the requirements listed the needed reliability to be at 98.99%. Supportability has been taken into consideration by ensuring the app cross platform. Finally, security has been addressed by ensuring there is a lock out mechanism, unique user accounts, and system encryption. The team has done a great job in securing the major requirements needed for the application.

This project is to create a frontend application that will utilize the existing backend servers and services. Although the team will create music apps for multiple platforms there will be some similarities. The apps will contain four main layers that will include an interface layer, media layer, services layer, and OS layer. The interface layer will provide the user interaction and allow for gestures and app navigation. Next will be the media layer, which will provide graphics, audio, and wireless streaming.

After the media layer is the core service layer. The core service layer provides networking, cloud storage, string management, and in-app purchases. The last layer is the OS or Kernel layer. The OS/Kernel layer is what will handle signal processing, security, policies, memory management, and inter-process communication. The music app will interface with the backend music servers and store downloaded music in a local cache (Helal & Bose, 2012).

Figure 1. Music App Architecture (Helal & Bose, 2012)

The major app components are shown in the component diagram. As shown in the diagram, the app will have two distinct ways the app will be usable. First is the radio stream service. This is available to users for free but will limit the apps components. With this type of account the user will only be able to stream preprogrammed stations, search stations, share via social media and use Bluetooth. Several other components will only be useable with a full paid subscription. If the user has a paid subscription (direct listen) they will be able to access the download music, library, and playlists components in addition all of the free service components. Also with a direct listen account the user will still be able to listen to radio streams provided to free account users.

Figure 2. Component Diagram

The below class diagram illustrates the classes contained within the music app system. The classes include user classes like customer and employee. Customer services representatives, site administrators, and third parties will inherit from the employee class. Other classes include the main class, user account, music, and search classes. All relationships between classes are also shown in the diagram.

Figure 3. Class Diagram

The below use case diagram shows all of the major components of the music application. The user of the application is on the left of the diagram. They will have access to create an account, login or out, music library, and payment information. Additional actors on the right are for the customer service representatives, third party payment verification, and site administrators. Each of these actors has access to their specific area of the system.

Figure 4. Use Case Diagram

This section displays a mockup of the app’s main screen. Across the top of the screen are four tabs for home, library, search, and settings. Each of these tabs provides the user with unique options to use the application. The main screen will display top items from the music service. Under the music service banner will be additional options for the user to use. The user will be able to browse top albums, songs, and artists by tapping one of the options.

Figure 5. Music App Screen

A 2012 Pew survey found 57% of users have either declined to install or removed an app based on privacy concerns (Boyles, Smith, & Madden, 2012). A data management policy will be developed for this project that will apply to both data access and restriction. Care will be taken to ensure the data owned by the user and third parties are not open to public domain. Below are the initial requirements for data management of the music app.

· Ownership and Custodianship – The app’s data management shall delineate ownership between user, music service, and third party data. The music app will protect all data owned by users and music labels, however, it will allow these entities access to what information is collected and maintained in the music app.

· Privacy – The music app shall adhere to all privacy legislation to ensure that personal information is protected from the public domain.

· Liability – The music service’s liability shall be clearly stated in the end-user agreements and licenses.

· Sensitivity – The music app shall ensure sensitive data is not publicly available to unauthorized parties.

· Existing Law & Policy Requirements – The music app shall abide by all laws, existing legislation, and business policies (Caviglione, Coccoli, & Merlo, 2013).

The coding approach for the music app will match the agile development methodology for the project. The music app will be coded in small phases to ensure optimal iterative development and continuous integration into the system. Not all requirements will be initially known for the entire project. The project will mature and reveal more requirements after development begins. For this reason the project will be coded in different iterations. The iterations will be mini-projects that will be integrated into the bigger project.

The main goal of this development methodology is to continuously add features to the project. The overall project plan will be modified to add new features that will be integrated into the system. There is also a short timeline, 2-4 weeks, between development and deployment for the iterations. Due to the short timeline, iterations will be limited to what can be coded during the iteration sprint. The coding that occurs during the sprints should not take more than 5-7 days to complete. This will allow the necessary time for testing and integration into the music app (Perry, 2006).

The three key processes that will be used to drive the coding phase of the project will be milestones, meetings, and constant testing. All three of these three processes will work hand-in-hand to accomplish the completion of the project. First, the milestones will cover both large and small parts of the project. The larger milestones will be setup for each development phase. For example, the large milestones for this project are:

· 1. The initial pilot app (includes account creation)

· 2. Radio module (search for music interest)

· 3. Subscription module (create playlists, add music to library)

· 4. Social media module

· 5. Project close

There will also be smaller milestones inside each of the five large milestones. The milestones will be tracked using Teamwork.com milestone tracking software. The milestone tracking software will be utilized so that the whole team will know the progress of the development any phase of the project. The milestones will be created and reviewed during the sprint review meetings, which is part of the next key process (Davis, 2013).

It is essential that the development team have frequent meetings. Meetings are held to ensure everyone is aware of the projects current status; report any issues or risks; create, modify, or change milestones; or request additional resources. Below are the four main meetings that are predefined and will be built into the project.

(Microsoft, 2014)

The last key process is continuous testing. Continuous testing is essential to keep the project on time. Testing will start early in the project and continue until the music app is accepted by the customer. The testing will start at the module level. Each module will have to be tested and approved before it is integrated into the project. Once all of the phase modules have been completed the phase will have to be tested before it is integrated. After a module or phase is integrated the app will undergo regression testing to ensure the added feature did not cause something else to malfunction. The app testing will be tracked via the testing plan documents. A more in depth look at the music app testing will be covered in the next section (Duval, 2007).

The music app development plan will call for several different phases and levels for testing. For the design phase of the project the project will start at the unit level of testing. The unit tests will test a small part of software that will make up an integration sprint. During this phase of testing the test will focus on a single class and will use a one-to-one relationship. It is possible to add additional classes however this should only be done if absolutely necessary. If additional classes are required the unit tests should not use outside dependencies (Duval, 2007).

Next, is the development phase and will include integration testing. Integration tests will include outside dependencies to ensure they will work with the system. Examples of dependencies are acceptable will be music databases, file systems, and network connectivity. The development phase will also include system tests. It is at the system level that tests require as many outside dependencies as possible. This will ensure that the music app is tested with web services, outside databases, and that the user interfaces work end-to-end (Duval, 2007).

The next phase will start the release phase for the project and will include acceptance testing. Due to the sort timeline of the sprints most of the acceptance testing will be completed using automated testing. The music app development team will use a testing an automated testing framework like Selenium. Even though most of the testing will be automated there will be some real-world tests that occur as well. The goal during this phase is to use the system like a user would. This type of testing will help ensure the system functions and performs to meet the customer’s needs (Duval, 2007).

Finally, the last part of the release phase for the iterations will be performance testing. The music app sprint performance testing will be a limited deployment. This will allow the customer and users the ability to use the system in real-world environment. The goal for this phase is to ensure the sprint will meet quality performance objectives for the project (Duval, 2007).

Test Case ID	Input Values	Enviro/Config	Expected Results
TC-CROSSPF -01	Perform Music Search	App Installed on iOS versions 6-7	The music app will open and function as required per the requirements documents
TC- CROSSPF -02	Perform Music Search	App Installed on Android versions 4.0-4.5	The music app will open and function as required per the requirements documents
TC- CROSSPF -03	Perform Music Search	App Installed on Windows Phone versions 8.0-8.1	The music app will open and function as required per the requirements documents

Test 2 Information	Test Details
Script ID	TS-STREAM
Description	Testing the user can stream radio music
Type of Test	Functional
Expected Results	System allow the user to stream radio music
Priority	Critical
Pass/Fail Criteria	To pass the system must allow the user to stream music without error otherwise the test will fail.
Traceability	MA004

Test Case ID	Input Values	Enviro/Config	Expected Results
TC-STREAM-01	Select stream with free account, non-wireless speakers	Browsing radio stations	User is able to stream radio without error to internal or wire-connected speakers
TC-STREAM-02	Select stream with paid account, non-wireless speakers	Browsing radio stations	User is able to stream radio without error to internal or wire-connected speakers
TC-STREAM-03	Select stream with free account, Bluetooth wireless speakers	Browsing radio stations, Bluetooth enabled	User is able to stream radio without error to Bluetooth wireless speakers
TC-STREAM-04	Select stream with paid account, Bluetooth wireless speakers	Browsing radio stations, Bluetooth enabled	User is able to stream radio without error to Bluetooth wireless speakers

Test 3 Information	Test Details
Script ID	TS-LOGIN
Description	Test user login screen to ensure access to user account
Type of Test	Functional
Expected Results	System should authenticate the user and allow or deny access to the account
Priority	Critical
Pass/Fail Criteria	To pass the test the system should only allow users with a valid user name and password to access the system. Tests will fail if unauthenticated users can access the system.
Traceability	MA015

Case ID/Script ID	Input Values	Enviro/Config	Expected Results
TC-LOGIN-01	Accurate username/password	System Login Screen	User is authenticated and granted access to account
TC-LOGIN-02	Invalid username and password	System Login Screen	User is denied entry and prompted to re-enter credentials
TC-LOGIN-03	Third invalid username and password entry	Reenter Login Information Screen	User is denied and directed to Forgot Login screen

(Perry, 2006)

The schedule for this project was completed in MS Project. Two separate teams, in parallel, will develop the software modules. The first two modules over a 7 day period with a 3 day extension at the end of the period to account for unforeseen issues. The next two modules will be developed in the same manner. Following the acceptance of all the individual modules, Integration of the system will be completed.

7. Risk Analysis

References Bittner, K., & Spence, I. (2006). Managing Iterative Software Development Projects. Boston, MA: Addison-Wesley Professional. Boyles, J., Smith, A., & Madden, M. (2012). Privacy and Data Management on Mobile Devices. Retrieved July 21, 2014, from Pew Research: http://www.pewinternet.org/2012/09/05/main-findings-7/ Caviglione, L., Coccoli, M., & Merlo, A. (2013). Social Network Engineering for Secure Web Data and Services. IGI Global. Davis, A. (2013). Just Enough Requirements Management: Where Software Development Meets Marketing. New York, NY: Addison-Wesley Professional. Duval, P. (2007). Continuous Integration: Improving Software Quality and Reducing Risk. Boston, MA: Pearson Education, Inc. . Helal, S., & Bose, R. (2012). Mobile Platforms and Development Environments. Morgan & Claypool Publishers. Microsoft. (2014). Meetings (Agile). Retrieved July 27, 2014, from MSDN: http://msdn.microsoft.com/en-us/library/dd997582(v=vs.100).aspx Perry, W. (2006). Effective Methods for Software Testing (Third ed.). Indianapolis, IN: John Wiley & Sons. Seilevel. (n.d.). Tools for Requirements Gathering Sessions. Retrieved November 20, 2013, from http://www.seilevel.com: http://www.seilevel.com/wp-content/uploads/RequirementsGatheringTools.pdf

Start Date Initial Pilot Sprint Radio Sprint Paid Subscription Sprint Social Media Sprint Integration Project Close 8/12/14 8/12/14 8/26/14 8/26/14 9/4/14 9/6/14 8/4/14 8/4/14 8/18/14 8/18/14 9/1/14 9/5/14 41855 41855 41869 41869 41883 41887 Duration 9 9 9 9 4 1

User

Interfa ce Layer

Media Layer

Core Services

OS/Kernel Layer

Music App

Music Service Infrastructure

Data Sync

Data Cache