jim richardson software engineering capstone 1 ip phase 5

Running head: SOFTWARE DEVELOPMENT PLAN 1

Software Engineering Capstone 1

SWE 481

Project Risks

Professor N. Abbas

Individual Project Phase 5

Jim Richardson

December 19, 2014

*Repurposed work: Portions of this task contains material originally submitted by Jim

Richardson during the 1403A Session, Software Requirements Engineering CS455, with

Professor T. Atencio between July 6, 2014 and August 12, 2014 and during the 1404A Session,

Software Project Management SWE440, with Professor C. Tilden between October 5, 2014 and

November 11, 2014. Original submissions are the intellectual property of Jim Richardson and

Colorado Technical University Online.*

SOFTWARE DEVELOPMENT PLAN 2

Table of Contents Document Version Control and Revision History .......................................................................... 3

I. Project Outline – Phase 1......................................................................................................... 4

Functional System Features ............................................................................................. 4

Non-Functional System Features ..................................................................................... 7

Major Issues to Consider .................................................................................................. 8

II. Development Methodology – Phase 1 ............................................................................... 11

Justification .................................................................................................................... 15

III. Requirements – Phase 2 ..................................................................................................... 16

Requirements Table........................................................................................................ 18

IV. Design – Phase 2 ................................................................................................................ 22

Smartphone Architecture................................................................................................ 22

Operating Environment and System Architecture ......................................................... 23

Application Specifications and Architecture.................................................................. 24

Use Case Diagram .......................................................................................................... 26

Class Diagram ................................................................................................................ 29

Component Diagram ...................................................................................................... 30

Visual User Interface Design ......................................................................................... 30

V. Development – Phase 3 ...................................................................................................... 32

VI. Testing – Phase 3 ............................................................................................................... 34

Test Case 1: Login.......................................................................................................... 35

Test Case 2: View Financial Statements ........................................................................ 38

Test Case 3: Transfer Funds ........................................................................................... 43

VII. Project Schedule – Phase 4 ................................................................................................ 51

VIII. Risk Analysis – Phase 5 ................................................................................................. 54

Impact Scale ................................................................................................................... 56

Probability Scale ............................................................................................................ 56

Risk Identification and Risk Response Table ................................................................ 57

IX. References .......................................................................................................................... 64


Document Version Control and Revision History

Name Date Reason for Change Version Number

Jim Richardson 11/23/2014 Origination of the Software Development

Plan for Capstone Bank

1.0

Jim Richardson 12/01/2014 Added content regarding Requirements

Engineering, system architecture, and

design

1.1

Jim Richardson 12/06/2014 Added content to discuss Development

and Testing

1.2

Jim Richardson 12/13/2014 Added content to discuss the Project

Schedule

1.3

Jim Richardson 12/19/2014 Added Risk Analysis and finalized the

Software Development Plan

2.0


I. Project Outline – Phase 1

Recently, Capstone Bank discovered through market research that Capstone Bank’s

services were lacking luster to maintain a competitive edge within the financial industry.

Subsequently, Capstone Bank decided to explore options and solutions to regain their status as a

modern financial institution. Essentially, Capstone Bank aspires to regain their appeal to become

a worthy contender in the financial industry once again. During deliberations, the notion of

introducing a mobile banking application emerges. After considerable consideration, Capstone

Bank ascertains that the implementation and deployment of a mobile banking application would

restore Capstone Bank’s status and increase the image of their institution, as well as increase

revenue through an expanded clientele. Essentially, since mobility and portability are modern

conveniences, Capstone Bank determines that adding a new service, a mobile banking

application, to their existing legacy web-based and on-location banking services, Capstone Bank

will reach a new audience of users and appease the existing customers. Accordingly, Capstone

Bank begins to formulate the design, features, and services they wish to offer through the mobile

banking application. After Capstone Bank decides upon the overarching design, establishes the

fundamentals, and concludes the details of the mobile banking application, Capstone Bank issues

a formal Request for Proposal (RFP).

Accordingly, Capstone Bank determines that the Capstone Mobile Banking Application

(CMBA) will include the following functional and non-functional features:

Functional System Features

Functional System Feature Description

FSF001: Login The Login feature will allow the user/customer to enter their

account associated login credentials to access their established

Capstone Bank account(s), which includes personal checking,

personal saving, business checking, and business saving


accounts. The Login feature will provide the user with a screen

that allows the user to enter both their Capstone Bank user

identification name and password. The user’s login credentials

will coincide with Capstone Bank’s legacy web-based banking

service to minimize the need to remember multiple user names

and passwords.

FSF002: View Balances The View Balances feature will provide the customer with

opportunities to view their Capstone Bank account balance(s).

After entering the correct login credentials, the CMBA will

present a screen of options to select. Within this list of options,

the user will be able to select the View Balances option to view

the current balances of all associated and linked Capstone

Bank accounts.

FSF003: Transfer Funds The Transfer Funds feature will provide the customer with

opportunities to transfer funds between all associated and

linked Capstone Bank Accounts. Essentially, after entering the

correct login credentials, the CMBA will present a screen of

options to select. Within this list of options, the user will be

able to select the Transfer Funds option. After selecting the

Transfer Funds option, the user will be able to select the

sending and receiving accounts, enter the amount of funds to

transfer from the sending account to the receiving account,

specify the date in which the transfer should transpire, and

indicate the frequency in which this transfer transaction should

occur. Once the user enters the appropriate information, the

CMBA will communicate with Capstone Bank’s existing

database and application servers to verify the transaction,

perform the transaction, and update the user’s accounts with

the recent transaction. Upon confirmation and performed

account update, Capstone Bank’s database and application

servers will issue a confirmation number back to the CMBA to

display to the user.

FSF004: Make Photographed

Deposits

The Make Photographed Deposit feature will provide users

with opportunities to deposit checks into their corresponding

Capstone Bank account(s). Principally, after entering the

correct login credentials, the CMBA will present a screen of

options to select. Within this list of options, the user will be

able to select the Make Photographed Deposit. After selecting

the Make Photographed Deposit feature, the CMBA will

trigger the mobile phone’s enabled camera. Once the mobile

phone’s enabled-camera is active, the CMBA will prompt the

user to capture the images of the front and back of the check.

Link Once the CMBA collaboratively works with the

smartphone’s enabled camera to capture the images of the

check intended for deposit, the CMBA will prompt the user to

send the images for verification. Once Capstone Bank’s


database and application servers receive the images, Capstone

Bank’s database and application servers will attempt to verify

and confirm the deposit, perform the deposit, and update the

corresponding account with the deposit. Upon confirmation

and performed account update, Capstone Bank’s database and

application servers will issue a confirmation number back to

the CMBA to display to the user.

FSF0005: Link Accounts The Link Accounts feature will provide users with

opportunities to link multiple Capstone Bank accounts to one

username or one account. After entering the correct login

credentials, the CMBA will present a screen of options to

select. Within this list of options, the user will be able to select

the option to add or link accounts to their main Capstone Bank

user login name or main Capstone Bank account. In the event

that user selects the Link Accounts options, the CMBA will

present a screen to the user to enter their corresponding

Capstone Bank account’s information intended for linked

access. Once the user enters the correct account information,

the CMBA will prompt the user to send the information for

verification. Upon verification of the intended account for

linked access, Capstone Bank’s database servers and

application servers will associate and link the corresponding

accounts to the main Capstone Bank account and user name.

Once association is complete, Capstone Bank’s database

servers and application servers will update the main account

and user name with the linked accounts and issue confirmation

back to the CMBA. In addition to providing users with abilities

to link accounts, the Link Accounts feature will provide users

with opportunities to unlink previously linked accounts via the

same process of linking accounts.

FSF006: View Financial

Statements

The View Financial Statements feature will provide users with

opportunities to review a list of financial transactions

associated with their Capstone Bank accounts. Essentially,

after entering the correct login credentials, the CMBA will

present a screen of options to select. Within this list of options,

the user will be able to select the option to View Financial

Statements. After selecting the View Financial Statements

option, the user will be able to view all transactions associated

with their Capstone Bank accounts. The View Financial

Statements option will retrieve and display up to three months,

from the data of inquiry, of transaction data for the user’s

review. Essentially, once the user selects the View Financial

Statements option, the CMBA will query Capstone Bank’s

database servers to retrieve a list of transactions. Upon

retrieval of the list of transactions, Capstone Bank’s database

and application servers will transmit the information back to


the CMBA for display to the user.

Non-Functional System Features

Non-Functional System

Feature

Description

NFSF3000: Secure

Connection and Encrypted

Data Transfers

The CMBA will feature secure connection and encrypted data

transfers through Secure Socket Layer (SSL) network security

protocols. Once the user accesses and deploys the CMBA, the

CMBA will begin establishing a secure connection, utilizing

SSL network protocols, with Capstone Bank’s database and

application server. Upon establishing an SSL secure

connection with Capstone Bank’s database and application

servers, all information passed between the CMBA and

Capstone Bank, during the session, will remain under the

protection and encryption of the SSL connection.

NFSF3001: Prevention of

Simultaneous Logins

The CMBA Prevention of Simultaneous Login feature will

verify and confirm that only one instance of the user’s main

login information is accountable and logged in at a time.

Essentially, when logging into the CMBA or Capstone Bank’s

website, the Prevention of Simultaneous Login feature will

notify the user if his or her login credentials are in use on

another device or portal, such as the Capstone Bank website

and the CMBA. In the event that the user’s login credentials

are in use within another portal, both CMBA and the Capstone

Bank web portal will issue a notification prompting the user to

select an option. The options are to remain logged in on the

other portal or remotely log out of the other portal and log in

from the corresponding CMBA or Capstone Bank website. By

ensuring only one instance of login credentials are in use at a

time, Capstone Bank will provide the user with security and

