8
Have a Project  What are the next steps ?  Initiate the project  Consistent processes, methodology  Everyone knows what to expect and what is expected from them  Frameworks  Templates

9

10
Software Development Methodology  Water Fall  Agile  Scrum

11
Organization Structure

12

13

14
Requirements  Business Analyst  Gathering business requirements may appear to be a simple process  Simply ask the user what they want  One of the most difficult and critical tasks  The quality and realism of the requirements gathering process is a primary ‘make or break‘  If the requirements lack adequate definition, the project will fail to achieve its goals

15
Challenges  Communications gaps that exist between the business-savvy sponsor and the technical-minded  Executive instructs a subordinate to have IT develop a solution  IT enters the requirements gathering process with a preconceived (or pre-designed) solution and meets with the stakeholder out of courtesy  IT agrees with the sponsor on the definition of the requirements, and then begins working on the pre-designed solution, disregarding the input from the sponsor  The results of this situation are as predictable as they are historical. The sponsors do not receive a product that meets their needs and scope creep and poor design consume the project  For all practical purposes, the project fails

16
Project Definition  Objectives  RBC will issue MC by end of 2009  RBC will include rewards features for WJ by end of 2009  Scope Definition  What the project will deliver  User requirements  Product specs, if building a product

17
Scope Definition Business Requirements Requirement Details LOCC001 Add a New blind to the account services page in MYCA to include a “Line Of Credit Management” link LOCC002 MYCA needs to evaluate eligible accounts to perform Line Reduction functions LOCC003 Add new links to the Line of Credit Reallocation Confirmation page in MYCA LOCC004 Add the Line of Credit Reduction functionality to MYCA LOCC005 MYCA to capture line Reduction application parameters LOCC006 MYCA will accommodate default/min/max values for the line Reduction amount LOCC007 MYCA needs to display Verification page for Line Reduction LOCC008 MYCA needs to forward Line Reduction requests to the Composite service to process a Line Reduction of card account LOCC009 MYCA needs to display Confirmation page for Line Reduction LOCC010 MYCA needs to display Error Messages after negative validations for the line reduction field are performed. LOCC011 LOCC011 –De Scope-BAU only needs to be included as a test condition LOCC012 SSP will revise the Minimum Line of Credit field

18
Business Requirements REQUIREMENT ID: LOCC003 DEFINITION: Add new links to the Line of Credit Reallocation Confirmation page in MYCA TYPE: Functional AS IS: Does not exist TO BE: MYCA needs to Add the following links to the Line of Credit Reallocation Confirmation page: 1.Balance Transfer. This link promotes card member to Balance Transfer transaction page. 2.Line of Credit Increase. Link to the line of credit input page. (Via additional authentication). NET CHANGE: New links in Line of Credit Reallocation Confirmation page in MYCA BENEFITS: - Increase LOC transactions by driving LOC Reallocation - Improve Card Member Navigation CONSTRAINTS: None identified at this time IMPORTANCE: High STAKEHOLDER: MYCA SPONSOR: AXPi risk METHOD OF CHANGE: Systematic

19

20

21
Relative Cost to fix problems

22

23

24
Quality Assurance  Responsible for guaranteeing a level of quality for the end client  Help the software development team to identify problems early in the process  Often known as "testers“  More than just testing  Contributing to the quality of the final product

25
Quality Assurance (QA) Role  Focused on creating a quality deliverable  Responsibility of the QA role to make sure that the software development process doesn't sacrifice quality in the name of completed objectives

26
Quality Assurance (QA) Role  Works with the Functional Analyst (FA) and the Solutions Architect (SA) to convert the requirements and design documents into a set of testing cases and scripts  Used to verify that the system meets the client needs.  This collection of test cases and scripts are collectively referred to as a test plan  The test plan document itself is often simple providing an overview of each of the test cases  The testing cases and scripts are also used to validate that there are no unexplained errors in the system.

28
Test Case  A general-purpose statement that maps to one or more requirements and design points  It is the overall item being tested  It may be a specific usability feature  Technical feature that was supposed to be implemented as a part of the project  Test scripts fit into the test cases by validating that case  Test scripts are :  Step-by-step instructions on what to do  What to look for  What should happen  While the test cases can be created with nearly no input from the architecture or design, the test scripts are specific to how the problem was solved by the software development team and therefore they require an understanding of not only the requirements, but also the architecture, design, and detailed design.

29
Roles  Assist in creation of Requirements  SMART  Creates test cases and scripts.  Executes or supervises the execution of those test cases and scripts.  Facilitates or performs random testing of all components to ensure that there's not a random bug haunting the system

30
Risk Based Testing  Crashing the schedule  In theory, there is an infinite number of possible tests  RBT is a type of software testing that prioritizes the features and functions to be tested based on;  Priority/importance  Likelihood or impact of failure