SWE481 – Software Engineering Capstone 1 Page | 2 SWE481 Software Engineering Capstone I Group Software Development Plan 11 August 2014 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 1. Project Outline 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 devel ...

1. SWE481 – Software Engineering Capstone 1 Page | 2
SWE481 Software Engineering Capstone I
Group Software Development Plan
11 August 2014
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 Chart25
6.3 Network Diagram 25
7. Risk Analysis 26

2. 7.1 Risk Assessment26
7.2 Mitigation Strategy 26
References 26
1. Project Outline
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

3. 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.
2. Development Methodology
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:

4. 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).
3. Requirements3.1 Requirements Gathering Process
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

5. 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.). 3.2
Project Requirements
Requirement ID
Description
Criteria
Rationale
Type
Priority
MA001
App shall have touch screen support
Yes/No
Provides app navigation

6. Functional
1
MA002
Music search results shall be < 2 sec from pressing search
button
Must be < 2 secs
Reduce user wait time
Functional
2
MA003
App shall have native device appearance
Yes/No
App blends with device environment
Nonfunctional
2
MA004
App shall stream music online from server
Yes/No
Provides on demand access to entire music selection
Functional
1
MA005
App shall play music offline with full subscription
Yes/No
Allows user to listen without incurring data charges
Functional
1
MA006
App shall allow free radio access
Yes/No
User can listen to music without paying monthly fee
Functional
3
MA007
App shall provide music preference recommendations
Yes/No/

7. Partial
Entices user to explore other like music interests
Nonfunctional
3
MA008
App shall have < 3 search process steps
Must be < 3 steps
Simplifies music searching
Functional
2
MA009
App shall support Facebook, Google+ integration
Yes/No
Allow sharing of music interests with friends
Functional
2
MA010
App size shall be < 20 MB
Must be <20 MB
Ensures app is easy to download/install
Nonfunctional
3
MA011
App music storage size shall be < max device capacity
Storage size
Ensures app doesn’t limit storage space
Nonfunctional
2
MA012
App run size shall be < 15 MB
Must be <15 MB
Ensures app is not intrusive
Nonfunctional
3
MA013
App shall support Bluetooth 2.0+

8. Yes/No
Supports user accessories
Nonfunctional
1
MA014
App shall support iOS 6.0+, Android 4.0+, Windows 8.0+
Yes/No
Cross platform device support
Nonfunctional
1
MA015
App shall provide 3 failed login attempt lockout
No more than 3 attempts
Provides account access security
Nonfunctional
1
MA016
App shall meet ADA compliance
Yes/No
Provides easy access for impaired users
Nonfunctional
1
MA017
App shall have unique user accounts
Yes/No
Ensures no more than one account per username
Nonfunctional
1
MA018
App shall have salt/hash password storage
Yes/No
Provides secure storage of passwords
Nonfunctional
1
MA019
App shall support SSL/256 bit login encryption support

9. Yes/No
Provides end-to-end encryption for login
Nonfunctional
1
MA020
App shall have minimum 98.99% reliability
Minimum of 98.99%
Ensures availability of service
Nonfunctional
1
3.3 Requirements Analysis
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.
4. App Design4.1 Music App Architecture
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

10. 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)4.2
Major Application Components
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
4.3 Class 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

11. classes are also shown in the diagram.
Figure 3. Class Diagram
4.4 Use Case 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
4.5 Main Screen
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
4.6 Data Management
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

12. 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).
5. Development and Testing5.1 Coding Agile Development
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

13. 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).5.2 Key Processes
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.
MEETING
PURPOSE
DURATION
FREQUENCY
Sprint Planning
Lay the ground work for the next sprint

14. 2-4 hours
1 per sprint
Daily Meetings
Allows the team to discuss risks, and milestones
15-20 minutes
Daily
Sprint Review
Display work that has been completed to the stakeholders
2-4 hours
1 per sprint
Retrospective Meeting
Discuss lessons learned
1-2 hours
1 per sprint
(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). 5.3 Testing Phases
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

15. 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).5.4 Test Cases
Test 1 Information
Test Details
Script ID
TS-CROSSPF
Description
Test cross platform support
Type of Test

16. User Interface
Expected Results
The app will operate properly on iOS, Android, & Windows
Phone
Priority
Mandatory
Pass/Fail Criteria
To pass the test the app should be fully functional on System
shall support iOS 6.0+, Android 4.0+, and Windows 8.0+ Oses
other wise the test will receive a fail.
Traceability
MA014
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

17. 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

18. 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

19. 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)6. Project Schedule
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. 6.1 Master
Schedule
WBS
Task Name
Duration
Start
Finish
Predecessors
Resource Names
1
Pilot
7 days
Mon 8/4/14
Tue 8/12/14
Development Team A
1.1
Plan
1 day
Mon 8/4/14
Mon 8/4/14