peace of mind in knowing that their account cannot be

accessible simultaneously in more than one portal at a time.

NFSF3003: Application

Loading

The Application Loading non-functional requirement will

ensure the performance of the CMBA is optimal and congruent

with industry related parameters. Essentially, the Application

Loading non-functional requirement will ensure the CMBA

loads within a reasonable amount of time, such as within 3 to 5

seconds upon deployment.

NFSF3004: Refresh Rate The Refresh Rate non-functional requirement will ensure that

the CMBA’s performance is optimal and congruent with

industry related parameters. Essentially, the Refresh Rate non-

functional requirement will ensure the CMBA refreshes the

information, when account transactions require an update, in a


timely manner, such as the CBMA shall refresh the account

information, after a transaction, within 10 to 30 seconds.

NFSF3005: System Lock Out The System Lock Out non-functional requirement will ensure

the system locks the account after several failed attempts to

enter the correct login credentials. Essentially, the System

Lock Out feature and requirement will ensure the system locks

the CMBA out from entering additional attempts after the 5th

failed attempt. By locking the system out, this security feature

will safeguard the user and Capstone Bank against potential

hackers and unauthorized users. Once the system locks a user

out, the CMBA will be inaccessible for 30 minutes or

authorization from Capstone Bank’s system administrators.

NFSF3006: System Time Out The System Time Out requirement and feature will ensure that

the CMBA automatically severs and terminates the secure

connection, notifies the user that due to inactivity the mobile

banking application will close, and closes the CMBA.

Essentially, the System Time Out feature will initiate after

three minutes of inactivity within the CMBA. After three

minutes of inactivity, the CMBA will begin the termination

procedure. By implementing a time out feature into the

CMBA, customers will have the peace of mind in knowing that

their account information will be safe from accidental access

from unauthorized users.

Major Issues to Consider

In light of the fact that Capstone Bank has a legacy system in place, and the CMBA will

be an added service, there are several issues to consider. One issue Capstone Bank will need to

consider is the possibility that the legacy system will not have sufficient technology to manage,

control, process, and interface with modern mobile technology. Another issue Capstone Bank

will need to consider is how the legacy system will interact and function with the influx of

activity. For instance, since Capstone Bank has an existing website that offers banking from the

internet enabled and accessible devices, add the CMBA will increase traffic and access to

Capstone Bank’s internal database and application servers. Furthermore, in light of the fact that

Capstone Bank offers internet banking, adding mobile banking could pose the issue of


inconsistencies with data conversions, account information, transactions, and the ability to link

accounts.

Aside from performance issues and continuity between the mobile banking application

and the internet banking solution, another issue arises that Capstone Bank must consider is

security related. Essentially, with the addition of mobile banking services, Capstone Bank must

be aware that their legacy system will have additional points of entry and access into the legacy

system. Essentially, aside from the increase of traffic, which could result in denial of service,

Capstone Bank must consider the possibility of their legacy system experiencing a breach from

mobile devices. In addition, Capstone Bank must consider the possibility that the system may

prevent a transaction to process from one medium and not the other, resulting in fraudulent

activity. For example, if a user’s account has insufficient funds to perform a balance transfer, but

one medium or another does not recognize this deficiency, and performs the transfer, the

erroneous transaction could result in undesirable consequences for the user and Capstone Bank.

Lastly, another issue that could arise with the development of the CMBA is the issue of

unauthorized access. While the mobile banking application utilizes the same login credentials as

the web-based banking solution, Capstone Bank must consider the possibility of users storing

their login credentials on their mobile smartphone, and if stolen or lost, could result in

unauthorized access to the owner’s account information and funds. Subsequently, attempting to

prove or disprove such actions could be costly and detrimental for Capstone Bank or the account

owner.

Aside from performance and continuity issues, concerning development and

implementation of the CMBA, Capstone Bank’s CMBA development project is equally

susceptible to issues. For instance, Capstone Bank must consider and prepare for a lengthy


project that could cost more than the allocated budget. Specifically, in the event that Capstone

Bank continually alters the requirements or makes significant changes to the legacy system

during development of the CMBA, the CMBA project could result in negative consequences that

would require additional time, additional resources, and additional funds to compensate for the

changes or upgrades made to the legacy system. Furthermore, Capstone Bank faces another issue

when outsourcing the development of the CMBA, failure to complete the project. Even though

CMBA researched and hired a reputable software engineering organization, respective software

engineering organization could suffer from internal issues that would cause the project to fail,

such as incompetency, under allocated staff, inexperienced project managers, or the project

teams’ failure to adopt and commit to the project or the project’s software development life cycle

(SDLC) methodology. Moreover, the software engineering organization could fail to budget the

project’s schedule and budget inaccurately, which would result in failure to complete the project

or require additional funds to see the project come to fruition. Lastly, the CMBA development

project could suffer from unclear requirements that result in a program that does not meet

Capstone Bank’s initial business needs or actual requirements.


II. Development Methodology – Phase 1

Recently, AJAR Engineering entered contract negations with Capstone Bank to develop a

mobile banking solution, Capstone Mobile Banking Application (CMBA), which would extend

the existing services of Capstone Bank. Once AJAR Engineering and Capstone Bank agree upon

and establish a formal contract, AJAR Engineering must begin their project planning process.

Initially, before project development and planning can progress, AJAR Engineering must

research and select an appropriate Software Development Life Cycle (SDLC) Methodology to

govern and guide the project. Accordingly, after considerable deliberations, AJAR Engineering

concludes that the Scrum Methodology is the most appropriate approach to developing the

CMBA.

The Scrum Methodology is an Agile project management framework designed to assist in

completing complex projects through managing processes. Essentially, the Scrum Methodology

adheres to the agile software methodology manifesto in that, Scrum places emphasis on

communication and collaboration between stakeholders and the development team over focusing

on contract negotiations, software development processes, and software development tools.

Additionally, Scrum adheres to the concepts of concentrating upon developing functioning

software instead of relying heavily upon extensive and comprehensive documentation. Lastly,

Scrum Methodology aligns with the agile methodology’s approach of remaining flexible and

adapting to emerging business realities as they emerge, instead of adhering to a strict and

uncompromising software engineering approach (“Scrum Methodology”, 2014; Rouse, 2014).

Principally, specialized for software development projects, the Scrum Methodology is an

iterative and incremental approach to software development that focuses on team collaboration,

creativity, and short stints of development processes, also known as Sprints. Fundamentally,


Scrum bases development on capitalizing on small teams that collaborate in an intensive and

interdependent manner to achieve accomplishment of a project (Rouse, 2014).

Principally, a project implemented with Scrum principles and processes will function and

evolve through guidance and participation of three major roles. Scrum’s approach of employing

only three major roles is an attempt to capitalize upon flexibility and creativity. Essentially, the

three major roles within Scrum are Product Owner, Scrum Master, and the Scrum team.

Fundamentally, the Product Owner is responsible for facilitating communications between client

and software development team or the Scrum team. In addition to facilitating communication

between the client and the Scrum team, the Product Owner is responsible for ensuring that the

Scrum team realizes and maintains the product’s vision throughout the project by conveying the

client’s interest, software and business requirements, and levels of appropriate priority. While

other software development methodologies bestow the most authority to the project manager,

Scrum imparts the majority of authority upon the Product Owner. Therefore, in the event that the

project becomes awry, it is the Product Owner’s sole responsibility to devise, formulate, and

integrate a corrective course of action to resolve the project’s obliqueness (“Scrum

Methodology”, 2014).

The next major role within the Scrum Methodology is the Scrum Master. The Scrum

Master’s function is to act as a facilitator between the Product Owner and the Scrum team. While

the Scrum Master is an active facilitator between the Product Owner and the Scrum team, the

Scrum Master is not responsible for managing the Scrum team. Alternatively, the Scrum Master

is responsible for resolving or removing any obstacle that may impede the progress of the Scrum

team or accomplishing the current sprint’s objective. Essentially, the Scrum Master is

responsible for ensuring that the Scrum team has all the necessary components to generate and


nourish creativity, efficiency, and productivity throughout each project sprint. Additionally, the

Scrum Master must ensure that the project progresses successfully so that each sprint’s

accomplishments are visible and capable of placating the Product Owner. While the Scrum

Master is responsible for the success of each sprint, the Scrum Master also acts as an advisor to

the Product Owner. Generally, as an advisor, the Scrum Master has the opportunity to advise the

Product Owner with methods and approaches to maximize their return on investment (ROI) for

the entire project, as well as the project team (“Scrum Methodology”, 2014).

The last of the three major roles within the Scrum Methodology is the Scrum team

members. Principally, the Scrum team consists of a small number of cross-functional team

members that are capable of completing the predetermined work. Fundamentally, the cross-

functional team members should include a combination of software engineers, software

architects, software programmers, software analysts, software testers, software quality-assurance

experts, and software user-interface designers. Dissimilar from most conventional SLDC

Models, Scrum encourages the Scrum team to collaborate and determine how they will

accomplish each sprint. While providing the Scrum team with liberties and autonomy to manage

their own progression and approach to accomplish the sprint’s tasks, the Scrum team must also

be willing to accept the responsibilities of project failure or sprints gone awry (“Scrum

Methodology”, 2014).

Vitally, Scrum’s objectives are to increase and improve the software engineering teams’

efficiency by reducing the amount of processes and documentation required to complete the

project or produce a project’s iteration deliverable. As a result, Scrum’s approach to reduce the

amount of engineering processes and documentation relies upon Scrum’s nature of incorporating

a dynamic and living backlog of predetermined prioritized work. Furthermore, Scrum


concentrates on accomplishing conclusion of fixed sets of backlog of work items, rather

expediently, through short iterations, known as sprints. Generally, sprints are short iterations of

development that last from one week up to four weeks and produces work that is potentially

