some slides adapted from:

25
1 SA Capstone Requirements and Design Week 11 SYST36367 - Winter 2013 Instructors: Jerry Kotuba & Joe Varrasso Some slides adapted from: Systems Analysis and Design in a Changing World, 6th Edition, Satzinger, Jackson, Burd, CENGAGE Learning, 2012

Upload: mikaia

Post on 17-Feb-2016

30 views

Category:

Documents


1 download

DESCRIPTION

SA Capstone Requirements and Design Week 11 SYST36367 - Winter 2013 Instructors: Jerry Kotuba & Joe Varrasso. Some slides adapted from: Systems Analysis and Design in a Changing World, 6th Edition, Satzinger , Jackson, Burd , CENGAGE Learning, 2012. Lesson Objectives. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Some slides adapted from:

1

SA Capstone Requirements and Design

Week 11

SYST36367 - Winter 2013Instructors: Jerry Kotuba & Joe Varrasso

Some slides adapted from: Systems Analysis and Design in a Changing World, 6th Edition, Satzinger, Jackson, Burd, CENGAGE Learning, 2012

Page 2: Some slides adapted from:

2

Lesson Objectives Selecting an Implementation and Testing Strategy Choosing a Configuration Management and Version

Control strategy and tools Choosing Collaboration Tools Quality Management Testing Tools (jUnit, etc.) Software Development Plan

Page 3: Some slides adapted from:

Implementation and Testing Strategy Will each member program individually? Will you use pair

programming? Who will be responsible for each module? Will you have informal code reviews? Who will strategies?

Please discuss these issues with your team since: They will impact your Project Plans The discussions can help to prevent problems in semester 6!

3

Page 4: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

OverviewImplementation, Testing and Deployment activities

[Part of QA & Testing Course –Sem 06]

• Implementation includes programming and testing activities. Deployment includes system tests, converting data, training, setting up the production environment, and deploying the solution

4

Page 5: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Implementation and Deployment Activities

5

Page 6: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Test Types

6

Page 7: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Testing Concepts

• Testing – the process of examining a component, subsystem, or system to determine its operational characteristics and whether it contains any defects

• Test case – a formal description of a starting state, one or more events to which the software must respond, and the expected response or ending state– Defined based on well understood functional and non-functional

requirements– Must test all normal and exception situations

• Test data – a set of starting states and events used to test a module, group of modules, or entire system– The data that will be used for a test case

7

Page 8: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Unit Testing

• Unit test – tests of an individual method, class, or component before it is integrated with other software

• Driver – a method or class developed for unit testing that simulates the behavior of a method that sends a message to the method being tested

• Stub – a method or class developed for unit testing that simulates the behavior of a method invoked that hasn’t yet been written

8

Page 9: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Unit TestingDriver to test createCartItem method

9

Page 10: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Unit TestingSome stub modules used by createCartItem

10

Page 11: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Integration Testing• Integration test – tests of the behavior of a group of

methods, classes, or components– Interface incompatibility—For example, one method passes a

parameter of the wrong data type to another method – Parameter values—A method is passed or returns a value that was

unexpected, such as a negative number for a price.– Run-time exceptions—A method generates an error, such as “out of

memory” or “file already in use,” due to conflicting resource needs– Unexpected state interactions—The states of two or more objects

interact to cause complex failures, as when an OnlineCart class method operates correctly for all possible Customer object states except one

11

Page 12: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Integration Testing• Integration testing of object-oriented software is very

complex because an object-oriented program consists of a set of interacting objects– Methods can be (and usually are) called by many other methods,

and the calling methods may be distributed across many classes.– Classes may inherit methods and state variables from other classes.– The specific method to be called is dynamically determined at run

time based on the number and type of message parameters.– Objects can retain internal variable values (i.e., the object state)

between calls. The response to two identical calls may be different due to state changes that result from the first call or occur between calls.

12

Page 13: Some slides adapted from:

Systems Analysis and Design in a Changing World, 6th Edition

Usability Testing• Usability test – a test to determine whether a method,

class, subsystem, or system meets user requirements• Many usability tests are required because they involve

functional and non-functional requirements• Most common type evaluates functional requirements, use

case by use case– Can be completed in each iteration as use cases are implemented– Can test ease of learning and ease of use– Can test whether results match actual requirements– Key type of feedback from users throughout project

13

Page 14: Some slides adapted from:

14

Testing Tools Test frameworks such as JUnit and NUnit can help to eliminate

lots of manual Unit Testing Some IDEs such as Visual Studio provide excellent support for

executing and documenting the results of automated tests Some IDEs such as Visual Studio also provide excellent support

for profiling and loading tests

Page 15: Some slides adapted from:

15

Software Development Plan A Software Development Plan is NOT required for this course! However, you should still:

Discuss and plan some of the key elements of a SDP that were identified in these slides

Use the tools identified in Semester 6 Developing an informal SDP in Semester 5 and using these

tools in Semester 6 will undoubtedly help you as you start your careers!

Page 16: Some slides adapted from:

Configuration Management Version Control Software is an essential tool for most software

development projects for many reasons including: It provides a convenient way to share and synchronize code changes Maintains a detailed history of all changes to the source code (Why did I

change that again?) Allows us to easily go back to a milestone (Ex. The night before the

demo when everything stops working) Provides the ultimate backup tool for source code

Video: Overview of Software Version Control

16

Page 17: Some slides adapted from:

Configuration Management Several basic issues arise regarding the use of Version Control

Software such as: What Version Control Software will you use for managing your source

code? Sheridan provides a SVN account for each team The Tools section of the Wiki Start page lists other Version Control options including:

GitHub, BitBucket and Team Foundation Server How often will team members check-in their code? (ex. Daily) Will everyone add a comment to each check-in? (usually a good idea) How will you isolate yourselves from rogue changes? (ex. labels,

branching)

17

Page 18: Some slides adapted from:

Configuration Management – Version Labels

Version Control Software provides support for attaching labels to all files or a group of files at a particular instant in time (milestones). These labels provide snapshots that allow you to easily go back to a particular point in time.

Some things to consider are: When will you apply labels to your source code? (ex. At the start of

each testing cycle, the week before and night before each deliverable) What will the version labels look like? (ex. Alpha 1.0.51) What will the version label comments look like? (ex. Sales Report

implementation complete and ready for testing) Where and how will you display this version label in the software for

bug reporting?

18

Page 19: Some slides adapted from:

Configuration Management - Branching

Branching allows people to make changes in one or more branches independently of the main trunk.

Some things to consider are: When will you create branches? Will you all work from the trunk or from separate branches? How and when will you merge the branches back to the trunk?

Video on Branching & Merging

19

Page 20: Some slides adapted from:

Configuration Management - Building

Many companies design a special machine as the “Build Machine” which is only used for performing an Automated Build of the software.

Some things to consider are: Which machine will be the Build Machine? Will you create a script to perform automated builds? How often will you build the software? Will each build be labeled? (usually a good idea)

20

Page 21: Some slides adapted from:

21

Collaboration Tools Help to organize documents, ideas, bugs, etc amongst a team:

What Collaboration Tool will you use for collaborating with your team? The Tools section of the Wiki Start page lists various options including: Trello and

PivotalTracker GitHub, BitBucket and Team Foundation Server also have built-in collaboration

support Wikis such as wikidot can also be a great tool for collaboration but they generally lack

issue/bug tracking Will Testers add traceable issues to the system every time a bug is

found? (usually a good idea) Will you use a discussion board or Wiki for brainstorming and sharing

ideas?

Page 22: Some slides adapted from:

22

Quality Management How often will you test the product? Will you do Unit Testing, Module Testing, Integration Testing

or some combination of them? Will you use a Test Driven Development approach? Where will you record the issues that are uncovered? Will you use automated tests and frameworks (jUnit, Nunit,

etc.)?

Page 23: Some slides adapted from:

23

Software Development Plan A Software Development Plan is designed to address strategies

for many of the issues we have addressed including: Implementation and Testing Strategy Configuration Management (labeling, branching, merging, etc.) Collaboration Tools and Bug Tracking Quality Management Testing Tools And many other important topics

Page 24: Some slides adapted from:

24

Exercises In your Capstone Groups discuss:

1. How you will apply some of the key elements (Configuration Mgmt, Collaboration Tools, Test Strategy, Testing Tools, etc.) of a Software Development Plan which were discussed today!

2. Your plan for Deliverable 4 (Project Plan) and Deliverable 5 (UI Prototype).

Page 25: Some slides adapted from:

25

Group Meetings We will be meeting with each group today to assess

your progress and provide some advice