20. 1.2
Requirements
1 day
Tue 8/5/14
Tue 8/5/14
2
1.3
Analysis
1 day
Wed 8/6/14
Wed 8/6/14
3
1.4
Design
1 day
Thu 8/7/14
Thu 8/7/14
4
1.5
Test
1 day
Fri 8/8/14
Fri 8/8/14
5
1.6
Acceptance
1 day
Mon 8/11/14
Mon 8/11/14
6

21. 1.7
Deployment
1 day
Tue 8/12/14
Tue 8/12/14
7
2
Radio
7 days
Mon 8/4/14
Tue 8/12/14
Development Team B
2.1
Plan
1 day
Mon 8/4/14
Mon 8/4/14
2.2
Requirements
1 day
Tue 8/5/14
Tue 8/5/14
10
2.3
Analysis
1 day
Wed 8/6/14
Wed 8/6/14
11

22. 2.4
Design
1 day
Thu 8/7/14
Thu 8/7/14
12
2.5
Test
1 day
Fri 8/8/14
Fri 8/8/14
13
2.6
Acceptance
1 day
Mon 8/11/14
Mon 8/11/14
14
2.7
Deployment
1 day
Tue 8/12/14
Tue 8/12/14
15
3
Subscription
7 days
Mon 8/18/14
Tue 8/26/14
Development Team A
3.1

23. Plan
1 day
Mon 8/18/14
Mon 8/18/14
3.2
Requirements
1 day
Tue 8/19/14
Tue 8/19/14
18
3.3
Analysis
1 day
Wed 8/20/14
Wed 8/20/14
19
3.4
Design
1 day
Thu 8/21/14
Thu 8/21/14
20
3.5
Test
1 day
Fri 8/22/14
Fri 8/22/14
21
3.6
Acceptance

24. 1 day
Mon 8/25/14
Mon 8/25/14
22
3.7
Deployment
1 day
Tue 8/26/14
Tue 8/26/14
23
4
Social Media
7 days
Mon 8/18/14
Tue 8/26/14
Development Team B
4.1
Plan
1 day
Mon 8/18/14
Mon 8/18/14
4.2
Requirements
1 day
Tue 8/19/14
Tue 8/19/14
26
4.3
Analysis
1 day

25. Wed 8/20/14
Wed 8/20/14
27
4.4
Design
1 day
Thu 8/21/14
Thu 8/21/14
28
4.5
Test
1 day
Fri 8/22/14
Fri 8/22/14
29
4.6
Acceptance
1 day
Mon 8/25/14
Mon 8/25/14
30
4.7
Deployment
1 day
Tue 8/26/14
Tue 8/26/14
31
5
Integration
7 days
Mon 9/1/14

26. Tue 9/4/14
Teams A and B
5.1
Design
1 day
Mon 9/1/14
Mon 9/1/14
28
5.2
Test
1 day
Tue 9/2/14
Tue 9/2/14
29
5.3
Acceptance
1 day
Wed 9/3/14
Wed 9/3/14
30
5.4
Deployment
1 day
Thu 9/4/14
Thu 9/4/14
31
6
Close
1 day
Fri 9/5/14
Fri 9/5/14

27. 6.2 Gantt Chart
6.3 Network Diagram
7. Risk Analysis7.1 Risk Assessment
7.2 Mitigation Strategy
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

28. (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
Interface Layer
Media Layer
Core Services
OS/Kernel Layer
Music App
Music Service Infrastructure
Data Sync
Data Cache

29. User
Interfa ce Layer
Media Layer
Core Services
OS/Kernel Layer
Music App
Music Service Infrastructure
Data Sync
Data Cache
HU1440: Week 7 Essay
Page 1
Visual Argument
Create a visual argument for a public service announcement of
your choice. Here are some ideas that
you can use for public service announcements:
1. Should prisoners be released due to lack of funding?
2. Should libraries shut down due to lack of funding?
3. Should soldiers be pulled out of Iraq and Afghanistan?
4. Should music and art programs be the first to be taken out of
schools to cut costs?
5. Should the E-reader replace traditional texts in schools?
You may create this argument in a number of ways, such as by

30. using Microsoft PowerPoint or Adobe
Photoshop. You can also create your own poster, scan it, and
submit it. Remember to properly cite all
the references and information such as web images that you
have borrowed for your document.
Answer the following questions after creating the visual
argument:
1. How have you made the visual argument immediate and
tangible? How does this visual argument
pull you into the picture?
2. What common ground is established with the viewer through
shared values and points of view?
What emotional response is evoked from your image?
3. What is the importance of the placement of objects, people,
and actions in your visual argument?
4. Did you use any icons or symbols to prompt response from
your viewers? If so, which icons did
you use, and what response did you hope to evoke?
5. What audience do you imagine your visual argument to be
directed at and why?
6. What are the claims of your visual argument, and what
supporting evidence is given to support
those claims?

31. Submission requirements:
You may create this argument in a number of ways, such as by
using PowerPoint or Adobe
Photoshop. You can also create your own poster, scan it, and
submit it. Submit your response to all
the questions in a minimum of 50 words per question in a Word
document.
Font: Arial, 12 point, double-spaced
File name: InitialName_FirstName_Essay7.1_Date