deliverable, such as implementation ready, marketable, or complete to the point of a working

demonstration. Accordingly, Scrum’s sprint deliverables are smaller portions of the whole

product and allows the team to build upon each portion throughout the project’s progression. In

lieu of extensive documentation, documented communication, or extensive electronic

correspondence, Scrum chooses to communicate directly with the team and stakeholders through

brief daily meetings, known as a scrum or scrum session. During scrum sessions, the Scrum

Master delineates the project’s progress, the Scrum team deliberates over the upcoming work and

descriptively explains the next sprint’s approach, and the Scrum Master and Scrum team

considers any project risks or obstacles that may impede the progress and objective of the next

sprint. Furthermore, the scrum session allows the Scrum Master and the Scrum team to expose

project risks and provides an opportunity for the risk mitigation management plan to receive due

diligence so that the next sprint progresses efficiently from lessons learned. In conjunction with

weekly scrum sessions, the Scrum Methodology exploits proactive approaches of suggesting

orchestration and incorporating opportunities to conduct planning sessions. During the planning

sessions, the Scrum team would organize and define the backlog of work items that would

become the focus for the next sprint. Lastly, similar to most SDLC Models, the Scrum

Methodology considers and benefits from conducting retrospective meetings after each sprint, in

which the engineering team would reflect upon the previous sprint and determine corrective or

alternative solutions to enrich and fortify the next sprint (“Software Development

Methodologies”, 2014).


Justification

AJAR Engineering ascertains that the Scrum Methodology is suitable for the CMBA

development project for the following justifications:

Scrum provides better opportunities for AJAR Engineering to gain more clear definitions and

understanding of the requirements through open and frequent communication with Capstone

Bank, which ensures the client and stakeholder’s desires come to fruition

Scrum is a cultural improvement in that Scrum advocates and promotes creativity,

collaboration, and communication among the AJAR Engineering’s project team, which

increases productivity and promotes quality

Scrum eliminates the feel of a dictatorship and empowers the AJAR Engineering project

team with control of the project, which increases job satisfaction

Scrum provides AJAR Engineering with opportunities to improve the processes and product

through lessons learned

Scrum’s focus of open and frequent communication provides AJAR Engineering with better

opportunities to develop exactly what Capstone Bank needs and a product that will suit

Capstone Bank’s business requirements

Scrum capitalizes upon Capstone Bank’s feedback to ensure the product is within

specifications

Scrum’s iterative and incremental approach ensures that Capstone Bank has a working

deliverable after each sprint, which engages and satisfies Capstone Bank’s apprehensions, as

well as provides ample opportunity for feedback to enhance the next iteration’s deliverable

Scrum’s backlog of work items facilitates AJAR Engineering in realizing the required work

and work schedule (“Features of Scrum”, 2014)


III. Requirements – Phase 2

With intentions of eliciting requirements, for the CBMA, from Capstone Bank, AJAR

Engineering will develop a specific requirements elicitation strategy. Accordingly, AJAR

Engineering’s requirements elicitation strategy will be a hybrid approach that consists of two

distinct formats, brainstorming sessions and informal interviews. Initially, AJAR Engineer will

assemble a team of qualified Business Analysts, Software Engineers, and System Analysts. Next,

the requirements team will meet with Capstone Bank’s key stakeholders to conduct a

brainstorming session. Essentially, the brainstorming session will be informal, relaxed, and

include a catered lunch. By providing an informal and relaxed atmosphere, AJAR Engineering

aspires to encourage creativity and free-flowing communication. During the brainstorming

session the requirements team will ask specific questions to provide Capstone Bank’s key

stakeholders with an opportunity to, freely, express their interpretation of what the CMBA needs

to feature so that the CMBA satisfies Capstone Bank’s business need. As the questions and

solutions evolve throughout the brainstorming session, the requirements team will note and

document the proposed solutions as they become final (Wiegers & Beatty, 2013, p. 48).

Once the brainstorming session concludes and all the elicited requirements documented,

AJAR Engineering will begin to storyboard the requirements to ensure AJAR Engineering has

significant information and requirements. After AJAR Engineering storyboards the requirements

and establishes a formal foundation for designing the CMBA, AJAR Engineering will create

Unified Modeling Language (UML) Use Case diagrams to present and verify the requirements

with Capstone Bank through informal interviews. Essentially, conducted informal interviews will

further clarify, expose, and identify issues with the requirements or provide Capstone Bank with

an opportunity to deliver or specify additional requirements. Principally, the informal interviews


will be intimate in nature. Specifically, the conducted informal interviews will transpire as AJAR

Engineering’s Business Analysts prepare a list of specific questions, meet with the key

stakeholders on a personal level, and discuss the requirements one-on-one. During the informal

interview, the Business Analyst will read from a list of predetermined open-ended questions

regarding the previously established requirements to gain additional clarity and understanding of

the client’s needs. As the stakeholder exposes the details of the requirements, the Business

Analyst will document the new information, take notes of the stakeholders’ body language and

reaction to the questions, and document any new information exposed. By conducting face-to-

face intimate interviews, AJAR Engineering aspires to establish a better rapport with Capstone

Bank and engage the client on a personal level so that the key stakeholders feel involved with the

project (Wiegers & Beatty, 2013, p. 48; Famuyide, 2013).

After conducting both the brainstorming requirements elicitation meeting and the

informal requirements elicitation interviews, AJAR Engineering and Capstone Bank determines

and establishes the following functional and non-functional requirements:


Requirements Table

Requirement/Feature

Functional/Non-Functional Category

Description Success Criteria Priority

1. FSF001: Login Functional The CBMA Login feature will

provide users with opportunities

to enter their associated

Capstone Bank web banking

account credentials to access

their Capstone Bank account

from their mobile smart device.

The Login screen will appear,

complete with text fields for

entering both username and

password.

Very High – Users

will require use of

this feature for each

session.

2. FSF002: View Balances

Functional The CBMA View Balances

feature will be an option that

will allow the user to view their

Capstone Bank current

account(s) balance(s) after

successfully logging in to the

CBMA Portal.

After logging in, a menu screen

will appear, presenting the

option to view balances. The

success criteria for the View

Balances feature will be, the

CBMA will present and display

the current balance(s) for the

selected account(s)

Medium – Users will

only select this

feature when they

want to view

balances.

3. FSF003: Transfer Funds

Functional The CBMA Transfer Funds

feature will be an option that

will provide account holders

with opportunities to transfer

funds between their associated

and linked Capstone Bank

accounts.



option to Transfer Funds. The

success criteria for the Transfer

Funds feature will focus on the

ability to transfer of funds from

one CBMA account to another,

add and subtract accordingly,

update accounts, and present

confirmation to the user.

Medium – Users will

only select to use this

feature when they

want to transfer

funds.

4. FSF004: Make Functional The CBMA Make After logging in, a menu screen Medium – Users will


Photographed Deposits

Photographed Deposits feature

will provide account holders

with opportunities to deposit

checks into their account by

photographing and submitting

images of both front and back

of the intended check.


option to Make Photograph

Deposits. The Success criteria

for this feature will revolve

around the ability to trigger the

camera, capture images, add the

deposit amount to the current

balance, update the account, and

present confirmation to the user.

only select this option

when they wish to

make a photograph

deposit.

5. FSF005: Link Accounts

Functional The CBMA Link Accounts

feature will provide account

holders with opportunities to

link several Capstone Bank

accounts and account types to

one main account and one set of

login credentials.



option to Link Accounts. The

success criteria of this feature

will revolve around the ability to

associate multiple accounts to

one set of user login credentials

and the main account.

Low – Users will only

select this option

when they wish to

link multiple unlinked

Capstone Bank

accounts to one set of

user login credentials.

6. FSF006: View Financial Statements

Functional The CBMA View Financial

Statements feature will provide

account holders with

opportunities to view an

account’s historical

information, up to three months

from the inquiry date, such as

deposits, debits, transfers, and

service fees.



option to View Financial

Statements. The success criteria

for this feature will revolve

around the ability to locate the

requested account, retrieve three

months of transactional

information, and display the

information on the user’s mobile

smart device via the CBMA.

Low – Users will only

select this option

when they wish to

confirm or view their

account’s

transactional

information.

7. NFSF3000: Secure Connection and Encrypted Data Transfers

Non-

Functional

The CBMA will feature and

provide SSL secure connections

and data encryption throughout

each session.

The success criteria for this non-

functional feature will revolve

around the ability to establish

and maintain the Secure

Connection and Data Encryption

Very High – The

system will require

secure connections

and encryption for

and throughout each


throughout. To verify the

CBMA has established a secure

connection and is encrypting

data, the CBMA will display an

icon, a shape of a shield, on each

screen, from the login screen to

each subsequent screen.

session.

8. NFSF3001: Prevention of Simultaneous Logins

Non-

Functional

The CBMA will feature

Prevention of Simultaneous

Login to verify and confirm that

only one instance of the user’s

account credentials are

accountable and logged into the

system at a time.



around the system’s ability to

confirm and verify that the

user’s login credentials are not

in use through another portal. If

the user’s credentials are in use

on another login portal, the

system will notify the user that

they are logged in elsewhere and

request action, such as log out

from the other location and log

in from the current location.

High – The system

will verify that the

user’s login

credentials only

appear once,

signifying an

established log in, in

the system at a time,

at the beginning of

each session.

9. NFSF3003: Application Loading

Non-

Functional

The Application Loading non-

functional requirement will

ensure the performance of the

CMBA is optimal and

congruent with industry related

parameters.




load the mobile banking

application within 3 to 5 seconds

from deployment.

High – The system

will verify that the

application loads

within the specified

time range at the

beginning of each

session.

10. NFSF3004: Refresh Rate

Non-

Functional

The Refresh Rate non-


