CSCI 222 system development

Rational Unified Process

APPROACH

CSCI 222 DR SIM

Hump Chart

CSCI 222 DR SIM

Goals of Inception
The objectives of the Lifecycle Objectives (LCO) milestone at the end of the Inception Phase are as follows : 1.

2.

The people who will use the final product, and the buyers, developers, and project managers (the stakeholders) have bought into the project. All stakeholders understand and agree about : a. what needs to be done (scope), b. how long it will probably take (high-level schedule), and c. what it will probably cost (budget). CSCI 222 DR SIM

Goals of Inception
3.

The stakeholders agree that their expectations and priorities (requirements) for the product are correctly captured and under stood by the others.
Everyone has had : a. the opportunity to flag perceived concerns (risks) and b. devised a way to handle each of them should they arise (mitigation strategy).
CSCI 222 DR SIM

4.

Goals of Inception
The artifacts developed to support the LCO review are : 1. The VisionWhat are we trying to accomplish? 2. Business CaseWhat is this going to cost, and is it worth the effort? 3. Risk ListWhat could derail us, and how are we going to stay on track? 4. Software Development Plan, Tools, Templates and Environment What do we need, and when, to get the product built and rolled out?

CSCI 222 DR SIM

Goals of Inception
The artifacts developed to support the LCO review are : 5. Iteration PlanWhat are our immediate development goals? 6. Product Acceptance PlanHow do we know we built the right product? 7. Use-Case ModelHow will users interact with our product to get something useful out of it? 8. GlossaryWhat are the objects in our domain?

CSCI 222 DR SIM

Goals of Elaboration
The objectives of the Lifecycle Architecture (LCA) milestone at the end of the Elaboration phase are as follows : 1. We know exactly what were going to build (stable architecture), and end users agree that it will support their needs (stable requirements). 2. We have described the key scenarios that the product needs to support to be considered successful, and we have proved through a series of executable prototypes that we have made the right tradeoffs, and can meet the success criteria (mitigated architectural risks).

CSCI 222 DR SIM

Goals of Elaboration
3.

4. 5.

Our overall and iteration plans for the Construction phase are realistic enough for work to begin (stable plans). Our budget burn rate to date has been realistic. We have established a suitable supporting environment and infrastructure to develop the product.

CSCI 222 DR SIM

Goals of Elaboration
The artifacts developed to support the LCA review are :
1. 2.

3.

Updated Vision Document, Risk List, Software Development Plan, Iteration Plan and Use-Case Model. Supplementary Specification - capture the nonfunctional requirements (performance, reliability, we want it in pink polka dot, and so on). Prototypes - quick slap together experimental executables used to explore software ideas (exploratory) on what parts are going to hang together (structural), or demonstrate specific behavior (behavioral), or even parts that may be scaled up into production code (evolutionary). Usually this is throwaway code. CSCI 222 DR SIM

Goals of Elaboration
4.

5.

6.

10

7.

Software Architecture Document - describes the key design elements and mechanisms (Logical View) needed to support the functional requirements (Use-Case View), and how the components will work together (Process View) and execute on their target plat form (Deployment View). Design Model - captures the product design, ensuring that the design meets user requirements and that the path to implementation is clear. Implementation Model - an organized collection of components, data, and subsystems that express the product design. Project Specific Templates and Tools to support product CSCI 222 DR SIM development.

Goals of Construction
Objectives of the Initial Operational Capability (IOC) Milestone : Produce an Alpha version of the product that is sufficiently mature to be released to first-adopter users. Ensure that users are ready to test and use the product. Validate that there is sufficient budget to complete the project.
CSCI 222 DR SIM

1.

2. 3.

11

Goals of Construction
The artifacts developed to support the IOC review are : 1. 2. 3.

4.

5.

Updated and expanded Implementation Model. Updated Design Model based on new design elements identified during the Construction phase. Test Model including test designs and harnesses required to validate the executable. Deployment Plan describing the tasks and resources required to install and test the developed product so that it can be effectively transferred to the user community. Preliminary draft of use-case based user manuals and training materials.
CSCI 222 DR SIM

