SWE 481 Capstone Mobile Banking Software
•Als PPTX, PDF herunterladen•
1 gefällt mir•2,098 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (8)
Ähnlich wie SWE 481 Capstone Mobile Banking Software
Ähnlich wie SWE 481 Capstone Mobile Banking Software (20)
SWE 481 Capstone Mobile Banking Software
- 1. Software Engineering Capstone 1 SWE 481 Capstone Mobile Banking Software Development Plan Group 4 Created and Edited by: Jim Richardson Approved by: Robert Perry & Alex Wiebold December 22, 2014 Page 1
- 2. Project Outline Capstone Bank decides to modernize their financial institution to appear more modern and competitive. Capstone Bank explores options. Capstone Bank determines they need to add a new service. Capstone Bank decides upon the new service… Mobile Banking! Page 2
- 3. Project Outline: Mobile Banking Capstone Bank’s new service: Capstone Bank Mobile Banking. Capstone Mobile Banking will include the following major features: Login View Balances Transfer Funds Make Photographed Deposits Link Accounts View Financial Statements • Major issues to consider Page 3
- 4. Development Methodology Scrum What is Scrum? Sprints Two to four week iterations Major Roles of Scrum Product Owner Scrum Master Scrum Project Team How does Scrum work? Major Activities Sprints Sprint planning meetings Daily Scrum meetings Sprint Review meetings Sprint Retrospective meetings Page 4(“Scrum Methodology”, 2014; Rouse, 2014; “Scrum Methodology”, n.d.; “What is Scrum”, n.d.)
- 5. Scrum Software Development Model (“Why should we”, 2014) Page 5
- 6. Scrum Software Development Model (“Why should we”, 2014; “Features of Scrum”, 2014; Uhlig, n.d.) Why should we choose Scrum? Provides a working model earlier than traditional Software Development Models Frequent Requirement Changes is less impactful Self- Organization and employee empowerment Open and frequent Communication Opportunities for clear definitions Promotes Creativity, Collaboration, and Collaboration Improved processes Capitalizes upon feedback Iterative and Incremental working models Backlogs work items for better realization of work schedules and required work Page 6
- 7. Requirements Requirements Elicitation How will we elicit the requirements? Stakeholder Meetings Informal Interviews Requirements Surveys What do we do with the elicited requirements? Brainstorm Storyboard Backlog Begin the processes of designing and developing the product Page 7
- 8. Requirements Approved Requirements Functional Requirements Login View Balances Link Accounts Photograph Deposits Transfer Funds View Financial Statements Non-Functional Requirements Secure Connection and Encrypted Data Transfers – 128-bit encryption and decryption on the fly Prevention of Simultaneous Logins – no more than one login instance at a time Application Loading – 7 second load time Refresh Rate – automatically refreshes account balances every 60 seconds System Lock Out – locks the system after 5 failed attempts to authenticate System Time Out - logs the user out after 10 minutes of inactivity Page 8
- 10. Design: UML Use Case Diagram Page 10
- 11. Design: UML Use Case Diagram Exploded View Page 11
- 12. Design: UML Class Diagram Page 12
- 13. Design: User Interface Prototype Page 13
- 14. Development and Testing Development Milestone identification and tracking using Computer Aided Software Engineering (CASE) Tools: Microsoft Project Milestone identification Finished product becomes a milestone Daily Scrum Meetings will produce mini-milestones Tracking Monthly Stakeholder Meetings will disclose the milestones Work Breakdown Schedule (WBS) Gantt Chart Network Diagram Testing Testing will occur within each sprint Testing conventions: Black Box Testing – Unit Testing Black Box Testing – Integrating Testing White Box Testing – Usability Testing White Boxy Testing – Automated Regression Testing Black Box Testing – System Testing Page 14(Scrumstudy, n.d.)
- 15. Development and Testing Page 15(Scrumstudy, n.d.)
- 16. Project Schedule CASE Tool: Microsoft Project Provides better organization Lists the project schedule Lists the milestones Lists detailed tasks for each milestone Provides a view of the Critical Path Project Schedule Best case estimates Incorporated “Float Time” Tracking Story points will be moved to the Completed Work section on the project storyboard MS Project will be updated with a color-coded scheme and the Gantt Chart will illustrate percent complete Page 16(“Leads, Lags and Floats”, 2014)
- 17. Project Schedule Page 17(Csaba, 2013; “Release Burndown Chart:, 2014)
- 18. Risk Analysis What is a project risk? An event that could potentially hinder or negatively affect the project in such a manner that the project fails to achieve its objectives What do we do about project risks so that the project is successful? Project Risk Management Plan Identify Risks Risk Identification Matrix Evaluate Risks Impact and Probability Scale Develop Risk Response Plan Avoid, Mitigate, Accept Review Project Risks Frequently Page 18(“What is a project risk”, n.d.; PMI, 2009, p.4; Yegi, 2014)
- 21. 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 Features of Scrum. (2014). Retrieved from The Braintrust Consulting Group website: http://braintrustgroup.com/scrum/features-of-scrum/ Lead, Lags and Floats. (2014). Retrieved from Tutorialspoint website: http://www.tutorials point.com/management_concepts/leads_lags_floats.htm 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 Scrum Methodology. (2014). Retrieved from Scrum Methodology website: http://scrum methodology.com/ Scrumstudy.com. (n.d.). Scrum Phases and Processes. Retrieved from Scrumstudy.com: http://www.scrumstudy.com/scrum-phases-processes.asp Uhlig, D. K. (n.d.). Advantages and Disadvantages of the Scrum Project Management Methodology. Retrieved from Chron.com: http://smallbusiness.chron.com/advantages-disadvantages-scrum-project- management-methodology-36099.html 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 Why should we choose SCRUM for our project. (c. 2014). Retrieved from http://sandervanpeer.wordpress.com/2012/01/05/why-should-we-choose-scrum-for-our-projects/ on November 24th, 2014. 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 Page 21
Hinweis der Redaktion
- Generated and edited by Jim Richardson. Approved by Robert Perry and Alex Wiebold
- 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.
- The project to be developed is a mobile banking application. The application is to be developed for the Android platform. The mobile banking application is to be developed for the company Capstone Bank. The mobile application will be called Capstone Mobile Banking. The mobile banking application will allow Capstone Bank’s customers to do many tasks that the customer would normally have to go into the bank to do, right from their mobile device. The new application will be created to interface to the banks existing system. The mobile application will interface with the existing Capstone online banking website. It will provide basic banking features such as viewing balances, transferring funds, linking accounts, and viewing statements. In addition, this software will provide a ‘photo deposit’ system allowing users to deposit checks remotely. 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. Below you will find a list of issues to consider in the development of the application. 1. Not all requirements are known; requirements may change or be added to. 2. There are standards applicable to the banking industry and the handling of customer data. 3. The new application may cause issues with the legacy system. 4. Inconsistent estimates may throw budget off track. 5. Team members may not fully commit to the software development lifecycle. 6. The project may accrue costs above the previously established budget. 7. Incessant change requests 8. Photographed deposit functionalities will require substantial effort to incorporate into the legacy system 9. Verification that our data connections are secure and ensuring the data itself is secure on the device
- The development model that has been selected for the Capstone Mobile Banking application project is the Scrum model. 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). The scrum model consists of three roles: the product owner, the Scrum master and the team members. The product owner is responsible for portraying the product to the development team. The product owner has the most authority within the project. This also means that if the project goes off track or fails, it is the product owner who must take the heat (“Scrum Methodology”, n.d.). The product owner creates a document called the product backlog. The product backlog contains the list of every requirement for the whole project. The Scrum master is essentially a facilitator for the product owner and the team members. The Scrum master does not have any real authority over the team. The Scrum master is mainly used to remove any obstacles the team members may run into during the development. The Scrum master, by removing the obstacles identified by the team members, helps keep the team productive and on track. The scrum master also cannot agree to any additional work for the team. The team members are those who are actually completing the work. The team members typically consist of a mixture of engineers, programmers, architects, analysts, quality assurance experts, testers and user interface designers (“Scrum Methodology”, n.d.). There are some events/activities that are part of the Scrum methodology. These activities are the Sprint Planning Meeting, Daily Scrum meeting, Sprint Review Meeting and the Sprint Retrospective meeting (“What is Scrum”, n.d.). The spring planning meeting is a meeting which is held prior to the start of any new sprint or iteration of the product. The meeting is held with the product owner and the team members. During the meeting the two involved parties are able to negotiate which requirements from the product backlog will be selected for the sprint being planned. After the meeting is completed, the sprint product backlog is created which contains all the requirements identified for the specific sprint as there are typically more than one sprint for a project. The sprints typically last two to four weeks. Every morning of the spring the daily meetings occur. The daily meetings are used to allow team members to discuss their progress and anything that may hinder their progress for the day. The daily meetings ensure that each team member is up-to-date on everyone’s progress which helps promote the self-organizing part of the Scrum model. Upon completion of the sprint, the sprint review meeting occurs. The sprint review meeting consists of the team members displaying the results of the sprint to the product owner. After the sprint review meeting is finished, there is a sprint retrospective meeting. The sprint retrospective meeting enables the team members and the product owner to identify any changes that need to be made for the next sprint. After the retrospective meeting, a new product backlog can be created and the cycle can start again. For a graphical representation of the scrum methodology, see the next slide.
- The Scrum methodology has been chosen as it provides a working model much earlier than other methodologies. It also enables changes to be made to requirements with less impact on cost and other resources. Furthermore, the Scum methodology enables a self-organization that allows the team members to voice their concerns to be heard. The Scrum methodology suits this project well because not every requirement is known. Requirements for the project may change as well which can be addressed by utilizing the Scrum methodology. Scrum splits the work into sprints which will each result in a shippable product (Uhlig, n.d.). It will fit this project perfectly for a couple of reasons. First, this project will consist of multiple ‘functions’ that can be standalone features. In essence, when we finish one sprint, we’ve added a new feature to our application. We could honestly ship the application after designing the ‘view balance’ feature and simply patch it to add more. Another reason Scrum is great for this project is that we’ll likely be dealing with considerable change regarding the photo deposit requirement. It’s likely we’ll run into hang-ups or uncover unforeseen risks later on in the software lifecycle. Scrum will allow us to adjust our scope accordingly. Additionally, the Scrum Methodology is suitable for the CMBA development project for the following justifications: 1. Scrum provides better opportunities 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 2. Scrum is a cultural improvement in that Scrum advocates and promotes creativity, collaboration, and communication among the project team, which increases productivity and promotes quality 3. Scrum eliminates the feel of a dictatorship and empowers the project team with control of the project, which increases job satisfaction 4. Scrum provides the project team with opportunities to improve the processes and product through lessons learned 5. Scrum’s focus of open and frequent communication provides the project team with better opportunities to develop exactly what Capstone Bank needs, resulting in a product that will suit Capstone Bank’s business requirements 6. Scrum capitalizes upon Capstone Bank’s feedback to ensure the product is within specifications 7. 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 8. Scrum’s backlog of work items facilitates the project team in realizing the required work and work schedule (“Features of Scrum”, 2014)
- Elicitation Requirement elicitation will be completed using multiple techniques. First, we’ll be holding stakeholder meetings three times a week to review the obvious requirements and brainstorm additional requirements with the stakeholders. Secondly, we’ll be holding interviews with many of the stakeholders to ask probing questions: attempting to elicit hidden or masked requirements. Lastly, we’ll be distributing surveys to bank customers to gather the perspective of the end users. Upon completing the stakeholder meeting, the next activity will be to conduct informal interviews with potential end users. The interviews with potential end users will help the elicitation team see what end users may expect to see from a mobile banking application. Furthermore, it will also enable the elicitation team to verify some of the requirements set forth by the stakeholders and their priority within the development. After the informal interviews are conducted, brainstorming activities can occur. With the requirements specified by the stakeholders and the information obtained from potential end users the requirements elicitation team can begin to brainstorm on the requirements for the overall project. The brainstorming session will help aid in the necessary design and architecture requirements and further uncover unmentioned requirements. During the brainstorming sessions, we will create storyboards, we will backlog the stories, then from the backlogs we will begin the designing and developing processes
- Functional 001 Login 1.1- The system shall provide access to customers who provide valid login credentials. Method of elicitation: Stakeholder meeting Rationale: Access should only be provided to authorized users. Measurement Criteria: Audit Success/Failure Priority: HIGH 002 View Balances1.2 - The system shall display current balances for all accounts linked. Method of elicitation: User Survey / Stakeholder meeting Rationale: Users have expressed that viewing account balances is primarily what they would use this system for. Measurement Criteria: Accurate balances are displayed in the system for each account. Priority: HIGH 003 - Photograph Deposits 1.3 - The system shall allow for photographic deposits to all linked accounts. Method of elicitation: User Surveys Rationale: Users have requested the ability to remotely make deposits to their account. Measurement Criteria: Deposit photos are uploaded successfully and placed in a queue for review by bank employees. Priority: MODERATE 004 Link Accounts 1.4 - The system shall allow for linking multiple banking accounts to one login. Method of elicitation: Stakeholder meeting Rationale: Allows customers to manage all accounts from one login. Measurement Criteria: Accounts successfully linked in system. Priority: MODERATE 005 Transfer Funds 1.5 - The system shall allow for the transfer of funds between linked accounts. Method of elicitation: Interviews Rationale: Stakeholders have expressed their desire to easily transfer funds. Measurement Criteria: Accurate and immediate transfer of funds: funds are appropriately added to one account and removed from another. Priority: HIGH 006 View Financial Statements 1.6 - The system shall allow for viewing financial statements. Method of elicitation: Interviews Rationale: Stakeholders have expressed a desire to view their financial statements. Measurement Criteria: Statements are viewable within the application. Priority: MODERATE Non-functional Requirements 007 Secure Connection and Encrypted Data Transfers 2.1 - The system shall include Secure Connection and Encrypted Data Transfers Method of elicitation: Stakeholder meeting Rationale: Financial information is very sensitive and as a result needs to be protected from those who would attempt to steal it. Measurement Criteria: All data sent to or from the application is 128-bit encrypted and is decrypted by the application on-the-fly. Priority: HIGH 008 Prevention of Simultaneous Logins 2.2 The system shall Prevent of Simultaneous Logins. Method of elicitation: Stakeholder meeting Rational: To ensure the user’s account credentials are not in use across multiple locations at the same time Priority: HIGH 009 Application Loading 2.3 - The system shall ensure the application loads within 7 seconds of execution on a newly formatted device. Method of elicitation: User Surveys Rationale: In a fast paced world, fast application load times have become an expectation. Measurement Criteria: Application loads within 7 seconds on a fresh device. Priority: MODERATE 010 Refresh Rate 2.4 - The system shall be able to display refreshed information within 5 seconds during peak traffic. Method of elicitation: Interviews Rationale: Stakeholders expressed their concern that the current website doesn’t refresh automatically. Measurement Criteria: Account balances are updated every 60 seconds. Priority: MODERATE 011 System Lock Out 2.5 - The system shall lock user accounts that fail authentication 5 times in a row. Method of elicitation: Stakeholder meeting Rationale: Locking out accounts helps to prevent brute force attacks. Measurement Criteria: Accounts successfully lock after 5 audit failures. Priority: HIGH 012 System Time Out 2.6 - The system shall log the user out after 10 minutes of inactivity. Method of elicitation: Stakeholder meeting Rationale: Devices left unattended with users still logged in can become a security risk. Measurement Criteria: Application automatically logged user out after 10 minutes of inactivity. Priority: MEDIUM
- This is a graphical representation of the components that the Capstone Mobile Banking application will use and the flow of transmission. The user, using an android mobile device, connects to the internet and which passes through a firewall to the web server. Unknowingly, the user tunnels through the web server and then passes through another firewall. From there, the connection then passes through a switch and the user’s login information is verified within the application server. If the application server confirms the users identity it will then pull the necessary data from the database server and return it to the mobile device user interface.
- This is a graphical representation the use cases that the system will use to perform operations initiated by the user
- 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: The user clicks on the CMBA The CMBA and Capstone Bank’s server systems establish a secure connection The user enters their corresponding Capstone Bank login credentials The user submits the login credentials Capstone Bank confirms the login credentials Capstone Bank locates the corresponding account information The CMBA presents a menu screen The user selects the option to make a photographed deposit The CMBA responds by enabling the mobile smart device’s camera The user captures the appropriate images The CMBA prompts the user to transmit the images The user elects to transmit the images The CMBA transmits the images to Capstone Bank Capstone Bank’s server system receives the images Capstone Bank’s server systems verify authenticity of the images Capstone Bank’s server systems locates the appropriate account Capstone Bank’s server systems retrieves the corresponding account Capstone Bank’s server systems performs the deposit Capstone Bank’s server system updates the account to reflect the deposit Capstone Bank’s server system issues confirmation The CMBA receives confirmation The CMBA displays the confirmation and updated account balance reflecting the deposit Alternate Flow: User clicks on mobile banking application A secured session fails to establish User enters invalid login credentials Database is unable to confirm or verify the login credentials Database fails to retrieve customers’ account Menu screen does not display User submits an unacceptable photograph(s) Check is not properly endorsed 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.
- This Unified Modeling Language (UML) Class Diagram is part of the design process we will use to design the Capstone Mobile Banking Application. As you can see from this UML Class Diagram, we have the major classes listed: Customer, Account, Transfer Funds, Link Account, Photograph Deposits Within each UML Class Diagram, we have the variables , getters, and setters listed. Using these variables, as the foundation, we will be able to develop the system.
- Here is our initial User Interface (UI) design prototype. As you can see, this UI design is simplistic, consistent, and provides all the major required features elicited and listed
- Development Coding will done using the SCRUM methodology during the implementation phase. During this phase, we’ll be executing the tasks necessary to fulfill our sprint. This includes development of the code. There are three methods we’ll be utilizing to drive development throughout this phase: identification and tracking of our milestones, daily scrum meetings, and monthly stakeholder meetings. Milestones are easy to identify in a Scrum methodology, as one could easily identify the end of a sprint as a milestone of sorts. At the end of a sprint, we’ll have a finished product, which in itself is a milestone. Tracking of these milestones will be done using CASE tools. Our daily scrums will allow us to create mini-milestones for the team. These will mark the completion of a requirement involved with that particular sprint. It’s not uncommon to work on a couple requirements in the same sprint, though we shouldn’t go too crazy. It also serves as a means of “grooming” our Product Backlog as we go (Scrumstudy.com, n.d.). Lastly, the monthly stakeholder meetings will give us a chance to show the stakeholders the milestone markers that we’ve met, and instill confidence in the stakeholders that the project is meeting our predetermined expectations and scope creep is not a concern. As mentioned, documentation will be necessary in order to keep track of our progress and clearly label our milestones. This will be accomplished using CASE tools. Microsoft Project for example, will be used to develop a WBS and Gantt chart. These documents will be used to not only track our progress, but also assist with preventing over-allocation of resources. In addition, it will help us to sculpt our ideal schedule and provide our realistic schedule to the stakeholders. Approvals will also be necessary for many different aspects of the development phase. Our team has agreed that comments in the code are not an option, but a requirement. The programming lead will need to approve all code submitted to ensure it follows our predetermined comment standards. Approval will also be needed from the Scrum Master before a new function can be considered ‘ready for testing.’ Testing will be accomplished during the “Review and Retrospect” phase of the Scrum methodology. It’s at this phase that we being reviewing and validating the completed sprint. We review what went wrong or right, and hopefully learn from that experience. We can then apply that knowledge to future sprints. However, in addition to reviewing the process, we’ll need to start reviewing the code and testing the new functionalities. Testing 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 the incorporated Scrum Methodology focuses on compiling with working code and delivering basic functionality, the project will require a test plan that corresponds with their sprint parameters. Accordingly, the 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, the project team will add Black Box System Testing to the test plan. By incorporating Black Box System Testing near the end of the project’s lifecycle, the project team will be able to ensure the system functions as completely integrated units.
- This sample test case and test script will describe how we will test the requirements of the Capstone Mobile Banking Application Each test case and test script will have a specific agenda and will be tailored to suit the corresponding requirement. This example is for the Login functional feature The Test case for the login feature is as follows: 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): 001: Login 1.1 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. This is the how the Test Script will test the Login feature: TC1: 001 Login 1.1 Name of the requirement to be tested and the test case name Start Time open to indicate when the test begins Stop Time open to indicate when the test concludes Tester: tester’s name Step Operator Action Expected Results Observed Results Pass/Fail Severity of Failure Operator Action: Turn on smart device. Expected Result: The phone should power up 2. Operator Action: Open Capstone Mobile Banking Application by clicking on the icon Expected Result: The icon should be visible and should initiate connection when clicked by displaying an hourglass until connection is established 3. Operator Action: Wait for access Expected Result: The webserver receives the request and verifies that the application is seeking to establish a secure session 4. Operator Action: Wait for access Expected Result: 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. Operator Action: View Results Expected Result: The login screen should be visible with prompts for login credentials 6. Operator Action: Enter login credentials Expected Result: 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. Operator Action: Submit login credentials Expected Result: The user will enter correct login credentials and submit for verification. User’s credentials should be masked, as entered, to maintain security. 8. Operator Action: Wait for results Expected Result: The webserver will receive the information and pass the credentials along to the database server for verification. 9. Operator Action: Waiting for results Expected Result: Once the database server receives the login credentials from the webserver, the database will attempt to verify authenticity. 10. Operator Action: Waiting for results Expected Result: 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.
- 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: See Next Slide 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: See Next Slide
- 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:
- “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. Examples of Capstone Mobile Banking Project Risks Users Resistance to Change – Agree to changes but implement cut-off dates. We will provide user training to ensure users are less resistance to change User’s Lack of Commitment – Engage stakeholders with frequent communication. We will keep the stakeholders informed and incessantly request their participation Lack of User Cooperation – Frequent communication through brainstorming sessions and hospitality (such as appreciation luncheons, raffles, giveaways, and other rewards) Unclear System Requirements – Communication, Communication, Communication. Formal/informal interviews, observational interviews Incessantly changing requirements and project scope – Implement Change control, Change Requirements deadlines, and/or later implementations (such as add new functionalities to subsequent sprints, system updates, system patches) Incorrect System Requirements – Frequent Communication through brainstorming sessions Misidentified Requirements – Business Analysts who dedicate themselves to eliciting and identifying requirements, technical writers to document the requirements (such as Software Requirements Specification –SRS- documents and Requirements Traceability Matrix –RTM), Unified Modeling Language Diagrams (such as Use Case, Activity Diagrams, Sequence Diagrams), and Communication to ensure exactitudes Redundant Requirements – RTM to track the requirements and verify only one instance exists High Level Technical Complexity – Contract Subject Matter Experts as necessary, but we will promote and advocate continuous learning so this is not an issue, and utilize and capitalize upon team collaboration Ineffective Communication – Configuration Management and Communication Plans Inadequate Estimation of Resources – Estimation techniques (such as Program Evaluation Review Techniques – PERT- Delphi Method, Analogous Estimation, and Metrics). We will also use Work Breakdown Structures/Schedules (WBS) and Computer Aided Software Engineering –CASE- Tools (such as Microsoft Project) 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. (See next two slides for the Risk Impact Scale, Risk Probability Scale, and Risk Identification and Response Matrix)
- Once the Project Risks have been identified, we will evaluate and measure the risk using the Impact Scale and the Probability Scale
- This is a sample of the Risk Identification and Risk Response Table