ensure that the CMBA’s

performance is optimal and

congruent with industry related

parameters.




refresh the account with updated

information, after each

transaction, within 10 to 30

High– This non-

functional feature will

transpire with each

instance of a

transaction, such as

transfer funds, make


seconds of the transaction. deposits, and link

accounts.

11. NFSF3005: System Lock Out

Non-

Functional

The System Lock Out non-


ensure the system locks the

account after several failed

attempts to enter the correct

login credentials.




lock the system after 5 failed

attempts to enter the correct

login credentials. Once the

system locks a user out, the

CMBA will be inaccessible for

30 minutes or authorization from

Capstone Bank’s system

administrators.

Very High – This

non-functional feature

will be active for each

instance of logging

into the system.

12. NFSF3006: System Time Out

Non-

Functional

The System Time Out

requirement and feature will

ensure that the CMBA

automatically severs and

terminates the secure

connection, notifies the user

that due to inactivity the mobile

banking application will close,

and closes the CMBA.




detect inactivity of 3 minutes,

notify the user of inactivity,

terminate and sever the secure

connection, and close the

CMBA.

High – This non-

functional feature will

be active for each

instance of the system

being active, logged

on, and connected to

Capstone Bank.


IV. Design – Phase 2

Smartphone Architecture

The CMBA will be a new add-on service to Capstone Bank’s existing web based service,

legacy in-house system, and current network infrastructure. Since the CMBA will be a new add-

on service, the CMBA will rely upon Capstone Bank’s legacy system of database servers,

webservers, and application servers to communicate with Capstone Bank, retrieve information,

perform transactions, and update account information. Initially, the Samsung Galaxy S4 mobile

smart phone will be the piloting device for the CMBA, which will include initial design,

deployment, and testing. The Samsung Galaxy S4 specifications are as follows:

Operates on the Android operating system

Current version: Jelly Bean 4.2.2

1.9 Gigahertz (GHz) Quad-core processor

5-inch full high-definition (HD) super Active Matrix Organic Light-Emitting Diode

(AMOLED) touch screen display

Offered in 16, 32, and 64 gigabit (Gb) capacities

Capable of communicating across second and one half generation (2.5G), third

generation (3G), and fourth generation long-term evolution (4G LTE) mobile networks

The S4 utilizes two cameras, front-facing camera and a back-facing camera

o S4’s back-facing camera is capable of capturing images up to 13 Mega pixels

o S4’s front-facing camera captures images up to 2 Mega pixels

Air Gesture and Air View enabled

Touchscreen interface

Touchscreen QWERTY Keyboard

Integrated Microphone and Speakers

Global Positioning System (GPS) enabled

(“Samsung Galaxy S4”, n.d.)


Operating Environment and System Architecture

Capstone Bank’s legacy system will consist of a network of distributed systems, which

will consist of the Hewlett-Packard Moonshot Server System. The system’s operating

environments will consist of Hewlett-Packard database servers, Hewlett-Packard webservers,

Hewlett-Packard switches and hubs, Hewlett-Packard application and login servers, and Hewlett-

Packard desktop terminals. Currently, Capstone Bank’s operating system comprises of Red Hat

Enterprise Linux (RHEL) Release 19, which seamlessly interfaces and communicates with

Capstone Bank’s Hewlett-Packard servers. Capstone Bank’s database servers utilize Microsoft’s

Structured Query Language (SQL) Server 2008-R2 database software application to store data,

perform various procedures, and maintain account information. In order to maintain secured

sessions and data encryption, Capstone Bank will employ SSL network protocols. Accordingly,

the Hewlett-Packard Moonshot Server System’s specifications are as follows:

HP Moonshot Chassis (per chassis)

o Supports shared power, cooling, management, and fabric for 45 individual hot-

plugged server cartridges

HP ProLiant m300 Server Cartridges (per cartridge)

o Dynamic content delivery of Web Services

o Intel Atom C2750 Processor

o Integrated Security Operations Center (SOC)

o 32Gb of RAM per node

o 1terabyte (TB) Serial Advanced Technology Attachment (SATA) Hard disk drive

(HDD)

o Controllers Embedded in SOC

o Operating System - RHEL

HP ProLiant m700 Server Cartridge (per cartridge)

o Hosted Desktop and Mobile Infrastructure

o 4 x Advanced Micro Device (AMD) Opteron X2150 Accelerated Processing Unit

(APU)

o 8Gb of RAM per node

o 32Gb per APU

o SOC Embedded Controllers


o Operating System – RHEL

o Database server software – Microsoft SQL Server 2008 R-2

HP Moonshot - 6SFP Uplink Module

o 1Gb Ethernet

o Low-latency

o 6 – 10 Gigabit Ethernet (GbE) Small Form-Factor Pluggable Transceiver Module

Plus (SFPTM+) uplink ports

o 45 1GbE downlink ports

HP Moonshot – 45G Switches

o 1Gb Ethernet

o Low-latency

o 180 – 1GbE downlink ports

o 4 – 40GbE Quad Small Form-Factor Pluggable Plus (QSFP+) uplink ports

(“HP Moonshot System”, 2014; Lohrey, 2011; “FAQs for QSFP+”, 2014)

Application Specifications and Architecture

o Programming for the CMBA will consist of Java’s version 7.0 programming

language coding conventions and syntax protocols

o Programming for the CMBA will be RHEL compliant

o Programming for the CMBA will be Microsoft SQL compliant and use SQL Data

Manipulation Language (DML) and Data Definition Language (DDL) commands

to interface with Capstone Bank’s database servers.

o Data transmission will transpire through Capstone Bank’s current web services

o Utilizing DML and DDL commands, Capstone Bank’s predetermined User

Defined Functions and stored procedures will be able to perform the following

actions and duties:

Verify login credentials

Verify account

Locate account

Retrieve account information

Transmit account information

Perform fund transfers

Update account information

Add and subtract funds

Verify photographed images of checks to perform photograph deposits

View balances

Retrieve historical information for Financial Statements


Issue error and confirmation messages

Link accounts

Monitor inactivity and terminate the connection after three minutes of

inactivity

The CMBA will consist of six main components, Login, View Balances, Transfer Funds,

Photograph Deposits, Link Accounts, and View Financial Statements. While the CMBA has six

main components, not all components will require existence or deployment of another

component. For example, the Link Accounts component will not require activation or use of the

View Balances component. However, all components will require activation and access to the

Login component before operating. Overall, the normal progression of the CMBA will flow as

such:

a. User locates and deploys the CMBA

b. Upon deployment, the CMBA begins to establish a secure connection with Capstone

Bank

c. Once a secure connection is established, the CMBA presents the Login screen to the

user

d. User enters the correct login credentials and submits them for verification

e. Upon verification, from Capstone Bank’s database server, the CMBA displays a

menu of options, which includes the five remaining components/features

f. From the menu of options, the user selects a component/feature, such as View

Balances. The CMBA then sends a request to Capstone Bank to query the database

for the corresponding account balance

g. After the user verifies the account balance, the user returns to the menu screen to

select another option or log off the system


Use Case Diagram


Sample: detailed view for the Make Photographed Deposit Use Case and corresponding Use

Case Scenario:

Use Case ID: UCS4

Use Case

Name:

Make Photographed Deposit

Created By: Jim Richardson Last Updated By: Jim Richardson

Date Created: November 30, 2014 Date Last

Updated:

November 30, 2014

Actors: Customer, Samsung Galaxy S4, and Capstone Bank’s server system (includes:

webserver, database server, application server, and network server)

Description: The Make Photographed Deposit feature provides customers with

opportunities to make deposits from their mobile smart device by capturing

images of the check and sending them, wirelessly, to Capstone Bank’s sever

system.

Trigger: Customer clicks on the Make Photograph Deposit option from CMBA’s main

menu

Preconditions: 1. The user must have the CMBA installed on their mobile smart device

2. The user must have a qualifying Capstone Bank account

3. The user must have login credentials

4. The user must have a camera enabled mobile smart device

5. The user must have a qualifying check to deposit

6. The user must sign the check appropriately

7. The user’s mobile smart device must have sufficient network connection

to transmit images


8. Capstone Bank must be able to receive transmitted images

9. Capstone Bank must be able to verify images

10. Capstone Bank must be able to perform deposits

11. Capstone Bank must be able to update accounts

Postconditions: 1. Capstone Bank receives the transmitted images

2. Capstone Bank verifies the images

3. Capstone Bank performs the deposit

4. Capstone Bank updates the account

Normal Flow: 1. The user clicks on the CMBA

2. The CMBA and Capstone Bank’s server systems establish a secure

connection

3. The user enters their corresponding Capstone Bank login credentials

4. The user submits the login credentials

5. Capstone Bank confirms the login credentials

6. Capstone Bank locates the corresponding account information

7. The CMBA presents a menu screen

8. The user selects the option to make a photographed deposit

9. The CMBA responds by enabling the mobile smart device’s camera

10. The user captures the appropriate images

11. The CMBA prompts the user to transmit the images

12. The user elects to transmit the images

13. The CMBA transmits the images to Capstone Bank

14. Capstone Bank’s server system receives the images

15. Capstone Bank’s server systems verify authenticity of the images

16. Capstone Bank’s server systems locates the appropriate account

17. Capstone Bank’s server systems retrieves the corresponding account

18. Capstone Bank’s server systems performs the deposit

19. Capstone Bank’s server system updates the account to reflect the deposit

20. Capstone Bank’s server system issues confirmation

21. The CMBA receives confirmation

22. The CMBA displays the confirmation and updated account balance

reflecting the deposit

Alternate Flow: 1. User clicks on mobile banking application 2. A secured session fails to establish 3. User enters invalid login credentials 4. Database is unable to confirm or verify the login credentials 5. Database fails to retrieve customers’ account 6. Menu screen does not display 7. User submits an unacceptable photograph(s) 8. Check is not properly endorsed 9. The secured session terminates during the process