12

Goals of Transition
Objective of the Product Release Milestone (PRM) : 1.

The end users are ready to take delivery of the product.

13

CSCI 222 DR SIM

Goals of Transition
To support that objective, activities such as the following need to have been completed : 1. The users have validated and accepted the product, and are on their way to supporting the product in-house. 2. The users are trained and know how to make the transition from their legacy system to the new one. 3. The product is packaged for pricing and promotion rollout to the marketing, distribution, and sales forces. 4. The product has been handed over to support engineering, which has been trained for tuning, bug fixing, and enhancing the product. CSCI 222 DR SIM

14

Inception Phase

15

CSCI 222 DR SIM

Artifacts - Development Case

1. 2. 3.

4.
5. 6. 7.

8.
9.

Vision Risk list Use-case model Design model Build Component Test plan Test case Test results

10.

11. 12. 13. 14. 15. 16. 17. 18.

16

Product (the complete system as it is delivered to the customer) Release notes End-user support materials Iteration plan Iteration assessment Project plan Development case Programming guidelines Tools
CSCI 222 DR SIM

How to use Artifacts Inception Vision C Elaboration M Construction Transition

Review Details Formal

Tools Used MS Word

Responsible Project Manager

Risk List

MS Word

Project Manager

Use case model

Formal

MS Visio

System Analyst

Presentation of Project Plan

Test Plan

MS PowerPoint

Project Manager

Formal

MS Word

Project Manager

Test Results

Formal

MS Excel

Implementer

Product (release)

Formal

ASP.NET

Software Architect

Prototype

Formal

HTML

User Interface Designer System Analyst

Release Notes

Formal

MS Word

End-User support materials Iteration Plan C M M

Formal

MS Word

Software Architect

MS Project

Project Manager

Development case

Informal

MS Excel

System Analyst

17

Tools

MS Window Software Architect XP, MS .NET, CSCI 222 DR SIM MS SQL 2000

Sample of Role Map

Bryan System Analyst User Interface Designer Database Designer Software Architect Integrator Implementer Test Designer Tester Deployment Manager Technical Writer Configuration Manager Project Manager X X X X X X X X X X X X X X X X X Wint X X X X X X X X X X X X X X X X Zeya William Jun Cheng X

18

Tool Specialist

CSCI 222 DR SIM

Figure 4.4 illustrates the Plan section of a Inception Iteration Plan.

19

CSCI 222 DR SIM

Risk List
S/N 1 Description Different Operating System for current system in the office Priority High Indicator Inability to perform all functions of the applications Strategy & Contingency A web-base solution application to be developed. MS SQL Express version is selected instead. To establish training and user guides after deployments. Project Manager will discuss career goals with each developer, and try to assign tasks appropriately.

Database chosen was MS Access

Medium

Lack of security and concurrent connections Lack of knowledge of product

User unfamiliar with new system

Medium

Some developers may leave the project before it is finished

Medium

Conflict of interest and goals between group members and company.

Developers has different work schedule and commitments

Low

Lack of time to meet

Submission of individual commitment timetable to project manager for consolidation. Web meeting and constant email updates will be conducted.

20

CSCI 222 DR SIM

Project / Iteration Plan

21

CSCI 222 DR SIM

Sample of Project Budget

Procurement of Hardware and Software
Hardware Requirement Leasing Line 1 x Web Server 1 x Database Server Software Requirement 2 x Window Server 2003 Standard Editions 1 x Microsoft SQL Server 2005 Standard Editions

Sample of Development and Implementation cost

Description No. 1 Web Server : IBM x226 series Intel Xeon 3.2 Ghz , 1 GB RAM, 2 x 36.4 GB SCSI Hardisk, Microsoft Window 2003 Standard Editions Database Servers : IBM x226 series Intel Xeon 3.2GGhz, 2 GB RAM 2 x 73.4 Gb SCSI Hardisk Microsoft Window 2003 standard Editions 1mpbs Lease Line from Singtel for 1 year 1200 x 12 + 1500 (setup fee) - annually Microsoft SQL Server Standard Editions, Processor Licensing IT Support Manpower cost - Annually Development Cost (Based on 3 months development time & 40% of teams capacity) Annually: $11,554.00 Price