Exceptions: Capstone Bank’s system administrators will have liberties of overriding the

system and performing manual deposits. Capstone Bank’s server systems will

be inaccessible during routine maintenance.


Class Diagram


Component Diagram

Visual User Interface Design

Figure 1: CMBA Login Screen


Figure 2: CMBA Main Menu

Figure 3: CMBA View Balances Screen


V. Development – Phase 3

When developing software products or applications such as the Capstone Mobile

Banking Application (CMBA), using the Scrum Methodology, development processes progress

as sprints. Sprints, by Scrum definition, are repeatable work cycles that transpires throughout a

specific amount of time, such as one-week, two-weeks, three-weeks, and a month. Generally, the

team decides the length of the sprint for each iteration of the project. Typically, scrum teams

favor shorter sprints, but depending on the project’s nature, the scrum team may opt for longer

sprint cycles. Nonetheless, during each sprint, the scrum team will create a shippable product.

According to the project, these shippable products may be basic in nature or can be fully

functioning portions of the product. However, due to limited timeframes, iteration release

products focus on essential functionality. Essentially, the scrum team places emphasis on using

code that works (“Scrum Sprint”, 2013).

To ensure the scrum team has a specific agenda and realizes which portion of the product

to code during each sprint, the Product Owner prioritizes the product’s most essential features

and backlogs them accordingly as upcoming milestones to attain. When the team produces a

successful version of the product, from the prioritized backlog, the team then moves forward

with the project and builds upon the previous released version. To ensure the scrum team is

aware of the prioritized backlog of product features, the scrum team begins each sprint session

with a sprint-planning meeting to discuss upcoming sprint’s agenda with the Product Owner.

During these sprint-planning meetings, the scrum team and the Product owner create storyboards

of the planning process to use during the upcoming sprint. Generally, the storyboards contain

four main columns, Release Backlog, Sprint Backlog, Working On section, and Completed Work

(“Scrum Sprint”, 2013: Csaba, 2013).


Generally, the Release Backlog column will contain stories that relate to the current

release and provides the scrum team with a foundation to begin the next sprint. The Release

Backlog also serves as demonstration of milestones met and completed. Next, the Sprint Backlog

column will contain the plan for the upcoming sprint. Typically, for the upcoming sprint, the

scrum team and Product Owner negotiate the needs and wants for this sprint by performing

estimation analysis on the difficulty of items that pertains to the upcoming sprint’s story.

Essentially, the Sprint Backlog items become the new milestones to accomplish. Once negations

are complete, the scrum team begins the coding process to complete the stories in the Sprint

Backlog column. To indicate which portion of the story the team is coding currently, the scrum

team will remove the respective item from the Sprint Backlog column and place it in the

Working On column. By placing or noting the specific item in the Working On column, the

scrum team is demonstrating communication of their progress. As stories come to conclusion,

the respective scrum team moves and denotes the corresponding story in the Completed Work

column (Csaba, 2013).

Before placing an item or story into the Completed Work column, the team must

establish criteria for specific levels of completion, such as the design must be minimalistic, there

should be a mockup or prototype of the user interface, the written code should function properly,

testing should transpire, and functional or acceptance tests must pass. Since Scrum does not

focus on extensive documentation, but instead focuses on stories, which are the proposed

features or functions from the end user’s perspective, to gauge or track the progression of the

project, the scrum team utilizes Tasks or Sub-Stories. Generally, Tasks or Sub-Stories are short

synopses from the developer’s perspective that indicate precisely where their progress lies in

relation to the main user story they are working on. Essentially, these Tasks or Sub-Stories


define the developer’s current task and progress, to which functions as a method to identify and

track milestones (Csaba, 2013).

VI. Testing – Phase 3

AJAR Engineering elects to adopt and adhere to the Scrum Methodology for the

development of Capstone Bank’s Mobile Banking Application. In light of the fact that Scrum

delivers functioning product components at the end of each sprint, testing necessitates

coexistence within the same sprint that originates and creates a working and deliverable

component. Essentially, to ensure the component functions properly, each deliverable unit

requires testing. Therefore, once the initial phase of coding concludes, and before releasing the

product to the stakeholders, each iterative release must endure testing. Furthermore, before each

iterative release is ready for deployment, and after initial testing, the respective tested component

must have ample time to endure modification or adjustments according to the test results before

the sprint expires. However, since AJAR Engineering and the incorporated Scrum Methodology

focuses on compiling with working code and delivering basic functionality, AJAR Engineering

will require a test plan that corresponds with their sprint parameters. Accordingly, AJAR

Engineering’s test plan for each sprint will consist of Black Box Unit Testing, Black Box

Integration Testing, White Box Usability Testing, and Whit Box Automated Regression Testing.

Once the final component is ready for implementation, AJAR Engineering will add Black Box

System Testing to the test plan. By incorporating Black Box System Testing near the end of the

project’s lifecycle, AJAR Engineering will be able to ensure the system functions as completely

integrated units.


Accordingly, AJAR Engineering will use the following test cases for both manual and

automated testing:

Test Case 1: Login

Test Name: TC1: Login

Description: The login feature will prompt the user to enter their corresponding pre-

established Capstone Bank login credentials. Login credentials will consist of

username and password. For security purposes, upon entry of the user’s

password, the system will mask the user’s password with asterisks to conceal

the text from unauthorized users.

Requirement(s): FSF001: Login

Prerequisites: A database must be in place and the database must have capacities to

interface with the mobile banking application. A webserver and application

server must be in place to communicate with the database and smartphone.

The database must transmit and receive data across an SSL network

connection. The user must be a preexisting customer with Capstone Bank

and have a valid account. The user must have Capstone Bank pre-established

and recognized login credentials to access their Capstone Bank account(s)

information.

Setup: Tester will begin by ensuring installation of the Capstone Mobile Banking

Application (CMBA) is on the testing device, the Samsung Galaxy S4. The

Tester will launch the CMBA to initiate a secured session. All transmitted

data between the smart device, the webserver, the application server, and the

database servers will experience encryption through the SSL connection.

After establishing a secure session between the webserver, application server,

and the database server and the smart device, the login screen appears

prompting the user to enter their associated login credentials. Once the user

enters their corresponding Capstone Bank login credentials, the user/tester

will submit them for verification to access their account. User’s credentials

will be masked, as entered, to maintain security.


TC1: Login Start Time Stop Time Tester:

Step Operator Action Expected Results Observed Results Pass

/

Fail

Severity of

Failure

1. Turn on smart

device

The phone should power up

2. Open Capstone

Mobile Banking

Application by

clicking on the

icon

The icon should be visible and should

initiate connection when clicked by

displaying an hourglass until connection

is established

3. Wait for access The webserver receives the request and

verifies that the application is seeking to

establish a secure session

4. Wait for access The webserver confirms the application

and returns data to display the login

screen as verification that a secure

session is established between the

database and the smart device

5. View Results The login screen should be visible with

prompts for login credentials

6. Enter login

credentials

Text fields will have sample information

displayed, in gray text, so that the user is

aware of what information belongs in the

corresponding login fields. User will

start to enter information, by clicking on

the appropriate field, and the grayed out

text will disappear as the user’s entries


replace the greyed out sample text.

User’s password credentials should be

masked, as entered, to maintain security.

7. Submit login

credentials

The user will enter correct login

credentials and submit for verification.

User’s credentials should be masked, as

entered, to maintain security.

8. Waiting for results The webserver will receive the

information and pass the credentials

along to the database server for

verification.

9. Waiting for results Once the database server receives the

login credentials from the webserver, the

database will attempt to verify

authenticity.

10. Waiting for results Upon verification from the database, the

database will locate and retrieve the

corresponding account information.

Then, the database will issue

confirmation back to the webserver for

transmission back to the mobile smart

device, resulting in; the CMBA will

display the main menu screen.


Test Case 2: View Financial Statements

Test Name: TC2: View Financial Statements

Description: The View Financial Statements option is part of a menu that appears, as a

result, after entering correct login credentials and receives verification from

the database server. The View Financial Statements option provides the

customer with options to view their account’s transactional history, up to 6

months’ worth of information from the request date, for the selected account.

Requirement(s): FSF006: View Financial Statements


interface with the webserver. The webserver must have capacities to interface

and communicate with the mobile banking application. The webserver must

transmit and receive data across an SSL network connection. The user must

be a preexisting customer with Capstone Bank and have a valid account. The

user must have Capstone Bank pre-established and recognized login

credentials to access their Capstone Bank account(s) information. The user

must have, at least, one valid and open account with transactional history that

is within the 6 month, from the request date, range. The account numbers

will only be displayed as the last four digits of the account.











will be masked, as entered, to maintain security. The database server will

verify the login credentials, locate the corresponding account, and transmit

data back to the mobile application prompting the mobile application to

display the menu screen as verification of successful login and account

verification. The tester will begin by selecting the View Financial Statement

option. Once the user selects the View Financial Statement option, the

CMBA will transmit the request to the webserver. The webserver will

forward the request to the database server. The database will locate and


retrieve the account balance, transactional history, and transmit the data back

to the mobile smart device via the webserver. The mobile smart device will

sustain the SSL connection, receive the data, and display the transaction

history on the screen for verification. The tester will have the ability to view

6 months’ worth of transactions, from the date of inquiry, by scrolling

through the transaction history.


TC2: View Financial

Statements

Start

Time

Stop

Time

Tester:


/

Fail

Severity of

Failure

1. Turn on smart device The phone should power up

2. Open Capstone

Mobile Banking

Application by

clicking on the icon



displaying an hourglass until connection

is established






screen as verification that a secure

session is established between the

database and the smart device



6. Enter login credentials Text fields will have sample information



corresponding login fields. User will

start to enter information, by clicking on

the appropriate field, and the grayed out

text will disappear as the user’s entries

replace the greyed out sample text.

User’s password credentials should be


masked, as entered, to maintain security.

7. Submit login

credentials






information and pass the credentials

along to the database server for

verification.




authenticity.



corresponding account information.

Then, the database will issue

confirmation back to the webserver for

transmission back to the mobile smart

device, resulting in; the CMBA will

display the main menu screen.

11. Selects the View

Financial Statements

option from the menu

From the main menu, the tester will

select the option to View Financial

Statements. Then, the tester will select

which account to view the corresponding

financial statement. The mobile smart

device should send a request to the

database server via the webserver, the


database server should query the

database, through predefined functions

and user defined SQL scripts, and the

database should return the corresponding

6 months’ worth of transaction history to

the CMBA via the webserver. While the

database performs the queries, the

hourglass should reappear, signifying a

transaction is in progress

12. Waiting for results While the database server locates the

account and performs the queries,

through predefined functions and user

defined SQL scripts, the hourglass

reappears indicating the process is in

progress

13. Waiting for results Once the database server locates and

retrieves the corresponding account’s

financial statement, the database server

will transmit the financial statement, via

the webserver, back to the CMBA for

display

14. View Financial

Statement

Once the CMBA receives the data, the

CMBA will display the corresponding

account’s financial statement for review.


Test Case 3: Transfer Funds

Test Name: TC3: Transfer Funds

Description: The Transfer Funds option is part of a menu that appears, as a result, after

entering correct login credentials and receives verification from the database

server via the webserver. The Transfer Funds option provides the customer

with options to transfer funds between linked accounts, such as from

checking to saving or vice versa.

Requirement(s): FSF003: Transfer Funds


interface with the webserver. The webserver must have capacities to interface

and communicate with the mobile banking application. The webserver must

transmit and receive data across an SSL network connection. The user must

be a preexisting customer with Capstone Bank and have, at least, two valid

accounts. The user must have Capstone Bank pre-established and recognized

login credentials to access their Capstone Bank account(s) information. The

user must have, at least, two valid and open accounts with sufficient funds to

transfer. The transfer amount must not exceed the sending account’s current

balance. The account numbers will only be displayed as the last four digits of

the account.











will be masked, as entered, to maintain security. The database server will

verify the login credentials, locate the corresponding account, and transmit

data back to the mobile application prompting the mobile application to

display the menu screen as verification of successful login and account

verification. The tester will begin by selecting the Transfer Funds option. The

database will locate and retrieve all available account balances and transmit

the data back to the mobile smart device. The mobile smart device will


sustain the SSL connection, receive the data, and display the account

balances on the CMBA screen for verification. The CMBA will then offer

the option to transfer funds between available accounts. The tester will enter

a transfer amount, which does not exceed the current balance, from the

transferring account and select the sending from and receiving accounts.

There will be two open, valid, and available test accounts with test data to

conduct the transfer, checking and saving. The current balance will be

$123.45 in the checking account and $67.89 in the saving account.


TC3: Transfer Funds Start

Time

Stop

Time

Tester:


/

Fail

Severity of

Failure

15. Turn on smart device The phone should power up

16. Open Capstone

Mobile Banking

Application by

clicking on the icon



displaying an hourglass until connection is

established






screen as verification that a secure session

is established between the database and

the smart device



20. Enter login credentials Text fields will have sample information



corresponding login fields. User will start

to enter information, by clicking on the

appropriate field, and the grayed out text

will disappear as the user’s entries replace

the greyed out sample text. User’s

password credentials should be masked,


as entered, to maintain security.

21. Submit login

credentials






information and pass the credentials along

to the database server for verification.




authenticity.



corresponding account information. Then,

the database will issue confirmation back

to the webserver for transmission back to

the mobile smart device, resulting in; the

CMBA will display the main menu

screen.

25. Selects Transfer Funds

from the main menu of

options

From the main menu, the tester will select

the option to Transfer Funds. Then, the

tester will select which accounts to

transfer funds between. The mobile smart

device should send a request to the

database server via the webserver, the

database server should query the database,

through predefined functions and user


defined SQL scripts, and the database

should return the corresponding available

accounts, complete with current balances,

back to the CMBA via the webserver.

While the database performs the queries,

the hourglass should reappear, signifying

a transaction is in progress

26. Waiting for results While the database server locates the

account and performs the queries, through

predefined functions and user defined

SQL scripts, the hourglass reappears

indicating the process is in progress

27. Waiting for results Once the database server locates and

retrieves the corresponding available

account’s current balances, the database

server will transmit the balances, via the

webserver, back to the CMBA for display

28. View Financial

Statement

Once the CMBA receives the data, the

CMBA will display the corresponding

account’s current balances for review.

29. Select accounts to

transfer funds between

Once all available account balances are on

display, the CMBA will prompt the user

to select the appropriate accounts to

transfer funds between


30. Select accounts From the list of available accounts, the

user will select the sending account and

the receiving account. Then the CMBA

will prompt the user to enter the transfer

amount. The transfer amount must not

exceed the current sending account’s

current balance. The test data will reflect a

checking account balance of $123.45 and

a saving account balance of $67.89. The

account numbers will only be displayed as

the last four digits of the account number.

31. Transfer Funds The tester will perform the transfer by

submitting the request to Capstone Bank.

The CMBA will send the request to

Capstone Bank’s database server, via the

webserver, to perform the transfer.

According to the test data, the tester will

attempt to transfer $7.11 from the

checking account to the saving account.

The sending account will have a right facing

arrow displayed behind the account balance

and the receiving account will have a left

facing arrow behind the account balance.

The account numbers should only be

displayed as the last four digits.

32. Submit Transfer Funds

Request

After selecting the sending account, the

receiving account, and entering the

amount to transfer, the tester should see


an hourglass icon, that indicates the

transfer is in progress, after submitting the

transfer funds request

33. Waiting for results The hourglass icon, signifying a

transaction is in progress, should maintain

visible until the transaction is complete.

34. Receive Request The hourglass icon should remain visible

while the transaction is in progress. Once

Capstone Bank’s database server receives

the transfer request, via the webserver, the

database server will activate the

corresponding SQL commands to verify

the transfer.

35. Perform Transfer Once the database confirms the transfer,

the database will perform the transfer,

using SQL commands, by debiting the

transfer amount from the sending account

and crediting the receiving account with

the transfer amount. According to the test

data, the transferred amount of $7.11

should result in the checking account

should have a new balance of $116.34 and

the saving account should have a new

balance of $75.00

36. Update Account Once the database performs the transfer,

the database will update the corresponding


Balances accounts to reflect the transfer. the

checking account should have a new

balance of $116.34 and the saving account

should have a new balance of $75.00

37. Final Transmission Once the database completes the transfer

and account balance updates, the database

will transmit confirmation, via the

webserver, back to the CMBA for display

and review. Once the user/tester finishes

reviewing the transfer confirmation, the

CMBA will provide options to Return to

the main menu or perform another

transfer.

38. View Confirmation A confirmation screen should be visible

with updated account balances. The

checking account should reflect the

transfer with a balance of $116.34 and the

saving account should have a new balance

of $75.00. The account numbers should

only be displayed as the last 4 digits of the

account number.


VII. Project Schedule – Phase 4

For convenience and better organization, the Project Schedule, major milestones for the

project, subsequent detailed tasks, Gantt chart, and Network diagram depicting the critical path

are included in the Microsoft Project Computer Aided Software Engineering (CASE) Tool.

Figure 4: Link to Capstone Bank MS Project File

Jim Richardson

Software Engineering Capstone 1 SWE481 Phase 4 IP.mpp

Generally, all the scheduled times are best-case estimates. In order to ensure true

flexibility of the project, we incorporated float time. Float time, in project management, means

that a task can begin later in the sprint and its lateness will not delay the overall project or

specific sprint (“Leads, Lags and Floats”, 2014). For example, within each sprint, the project

team needs to review specific standards, protocols, and independent plans, such as

communication plans and human resource plan, but those tasks are viewable at any time

throughout the sprint. By incorporating float time, the project team can view the task important

plans, protocols, and standards as they apply to their specific task. If we did not incorporate float

time for these tasks, the project team may forget or omit a critical step later in the sprint.

Therefore, by incorporating float time tasks are more applicable and capable of corresponding to

the current task. Furthermore, by implementing base-case estimates, the schedule has extra time

built in to ensure that float time is achievable. For example, most of the testing tasks, both Black

Box and White Box testing conventions, have a list time of two days. However, due to

automation and reusable test scripts, general testing will not require both days to complete. By


padding the schedule by one day, we are not only capable of floating tasks but also consuming

the extra time for tasks that encounter difficulties that would endanger the overall schedule.

In order to track the progress of each task, the project team will move their story point to

the Completed Work section on the project storyboard. This will not only demonstrate to the

team which tasks are complete, but this convention will also illustrate the percentage of

completion. In addition to moving story points to the Completed Work section, the Scrum Master

will update the MS Project Capstone Bank project file with color-coded schemes. Essentially,

before the project initiates, the entire MS Project, in Gantt chart view, will be in red. After each

task concludes, the Scrum Master will update the file with the following color-coded schema:

Green = 100% Complete

Blue = 75% to 99% Complete

Yellow = 50% to 74% Complete

Orange = 25% to 49% Complete

Red = 0% to 24% Complete

In addition to the color-coded schema of designating the percent of completion, the Gantt chart

time line will illustrate the percent complete with the following convention:

Figure 5: Sample screen shot of color-coded schema


As an attempt to verify the completion of tasks, the project team will also utilize Sub-

Stories to confirm that their chosen task is complete. Essentially, Sub-Stories are short synopses,