$14,181.00

3 4 5 6

$25,500.00 $6,000.00 $24,000.00 $12,000.00 $48,000.00 $94,235.00

22

One-time setup fee:

CSCI 222 DR SIM

Use Case Diagram for Stock Request Module

23

CSCI 222 DR SIM

Use Case Diagram for Stock Allocation Module

24

CSCI 222 DR SIM

Elaboration Phase

25

CSCI 222 DR SIM

Executable Architecture (EA)

1.

2.

EA is used : c. to uncover any unknown or perceived risks in schedule or budget. d. to evaluate one or more specific architectural qualities, performance, reliability, modifiability, security and safely e. to serve as a baseline for the rest of the development. f. to identify reuse opportunity. Its development is also good way to bring the development organisation up to speed with tools, languages, technologies, processes and performance calibration.
CSCI 222 DR SIM

26

Executable Architecture (EA)

27

CSCI 222 DR SIM

Executable Architecture Diagram

28

CSCI 222 DR SIM

VOPC Diagram
1.

2.

Many people new to object-oriented development find it difficult to identify good objects. The RUP provides concrete guidelines that greatly facilitate this task by dividing classes into three categories, or socalled stereotypes:
CSCI 222 DR SIM

29

Figure 17.2 - View of Participating Classes. - shows the analysis classes whose instances participate in a given use case. - provides a high-level understanding of what classes are involved, without focusing on details such as what operations are involved at what time to provide the functionality of the use case.

30

CSCI 222 DR SIM

Use Case Diagram for Stock Request Module

31

CSCI 222 DR SIM

VOPC diagram for Stock Request Module

0..n 0..1
ve sa

RequestDetail

Status

0..1 1 1 0..1 0..1 Login Form authentication 0..1

authenticate

0..1

1 Stock Request Successful Page

0..1

Stock Request Form