from the developer’s perspective, that indicate precisely where their progress lies in relation to

the main user story they are working on. Essentially, these Tasks or Sub-Stories define the

developer’s current task and progress, to which functions as a method to identify and track

milestones (Csaba, 2013). Additionally, Project Capstone Bank will utilize metrics, such as the

Release Burn down chart, to depict the progress of each task visually. A Release Burn down

chart is a method that Scrum utilizes to track the progress of a sprint or the project against the

overarching release plan. Essentially, a burn down chart graphically illustrates each sprint or task

and depicts the amount of work remaining to completion. As each task or sprint concludes, the

graph will display a downward connecting plotted line that will correspond with the amount of

days, stories, or tasks left to complete before the project concludes. For example, in Project

Capstone Bank, the estimated time to completion is 73 days. The burn down chart would display

the amount of days on the left as a vertical axis. Then along the bottom, the burn down chart

would display the number of sprints as the horizontal axis. As each sprint concludes, the graph

would display a downward progression until all sprints conclude on the last day (“Release

Burndown Chart”, 2014). To illustrate this further, please review the following graph:

Figure 6: Sample Sprint Burn Down Chart for Capstone Bank


VIII. Risk Analysis – Phase 5

“A project risk is an uncertain event that, if it occurs, will have either a positive or a

negative effect on the prospects of achieving project objects” (“What is a project risk”, n.d.).

Accordingly, an uncertain event is something that may or may not happen but must experience

identification, evaluation, and definition so that the project team may establish a mitigation plan

for preparedness. Positive or negative effects are the result and consequences that ensue if a

project risk comes to fruition. As each project begins and progresses, each project must endure

the process of identifying, evaluating, and defining risks so that the project may experience fewer

obstacles that prohibit the success of the project or the project’s objectives. Essentially, this is a

Risk Management Plan. As defined by the Project Management Institute (PMI), Project Risk

Management is a predetermined set of processes that formulates the orchestration of risk

management planning, risk identification, risk analysis, methods and practices of responding to

risks, and establishes the procedures for monitoring and controlling risks within a project.

Fundamentally, Project Risk Management objects to decrease the probability and reduce the

impact of negative events while aspiring to increase the prospects of capitalizing upon positive

impacts from positive events (PMI, 2009, p. 4). In conjunction with our chosen software

development model, Scrum, project risks remain under the same category and definition.

However, the Risk Management Plan is different from other more traditional software

development models’ Risk Management Plan.

Within the Scrum software develop model, Risk Management is different because Scrum

develops software in Sprints. Therefore, with each sprint, risk management begins anew and

progresses throughout each sprint until the sprint concludes. Each sprint requires its own risk

management plan because the objectives of each sprint may differ from the previous and


subsequent sprint. Nonetheless, the overarching agenda of the Project Risk Management Plan

remains unchanged. Specifically, even in conjunction with the Scrum Model, Risk Management

follows the same set of processes, which are Identify, Assess, Respond, and Review.

Figure 7: Risk Management Processes

(Yegi, 2014)

With the concepts of Risk Management in mind, clarified, and understood, we now begin

to evaluate the project risks for the development of Capstone Bank’s mobile banking application.

Principally, Risk Management will be a collaborative effort of the entire project team, Scrum

Master, and Product Owner. Risk Management will transpire during each session’s pre-sprint

and post-sprint Scrum meetings. Accordingly, the following Risk Identification and Risk

Response matrix will demonstrate and elucidate the risks for Project Capstone Mobil Banking. In

conjunction with the Risk Identification and Response Matrix, we will use the following Risk

Impact Scale and Risk Probability Scale to measure the risks.


Impact Scale

Consequence Ranking Impact on Project Relocation

Extreme (9 -10) Complete Failure to attain/accomplish project

objectives

High (7-8) Severe extension of the project’s schedule and

budget

Moderate (5-6) Moderate delays, but recoverable, and

moderate costs incurred

Low (3-4) Slight Impact and minimal delay to the

project

Negligible (1-2) Little to No Concern

Probability Scale

Probability Ranking Probability of Risk Occurrence

Not Probable (NP) 0 - 1% chance of occurring

Low Probability (LP) 2 – 4% chance of occurring

Moderate Probability (MP) 5 – 7% chance of occurring

High Probability (HP) 8 – 10% chance of occurring

Expected (E) >10% chance of occurrence


Risk Identification and Risk Response Table

Risk Name Risk Description Risk

Potential

Ranking

(1 -10)

Risk

Impact

Ranking

(1-10)

Risk Impact Description Risk

Response

Type

Risk Mitigation Description

1. Users

Resistance to

Change

Users have attachment

to legacy systems,

familiar tools, and

existing software.

Therefore, when

introducing change, it

is possible that

Capstone Bank’s

employees will resist

interfacing with the

new Capstone Mobile

Banking Application,

which could result in

maintaining legacy

solutions or request

changes that would

result in a subpar

system.

8 10 If end users refuse to interact or

accept the new changes of the

software structure of Capstone

Bank, they could influence the

stakeholders into requesting

changes to the User Interface or

other components of the

system. Introducing too many

changes would have a negative

impact on the project’s

schedule and budget.

Furthermore, if the project team

continuously accepts and

implements the changes, the

new changes could hinder the

performance of the system,

resulting in customer

dissatisfaction.

Accept We will accept and implement a

certain degree or amount of

changes to ensure the users are

willing to accept and embrace the

change. However, we will

implement cut-off dates for

change requests and implement

subsequent changes, as necessary,

in subsequent Sprints. In order to

ensure users accept and embrace

changes further, we will highlight

the strengths of the new system

and promote the advantages of

adopting the new system.

Additionally, we will conduct

User Training to ensure Capstone

Bank is more susceptible to

accepting change.

2. User’s Lack of

Commitment

If user’s do not

commit to the project

and participate

actively, the project’s

details, business and

software requirements,

functionality, and

overall design could

be “left up to

interpretation”, to

which would result in

building the wrong

product or a product

that was subpar to the

original business

8 10 If the user’s do not commit or

actively participate in the

requirements elicitation

process, during the system

design process, and during the

system development process,

the project team could assume

the client’s needs and interpret

them incorrectly, to which

would result in a system that

does not meet the user’s

expectations and business

needs. Therefore, if we build a

system that does not meet the

client’s desires and business

Avoid To ensure User Commitment, the

project team proposes stakeholder

involvement through continuous

communication, such as email

correspondence, weekly updates,

and conferences. By engaging in

frequent contact and

communication, we anticipate

that communication will alleviate

anxieties and increase users’

commitment to the project.


needs needs, our efforts would be a

waste time, resources, and

money, resulting in customer

dissatisfaction and a product

that is unusable. Ultimately, we

could lose money by rebuilding

the software system and

assuming all the new costs in

attempts to preserve vendor-

client relations and our

reputation as a software

development organization

3. Lack of User

Cooperation

Similar to Lack of

User’s Commitment,

Lack of User

Cooperation could

lead to misinterpreting

the requirements, lack

of disclosed

requirements, and

ultimately end in

project abandonment

8 10 Lack of User Cooperation will

lead to project failure because

the software designers could

misinterpret the requirements,

functionality, and business

needs of the system, resulting

in loss of business, time,

money, and reputation as a

reputable software engineering

firm. Furthermore, Lack of

User Cooperation could result

in a product that presents

security hazards to Capstone

Bank, to which would endanger

the financial institution,

customers, and our software

engineering firm as law suits

ensue.

Avoid In conjunction with frequent

communication, we will include

the client (end User) in decision

making, such as eliciting

requirements through

brainstorming sessions. The

brainstorming sessions will be

informal, will include catered

meals, and will include door

prizes. By catering meals and

offering door prizes, we

anticipate that hospitality will

triumph and gain cooperation

from the client. Furthermore, we

will encourage, advocate User

Cooperation by promoting, and

rewarding creativity through

monthly prize giveaways that will

include free lunches/dinners for

two, free movie vouchers, and

gift certificates. The monthly

prizes will consist of the top two

contributors drawn from a list of

all the contributors, in raffle

format.

4. Unclear System

Requirements If we do not elicit

the requirements

8 9 Unclear System Requirements

could lead to building an

Avoid In order to gain full awareness of

the System Requirements, we


properly, we could

develop wrong

functionalities,

wrong user

interfaces, and

wrong business

applicable

systems. It is

essential that all

requirements are

concise, clear, and

detailed so that the

correct system

materializes.

ineffective product, a product

that is susceptible to security

breaches, a product that does

not meet the client’s business

needs, and/or a product that

does not work. Resultantly, we

would consume the loss of

time, spent resources, and

misallocated funds, to which

would result in unfavorable

consequences, such as

bankruptcy, loss of employees,

and loss of reputation and

business relations.

will conduct brainstorming

sessions with the client/users. In

addition to brainstorming

sessions, we will conduct formal

one-on-one interviews. The

formal interviews will follow the

best practices of eliciting

requirements by adhering to a

predetermined list of questions.

Lastly, we will conduct

observational interviews to

witness user’s interaction with the

current system. From

observational interviews, we can

witness day-to-day observations

and apply expert knowledge to

formulating the requirements and

verifying the requirements from

previous elicitation techniques.

5. Incessantly

changing

requirements

and project

scope

Users’ needs may

change or their

perception of the

system may change

over the course of the

project, to which could

result in an endless

stream and influx of

requirement change

requests

9 9 If the user is unsure of their

desired outcome, they could

issue change requests

repeatedly and incessantly, to

which would hinder the

progress of the project and

change the scope of the project

if the Product Owner and

Project Team accept too many

changes. Change in scope

would ultimately affect the

project’s schedule and budget,

resulting in project failure, an

over budget project, or delayed

project.

Accept Although we will advocate

creativity and promote changes to