`

Request Controller

0..1 0..1 1 Search Request Form 1 0..n 1 0..1 0..1

0..1

0..n RequestSearch Controller 0..1 Other Department Manager 0..n 1 0..n 1..n 1..n
get

Request List (Detail)

Department

User

32

Status

RequestDetail

Stock

CSCI 222 DR SIM

Use Case Diagram for Stock Allocation Module

33

CSCI 222 DR SIM

VOPC Diagram for Stock Allocation Module

34

CSCI 222 DR SIM

Construction Phase

35

CSCI 222 DR SIM

Objective 1 : Minimise development cost and achieve some degree of parallelism

1.

Organise around architecture a. Robust architecture divides systems responsibilities into well-defined subsystems. b. Helps with communication i. increase in communication paths destroys project team efficiency, and you need to find better means of communication (other than everybody communicating with everybody) ii. Achieved by having 1 team responsible for the architecture, and several small teams each responsible for one / several subsystems
CSCI 222 DR SIM

36

Objective 1 : Minimise development cost and achieve some degree of parallelism

2.

3. 4.

Configuration management a. Configuration management system b. Integration planning Enforce the architecture Ensure continual progress a. Create one team, with one mission b. Set clear, achievable goals for developers c. Continually demonstrate and test code d. Force continuous integration

37

CSCI 222 DR SIM

Objective 2 : Iteratively develop a complete product that is ready to transition to its community
1. 2. 3. 4. 5.

Describe the remaining use cases and other requirements Fill in the design Design the database Implement and unit-test code Do integration and system testing a. Identify targets of testing by analyzing the iterative plan to make sure that you properly test what is produced in the current iteration. b. Identify testing ideas c. Analyze testing ideas d. Implement test e. Analyse test failures & file defects & change request.
CSCI 222 DR SIM

38

6.

Early deployments and Feedback loops

a.

b.

c.

d.

Brining a few users to development environment & demonstrate key capabilities Brining a few users to development environment & having them use the product for some time Installing the software at a test site & sitting with the yuser so they are using the software For hosted applications, providing some users with early access. Need to guide the user thru the application which may not be stable or intuitive to use at this stage.

7. 8.

Prepare for beta deployment Prepare for final deployment

a.

b. c.

39

Producing material for training users & maintainers to achieve self-reliability later. Preparing deployment site & converting operational databases Preparing for launch : packaging & production; preparing for rollout to marketing, distribution and sales forces; preparing for field personnel training.
CSCI 222 DR SIM

Key Test Artifacts

1.

2.
3. 4. 5. 6. 7. 8.

Test evaluation summary. Test Plan Test-idea list Test suite Test scripts Test cases Deflects Workload model
CSCI 222 DR SIM

40

Testing Ideas

41

CSCI 222 DR SIM

Test Ideas

A test idea is a brief statement that identifies a test that might be useful. A test idea differs from a test case, in that the test idea contains no specification of the test workings, only the essence of the idea behind the test. Test ideas are generators for test cases: potential test cases are derived from a test ideas list. A key question for the tester or test analyst is which ones are the ones worth trying.
CSCI 222 DR SIM

42

Brainstorm Test Ideas

Were about to brainstorm, so lets review Ground Rules for Brainstorming

The goal is to get lots of ideas. You brainstorm together to discover categories of possible testsgood ideas that you can refine later. There are more great ideas out there than you think. Dont criticize others contributions. Jokes are OK, and are often valuable. Work later, alone or in a much smaller group, to eliminate redundancy, cut bad ideas, and refine and optimize the specific tests. Often, these meetings have a facilitator (who runs the meeting) and a recorder (who writes good stuff onto flipcharts). These two keep their opinions to themselves.
CSCI 222 DR SIM

43

Exercise: Brainstorm Test Ideas

A field can accept integer values between 20 and 50. What tests should you try?

44

CSCI 222 DR SIM

A Test Ideas List for Integer-Input Tests

Common answers to the exercise would include:

Test 20 19 0 Blank Why its interesting Smallest valid value Smallest -1 0 is always interesting Empty field, whats it do? Expected result Accepts it Reject, error msg Reject, error msg Reject? Ignore?

49
50 51

Valid value
Largest valid value Largest +1 Negative number

Accepts it
Accepts it Reject, error msg Reject,CSCI 222 DR SIM error msg

45

-1

Where Do Test Ideas Come From?

Where would you derive Test Ideas Lists?

Models Specifications Customer complaints Brainstorm sessions among colleagues Experiences

You should keep this list and reuses from project to project
CSCI 222 DR SIM

46

Identify a Generic List of Test Ideas

Think about the categories of values youd consider generally applicable in an integer input field with Lower Bound (LB) and Upper Bound (UB).
Test Why its interesting Expected result

47

CSCI 222 DR SIM

A Catalog of Test Ideas for IntegerInput tests

Nothing Valid value At LB of value At UB of value At LB of value - 1 At UB of value + 1 Outside of LB of value Outside of UB of value 0 Negative At LB number of digits or chars At UB number of digits or chars Empty field (clear the default value) Outside of UB number of digits or chars

48

Non-digits Wrong data type (e.g. decimal into integer) Expressions Space Non-printing char (e.g., Ctrl+char) DOS filename reserved chars (e.g., "\ * . :") Upper ASCII (128-254) Upper case chars Lower case chars Modifiers (e.g., Ctrl, Alt, ShiftCSCI 222 DR SIM Ctrl, etc.)

The Test-Ideas Catalog

A test-ideas catalog is a list of related test ideas that are usable under many circumstances. For example, the test ideas for numeric input fields can be catalogued together and used for any numeric input field. In many situations, these catalogs are sufficient test documentation. That is, an experienced tester can often proceed with testing directly from these without creating documented test cases.
CSCI 222 DR SIM

49

RUP Test Manager Role, Activities, and Artifacts

Activities:

Agree Mission Test Manager

Identify Test Motivators

Obtain Testability Commitment

Assess and Advocate Quality

Assess and Improve Test Effort

Artifacts:

Test Manager

Test Plan

Test Evaluation Summary

The Test Manager role is tasked with the overall responsibility for the test effort's success.

50

CSCI 222 DR SIM

RUP Test Analyst Role, Activities, and Artifacts

Activities:

Test Analyst

Identify Targets of Test

Identify Test Ideas

Define Test Details

Define Assessment and Traceability Needs

Determine Test Results

Artifacts:

Test Analyst

Test Ideas List

Test Case

Workload Analysis Model

Test Data

Test Results

51

The Test Analyst role is responsible for initially identifying and defining the required tests, and subsequently evaluating the results of the test effort. CSCI 222 DR SIM

RUP Test Designer Role, Activities, and Artifacts

Activities:

Test Designer

Define Test Approach

Define Test Identify Structure the Define Develop Test Environment Testability Test Testability Guidelines Configurations Mechanisms Implementation Elements

Artifacts:

Test Designer

Test Automation Architecture

Test Interface Specification

Test Environment Configuration

Test Suite

Test Guidelines

The Test Designer role is responsible for defining the test approach and ensuring its successful implementation.

52

CSCI 222 DR SIM

RUP Tester Role, Activities, and Artifacts

Activities:

Implement Test Tester

Implement Test Suite

Execute Test Suite

Analyze Test Failure

Artifacts:

Tester

Test Scripts

Test Log

53

The Tester role is responsible for the core activities of the test effort, which involves conducting the necessary tests and logging the outcomes of that testing. 222 DR SIM CSCI

Testing Templates

54

CSCI 222 DR SIM

Testing Plan

The definition of the goals and objectives of testing within the scope of the iteration (or project), the items being targeted, the approach to be taken, the resources required and the deliverables to be produced.

55

CSCI 222 DR SIM

Testing Template

Introduction Objectives/Aim/Scope/Restriction Resources

People Tools Environment (machine, data,etc)

Deliverables Schedule Design approach (testing approaches) Test Cases description

CSCI 222 DR SIM

56

Test Specification

Main parts

Introduction Test Plan (Overall Strategy) Testing Procedures Process model (Adaptable process model) Software quality assurance plan (SQA Plan)

From http://www.rspa.com/

They are part of a bigger plan called

57

It includes Reviews activities too

CSCI 222 DR SIM

Test Specification

Introduction

1.1 Goals and objectives Overall goals and objectives of the test process are described. 1.2 Statement of scope A description of the scope of software testing is developed. Functionality/features/behaviour to be tested is noted. In addition any functionality/features/behaviour that is not to be tested is also noted. 1.3 Major constraints Any business, product line or technical constraints that will impact the manner in which the software is to be tested are noted here.

Test Plan Testing Procedures

CSCI 222 DR SIM

58

Test Specification
1. Introduction 2. Test Plan
2.1 Software (SCIs) to be tested 2.2 Testing strategy
2.2.1 Unit testing 2.2.2 Integration testing 2.2.3 Validation testing 2.2.4 High-order testing

2.3 Testing resources and staffing 2.4 Test work products 2.5 Test record keeping 2.6 Test metrics 2.7 Testing tools and environment 2.8 Test schedule

3. Testing Procedures

59

CSCI 222 DR SIM

Test Specification
1. Introduction 2. Test Plan 3. Testing Procedures
3.1 Software (SCIs) to be tested 3.2 Testing procedure 3.2.1 Unit test cases 3.2.1.2 Stubs and/or drivers for component i 3.2.1.3 Test cases component i 3.2.1.4 Purpose of tests for component i 3.2.1.5 Expected results for component i 3.2.2 Integration testing 3.2.3 Validation testing 3.2.3.1 Testing procedure for validation 3.2.3.3 Expected results

60

CSCI 222 DR SIM

61

CSCI 222 DR SIM

62

CSCI 222 DR SIM

Activities of the Test

A. B.

C.
D. E.

F.

Define test mission Verify test approach Validate build stability (smoke test) Test and evaluate Achieve acceptable mission Improve test assets

63

CSCI 222 DR SIM

A. Define Test Mission

1. 2. 3. 4. 5.

Identifying the objectives for the testing effort and deliverable artifacts. Identifying a good resource utilization strategy. Defining the appropriate scope and boundaries for the test effort. Outlining the approach that will be used, including the tool automation. Defining how progress will be monitored and assessed.
CSCI 222 DR SIM

64

B. Verify Test Approach

1.

2.

3.

4.

5.

Identifying the scope, boundaries, limitations, and constraints of each tool and technique. Gain an understanding of the constraints and limitations of each tool and technique in the context of your specific project, and either to find an appropriate implementation solution for each technique or to find alternative techniques that can be implemented. Help to mitigate the risk of discovering too late in the project lifecycle that the test approach is unworkable. Establish the basic infrastructure to enable and support the Test Approach. Obtaining commitment from the development team to provide and support the required testability to achieve the Test Approach.
CSCI 222 DR SIM

65

C. Validate Build Stability (Smoke Test)

1. Validate that the build is stable enough for detailed test and evaluation efforts to begin.

2. Also referred to as a smoke test, build verification test, build regression test, sanity check, or acceptance into testing. 3. Prevent the test resources from being wasted on a futile and fruitless testing effort.
66
CSCI 222 DR SIM

C. Validate Build Stability (Smoke Test)

For each build to be tested, this work is focused on
a.

b.
c.

d.

67

Making an assessment of the stability and testability of the build: Can you install it, load it, and start it ? Gaining an initial understandingor confirming the expectationof the development work delivered in the build: What was effectively integrated into this build? Making a decision to accept the build as suitable for useguided by the evaluation missionin further testing, or to conduct further testing against a previous build. CSCI 222 DR SIM

D. Test and Evaluate

For each test cycle, this work focuses mainly on a. Providing ongoing evaluation and assessment of the Target Test Items. b. Recording the appropriate information necessary to diagnose and resolve any identified issues. c. Achieving suitable breadth and depth in the test and evaluation work. d. Providing feedback on the most likely areas of potential quality risk.

68

CSCI 222 DR SIM

E. Achieve an Acceptable Mission

1.

Deliver a useful evaluation result from the test effort to your stakeholders, where useful evaluation results are assessed in terms of the Mission. In most cases that will mean focusing efforts on helping the project team achieve the Iteration Plan objectives that apply to the current test cycle. a. Where appropriate, revising the Evaluation Mission in light of the evaluation findings so as to provide useful evaluation information to the project team.

2.

69

CSCI 222 DR SIM

E. Achieve an Acceptable Mission

3.

70

For each test cycle, this work focuses mainly on a. Actively prioritizing the minimal set of necessary tests that must be conducted to achieve the Evaluation Mission. b. Advocating the resolution of important issues that have a significant negative impact on the Evaluation Mission. c. Advocating appropriate product quality. d. Identifying regressions in quality introduced between test cycles. e. Where appropriate, revising the Evaluation Mission in light of the evaluation findings so as to provide useful evaluation information to the project team. 222 DR SIM CSCI

F. Improve Test Assets

1.

Close the loop at the end of a test cycle or at least at the end of the iteration, to provide some feedback on the test process itself, and take advantage of the iterative nature of the lifecycle to maintain and improve your test assets. This is important especially if the intention is to reuse the assets developed in the current test cycle in subsequent test cycles or even in another project.
CSCI 222 DR SIM

2.

71

F. Improve Test Assets

3.

For each test cycle, this work focuses mainly on a. Adding the minimal set of additional tests to validate the stability of subsequent builds. b. Removing test assets that no longer serve a useful purpose or have become uneconomic to maintain. c. Maintaining Test Environment Configurations and Test Data sets. d. Documenting lessons learned - both good and bad practices discovered during the test cycle. This should be done at least at the end of the iteration
CSCI 222 DR SIM

72

TEST CASE FORM

73

CSCI 222 DR SIM

Transition Phase

74

CSCI 222 DR SIM

Objective 1 : Beta Test to validate that user expectation are met

1.

Capturing, analyzing and implementing change requests a. Provides a lot of user feedback from the beta testers. b. Thru interviews, online queries, submitted change requests, etc. c. Take time to analyze feedback, review & submit change requests to understand what are the changes before final release. d. Change request minor system tweaking such as fixing minor bugs, enhancing documentation / training materials, tuning system performance
CSCI 222 DR SIM

75

Objective 1 : Beta Test to validate that user expectation are met

2.

Metrics for understanding when transition will be complete a. Analyse defect metrics & test metrics help determine when transition is complete.
i.

ii.
iii.

When will the quality be good enough ? How many more defects can we expect to find ? When will we have tested all functionality ? How many new defects are found each day How many defects are fixed each day Important thing to focus on the trend rather than the actual number of defects.
CSCI 222 DR SIM

b.

Defect Metrics track

i.

ii.
iii.

76

Objective 2 : Train users and maintainers to achieve user self-reliability

1.

2.

3.

Appropriate training are given to all users, operational staff and maintenance teams. Large user base may need to start preparation of materials during construction phase train-the-trainers approach for speedy and large group users trainings.
CSCI 222 DR SIM

77

Objective 3 : Prepare Deployment Site and Convert Operational Databases

1.

Smooth transition can be complex for system replacement a. Data migration b. Parallel system runs c. Data synchronisation for parallel system d. Areas to host new machine, addition power supplies, new network, new security rules & desktop settings.

78

CSCI 222 DR SIM

Objective 4 : Prepare for Launch : Packaging, Production & Marketing Rollout

1.

79

Packaging, Bill of Materials & Production a. BOM uniquely identifies all constituent parts of a product. b. Final packaged product will consist of the s/w on some storage media, some documents / manuals, licensing agreement forms and packing itself. c. Ensure all items are in the final approval state at the time of delivery to manufacturer. d. Ensure application & installation s/w are virus free.
CSCI 222 DR SIM

Objective 4 : Prepare for Launch : Packaging, Production & Marketing Rollout

2.

80

Marketing Rollout a. Core Message Platform (CMP) i. 1 to 2 pages of product description. ii. Corner stone in any successful launch and is used as a baseline or template for all internal & external communication related to their product. b. Customer-consumable collateral i. Data sheets, whitepapers, technical papers, information on your website, per-recorded demos of the product, demo scripts and multimedia presentations on product overview.
CSCI 222 DR SIM

Objective 4 : Prepare for Launch : Packaging, Production & Marketing Rollout

2.

Marketing Rollout c. Sales support material i. Sales & technical presentations, field training material, fact sheets, positioning papers, competitive write-ups, coaching on how to meet sales objectives, references, success stories.. d. Launch material i. Press releases, press kits, analyst briefings and internal newsletter
CSCI 222 DR SIM

81

Objective 5 : Achieve stakeholder concurrence that deployment is complete

1.

Product Acceptance Test

a. b.

Final test action prior to deploying the software Goal is verify software is ready to perform those functions & tasks it was built for.

2.

Common Strategies for acceptance test : a.

Formal acceptance i. Highly managed process where there is a clear oneto-one supplier acquirer relationship. ii. Carefully planned & designed in the same degree as system testing iii. Most frequently performed by supplying organisation under control of the acquirer, by the acquirer itself or 3rd party appointed by acquirer.
CSCI 222 DR SIM

82

Objective 5 : Achieve stakeholder concurrence that deployment is complete

2.

Common Strategies for acceptance test : b.

c.

Informal acceptance i. Less rigorously defined test procedures that formal acceptance testing. ii. Functions & business tasks to be explored are identified & documented, but no particular test cases to follow. iii. Individual tester determine what to do. iv. Not as controlled as formal testing & subjective v. Most frequently performed by the end-user organisation. Beta Test i. Validate that user expectations are met. ii. Agree on the test cases & how they should be evaluated before acceptance testing is implemented & executed.
CSCI 222 DR SIM

83

Objective 6 : Improve Future Project Performance Thru Lessons Learned

1.

2.

Advisable to spend some time for post-mortem assessment to analyse and document a. What work well and what didnt. b. What refinements on process & development environment. c. What other lessons learned. Determine whether any work can be reused for other projects a. Remove sensitive data and store the reusable assets, such a way that can be easily found and used by other teams.
CSCI 222 DR SIM

84