the system, in order to ensure the

project remains within budget and

on track with the predetermined

schedule, we will implement

Change Requirements’ deadlines.

Once the deadline comes to

fruition, we will table the

subsequent change requests for

review and possible

implementation later, such as in

subsequent sprints, through

software upgrades, or system

patch.

6. Incorrect

System

Requirements

If the client is unsure

of what they want,

they could present

requirements that

would not meet the

9 10 Incorrect System Requirements

would have a major impact

upon the project because the

software product would not

meet or satisfy the business

Avoid In order to ensure the client is

aware of their actual needs, we

will conduct brainstorming

requirements elicitation sessions,

as often as necessary and confirm


needs of Capstone

Bank, to which would

result in a system that

does not coincide with

the original

perceptions or

business needs.

needs, functionality, and end

user requirements, to which

would result in loss time,

resources, money, and business

relations. Additionally,

erroneous requirements could

lead to development of a

product that would be

susceptible to security issues,

which would lead to further

loss of money and reputation as

law suits begin to materialize.

our interpretations with the client

after designing each sprints

objective. By incorporating

brainstorming sessions, we will

be able to guide the user through

expertise and knowledge. By

guiding the user, the user will be

more apt to arriving at a

formidable conclusion of their

needs, to which will aid in

exposing the correct system

requirements.

7. Misidentified

Requirements

If the requirements do

not experience

accurate identification,

functionality could

suffer, user interfaces

could become

cumbersome, and

exclusion of

requirements could

transpire.

9 10 Inaccurate identification of

requirements would have a

huge, negative impact upon the

software product. Essentially, if

the requirements do not receive

accurate identification, we

could, yet again, build a

product that did not meet

business needs, functionality

requirements, and satisfy user

expectations, to which would

result in loss of time, money,

resources, and reputation.

Unequivocally, we would either

consume the losses or charge

Capstone Bank, either way; one

or both businesses would suffer

the consequences and may not

recover.

Avoid In order to identify the

requirements accurately, we will

incorporate and implement

business analysts to gather

requirements and technical

writers to scribe and generate a

formal Software Requirements

Specification (SRS) Document.

By incorporating business

analysts, technical writers, and

SRS creation, we will be able to

not only document the

requirements but also expose any

inconsistencies that require

clarification. Furthermore, in

addition to a formal SRS, the

technical writers will collaborate

with the software designers to

create formal Unified Modeling

Language (UML) Use Case

Diagrams, Activity Diagrams,

and Sequence Diagrams to ensure

all the requirements receive

accurate identification.

8. Redundant

Requirements

Redundant

requirements emerge

when the clients do

6 8 If Redundant Requirements

emerge throughout the

software’s life cycle, survives

Avoid In addition the SRS and Unified

Modeling Language Diagrams,

we will utilize a Requirements


not express themselves

clearly and the

software requirement

elicitation process is

not concise,

appropriate, or well

planned.

analysis, and experiences

implementation into the design,

we would develop a system that

consumes too many resources,

performs poorly, and may not

function according to the

business requirements.

Therefore, Redundant

Requirements would cost time,

money, and resources as a

cumbersome software product

emerge. Furthermore, building

a system with redundant

requirements could lead to

missing essential requirements

that relate to functionality,

operability, maintainability,

usability, and security.

Traceability Matrix to ensure all

the requirements are in place and

to minimize the chance for

redundant requirements.

9. High Level

Technical

Complexity

If the project requires

high-level technical

complexities, we may

succumb to

complications if the

required technologies

are too advanced or

technical

3 8 If the project requires high-

level technical complexity, and

we are unable to perform

accordingly, the software

project could fail, the schedule

could experience substantial

delays as we attempt to obtain

the necessary knowledge or

subject matter experts, and the

project could experience budget

increases, to which would be a

detriment to the project’s

schedule, budget, and abilities

to culminate. Therefore, High

Level Complexity could have a

major, negative impact on the

project, resulting in a

potentially ineffective product

that would not function as

required, meet the customer’s

needs and business

requirements, and potentially

Avoid To ensure the project’s

requirements are not too

complex, we will contract subject

matter experts as necessary,

provide and advocate ongoing

training to our software

development team, and ensure

that all employees have all the

proper certifications.

Furthermore, we will collaborate

as a team effort to overcome any

potential complexities that may

arise.


experience project

abandonment.

10. Ineffective

Communication

Ineffective

Communications

revolves around not

communicating the

proper information or

not communicating to

the proper authorities.

8 8 If the project endures

Ineffective Communications,

the project could miss

important information that is

necessary for the progression of

the project. Additionally, if

communication does not follow

the proper protocols and

established conventions, the

project could suffer from

implementing wrong

requirements, miss important

milestones, fail to implement

approved changes, and fail to

meet goals and objectives.

Principally, the Project

necessitates good

communication to preserve the

schedule, budget, and

functionality of the system or

else the project is ripe for

failure.

Avoid To ensure effective

communication, we will utilize

Configuration Management and

Communication Plans to

communicate the necessary

information between all

interested parties.

Communication plans will

include a Stakeholder

Communication Plan and a

Project Communication Plan.

Essentially, the Communication

Plans will delineate the necessary

and required communicable

information, communication

format, and frequency of

communication.

11. Inadequate

Estimation of

Resources

Inadequate Estimation

of Resources revolves

around over/under

allocation of Project

Team resources for the

project

6 8 If the Project Team has too

many or too few resources, the

project schedule could suffer.

For example, if the project has

too many resources, the project

could go over budget; resources

may become uninterested,

and/or cause a conflict of

interest during the project’s life

cycle. Furthermore, if an over

allocated project has too many

resources, the project team may

feel too confident and miss

major milestones, processes,

and requirements.

Avoid To ensure the project has

adequate resources and receives

the proper estimation, we will

utilize industry-recognized

estimation techniques, such as

work breakdown

structures/schedules (WBS),

Program Evaluation Review

Technique (PERT), Delphi

Methods, Analogous Estimation,

and Metrics when applicable.

Specifically, for Project Capstone

Mobile Banking, we will utilize

PERT and WBS conventions to

establish a proper schedule that


Alternatively, if the project has

too few resources, the project

could run the risk of failing to

meet milestones, delay

deliverables, miss

requirements, forego or

diminish important processes,

and produce faulty products in

a hurried state. Additionally, if

the project has too few

resources, the project risks

employee frustration, over-

worked employees, and fatigue

that could result in project

abandonment, employee

dissatisfaction, and potential

vacancies, to which would have

a negative effect on the overall

project.

will aid in determining the

amount of resources necessary for

project completion.


IX. References

Csaba, P. (2013, January 10). SCRUM: The story of an agile team. Retrieved from Envato Pty

Ltd. website: http://code.tutsplus.com/tutorials/scrum-the-story-of-an-agile-team--net-

29025

Famuyide, S. (2013, July 18). Interviews: Requirements Elicitation Technique. Retrieved from

Business Analyst Learnings website: http://businessanalystlearnings.com/ba-

techniques/2013/7/18/interviews-requirements-elicitation-technique

FAQs for QSFP+. (2014). Retrieved from Siemon Interconnect Solutions website:

http://www.siemon.com/sis/application-guide/2010-08-20-FAQs-for-QSFP-plus.asp

Features of Scrum. (2014). Retrieved from The Braintrust Consulting Group website:

http://braintrustgroup.com/scrum/features-of-scrum/

HP Moonshot System. (2014, February). Retrieved from Hewlett-Packard website:

http://h20195. www2.hp.com/V2/GetDocument.aspx?docname=4AA4-

6076ENW&cc=us&lc=en

Lead, Lags and Floats. (2014). Retrieved from Tutorialspoint website: http://www.tutorials

point.com/management_concepts/leads_lags_floats.htm

Lohrey, J. (2011, December 29). What is a gigabit sfp? Retrieved from Demand Media website:

http://www.ehow.com/info_12214766_gigabit-sfp.html

PMI. (2009). Practice standard for project risk management (p. 9). Newtown Square, PA: PMI

Publications.


Release Burndown Chart. Topics in Scrum (2014). Retrieved from Mountain Goat Software

website: http://www.mountaingoatsoftware.com/agile/scrum/release-burndown

Rouse, M. (2014). Agile Manifesto. Retrieved from Tech Target website: http://searchcio.

techtarget.com/definition/Agile-Manifesto

Rouse, M. (2014). Scrum. Retrieved from Tech Target website: http://searchsoftware

quality.techtarget.com/definition/Scrum

Samsung Galaxy S4 (Verizon) Electric Blue. (n.d.). Retrieved from Samsung website:

http://www.samsung.com/us/mobile/cell-phones/SCH-I545ZBAVZW

Scrum Sprint. (2013, October 10). Retrieved from Scrum Methodology website: http://scrum

methodology.com/scrum-sprint/

Software Development Methodologies. (2014). Retrieved from the Association of Modern

Technologies Professionals website: http://www.itinfo.am/eng/software-development-

methodologies/

Scrum Methodology. (2014). Retrieved from Scrum Methodology website: http://scrum

methodology.com/

Wiegers, K., & Beatty, J. (2013). Software Requirements (3rd ed.) (p. 48). Redmond, WA:

Microsoft Press

What is a project risk? (n.d.). Retrieved from Project Future 2 website:

http://www.projectfuture.net/uk/projectfuture-software/frequently-asked-questions/what-

is-a-projectrisk


Yegi, S. (2014). Risk and Issue Management in the Scrum Process. Retrieved from Scrum

Alliance website: https://www.scrumalliance.org/community/articles/2014/april/risk-and-

issue-management-in-scrum-process

jim richardson software engineering capstone 1 ip phase 5

Documents

development phase

requirements phase

software engineering

design phase

project outline phase

abbasindividual project

project schedule phase

capstone banks services