ATM Software System Development

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________

Project Management, Software Testing Nasreen Iqbal Msc. Software Engineering [email protected] De Montfort University 1 1.1

INTRODUCTION Purpose The overall purpose of this project is to evaluate and analyses the requirement of the customer, design and implement the system, testing the functionality and maintain the software of an ATM component of a larger ATM network project, consistent with the requirement specification.

1.2

Scope The scope of the ATM is to support a computerized banking network. All activities directly related to the purpose are considered to be in scope. The other activities not directly related to the purposes are considered to be out of scope, such ATM hardware and concern issues.

1.3

Assumptions and Constraints The Assumptions of the project are as follows: 

The project is a model of a larger ATM network.



This project will deliver the software components.



The ATM hardware will available later in the installation and handle as a separate project.



All hardware documentation will be available at the time of installation.



XYZ-ATM project will involve Object-Oriented Analysis and Development process and write the code in C++ on Microsoft .Net platform on IBM mainframes.



The project should complete within the due date and budget.

The project will have the following constraints:   

1.4

1.5

Budget o o Time o Staff o

2 Million Should not exceed 12 Months XYZ appointed the deputy director of data center to liaise with the project leader, to monitor progress, and set priorities for the development team.

o

The development team will be composed of 20 staff from the Data Centre,

o

6 additional staff from the client / server interface development and required them based on priority of the project.

Schedule & Budget Details 

The project kick-off: 09 December, 2013



Software ready for operation: 09 December, 2014

Project Promises The following items listed are the deliverables to the ATM project manager.  1

Software documentation Page


2.1

Installation documentation

o

End-user detailed document



Software installation



Software training provided to the staff



2

o

o

Bank staff

o

ATM installers

o

The maintenance team

Project deliverable documentation o

The software requirements document

o

The software design document

o

The software project document

o

Software test document

DESCRIPTION Product Viewpoint The ATM network will work together with the software provided by the banks, where banks have defined interfaces for the communication. Banks Networks

ATM System

Bank Computer

Bank Database

Bank Computer

Bank Database

Bank Computer

Bank Database

Bank Computer

Bank Database

ATM Network

ATM

ATM NETWORK Conceptual ATM Model Card Reader Cash Dispenser KeyPad

ATM

Deposit Slot

Screen

Printer Operator

2

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ Conceptual Flow Diagram of ATM

Verify Access Code

[Incorrect]

Handle Incorrect Access Code

[Correct]

Ask forAmount [Resolved]

[Note Resolved]

[Amount not available] [Amount available] Deposit Slot Prepare to print Receipt

Dispense Cash

Finish Transaction & Print receipt

2.2

Organization XYZ has one data center in the UK, employing some 200 IT professionals. Their work involve the maintenance of the company’s existing Information Systems; network support; providing a help desk service to XYZ staff and the development of new applications. The following attached diagram (Appendix B) discussed the proposed team and their relation with the project management group. The team led will assign by the project leader for each group. The role and responsibilities for the below organization will discuss and diagrammed in the next project plan specification section.

3

Page


3

EVALUTION OF THE PLAN The project supported the traditional structure SSADM following the waterfall Modeling. The SSADM methodology is a well-defined methodology and it can produce well-documented, accurate information systems. The aim of SSADM is to provide logical data modeling and document the data requirements of the system being designed. In this traditional structure, the data is split into entities and relationships. However, the waterfall model is a process that follows the sequence. Based on this concept the project will move in the following phases, as shown in the following diagram:

4

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ 3.1

Duration & Resource Evaluation A successful full project is one delivered ‘On Time’, within budget and with the required quantity. Ref: chapter ‘Software effort estimation’ by bob. The project is required to complete with 12 months of duration, each phasein the development planning will provide the sufficient time along with the appropriate resources. The report and documentations of each phasedelivered a complete information. Our work-break-structure (WBS) based on SSADM followed waterfall model, i.e. one stage flows on to the next from the top to the bottom and evolves over the course of planning. The WBS presenting list for planning and a structure for providing report status during the implementation phase. The duration, schedule and work estimation for each branch activity will be performed using a combination of the following methods: 

The estimation carried forward as independent when more than one resource is assigned to the activity.



The resources are required to complete their activity within the estimated time. A detailed estimate will be requested and broken down into sub activity milestones.



The duration provided based on their role and work activities.



The maximum duration spends in the requirement and analysis phase to build a strong structure.



Considering time limit, plan assigned multiple resources together to the structure and coding phase.

However, based on above evolution the WBS structure designed has the following faces. 1.1. The Requirement Analysis phase: The project leader must define the requirements that allow the developer to understand the structure of the software system. This development activity is part of a larger system, therefore the other resources must communicate to help with the development system. The total 64 days estimated with 10 resources included 4 Requirement Analysts, one Communication Expert, a Business Analyst, DB2 Expert and Security Specialist. The following are brief scenarios included in this phase.

5



Feasibility is an activity that should ideally be structured for all but low risk projects. It is a very initial decision point where a possible decision includes the option to terminate the project. Once completion of this phase we move into the first Module Requirements Analysis of SSADM. The study of technical, operational and economic feasibility, performed by the management.



Requirements Analysis: identified the requirement, and the current environment is modeled, produced and presented. The data flow modeling and the logical data modeling technique will be used.



Interview: the interview begins with stockholder, banking experts and staff to gain a better understanding of the system activity.



Software Development requirements: this phasebuilds as the backbone for the project that will carefully focus on its each and every single perspective. o

The important section will be focused on the project to develop the software and interfaces for the hardware, software and network communication.

o

The project based on, network activity, therefore, the network requirement study and analysis will pay a major and critical role for the development of this project.



Prioritize and integrate requirements: The integrated priority list provides the participants' recommendations for programming assets in the planning, programming, and budgeting system process.



System Analysis: this phasecarried out an explicit formal inquiry that helps management to identify a better course of action and make a better decision.



Risk Analysis: every project has risk; this project will identify their risks and resolutions. The project will register all the major risk as an output.

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ 

System Security Analysis: the security of the data is an important part in this section which planned to gain the customer faith and reliability.



Create Software Requirements Specification Report: the final activity of this phaseto prepare reports for the next phase.

1.2. System Designing: System designing will model the architecture, components and interfaces for a system to specify the requirement. The designing duration estimated total 67 days with the team Software Architecture and designers. 

Perform Architectural Design: will cover the internal and communication architecture between ATM and the bank.



Designing Interfaces: this phase will cover to achieve the goal to make the user's interaction as simple and efficient in the form of designing interfaces.



Develop Algorithm: algorithm follows the well-defined set of instructions for completing a task, not a program, but a specific language that explore the idea of step the program will take to perform its tasks.



Perform Detailed Design: This process will perform with the development team to generate the application software and integrating the softwares and communications with these applications.



Design Test Cases: the test plan describes what to test, but a test case describes how to perform a particular test, our team will develop a test case for each test listed in the test plan.



Create Software Design Specification: This phase will be ended with the final document and handover to the next phase.

1.3. Coding The Data Center arranged 10 designers and programmers using the new technologies for the source code of the program and a Java programmer for the object oriented (OOPS) technology. The team facilitates the work of computer programmers, who specify the actions to be performed by a computer mostly by writing source code for the duration of 47 Days with the consideration of Lines of Code (LOC) essentials.

6



Create Test Data: before begin with the coding phase the test data developed for the programmers and test specialist.



Create Source Code: the source code that contained an instruction to tell the computer what to do using language C++.

Page


Generate Object Code: a sequence of instruction in a computer language, generating an executable by combining parts of the object.



Plan Integration: a joined planned exercise that ensures participations of all stockholders and involved team to determine or examine all the aspects in order to find the most suitable option for the course of action.



Perform integration: objects required to collect and build a complete designed called integration, a collaborative method for designing buildings which emphasizes the development of a holistic design.



Document Program Model: the complete documentation and the program model will be ready for the testing.

1.4. Testing The software testing, investigation conducted to provide stakeholders with information about the quality of the product or service under test. We have 2 specialists for the duration of 60 days, the following phases will cover. 

Testing Plan: The IEEE stander and other tools follow to perform this plan that builds the testing phase structure.



Test Designing: test design is the act of creating and writing test suites for testing software. We have several recommended testing tools to perform this phase by the test specialist.



Unit testing: we shall create the individual units of source code that is, the sets of one or more computer program modules together with associated control data.



Component Testing: till now we have designed and developed model, therefore the model level testing that will find the bugs in the model and will verify the functions of the model.



System Testing: the final and important testing will be done by system testing that integrated system to evaluate the system's compliance with its specified requirements.



Documentation & Provide Feedback to Programmers: finally the document will be submitted all the tested results and defects.

1.5. Operation & Maintenance: The Operation and Maintenance has 2 most important phases, i.e. installation and maintenance. The training for the bank staff and manuals, documentation will be done before these two phases. I have assigned total 50 days with 2 installation specialists.

7



Final check and verification: because the system has limitations and budget specification therefore I recommended having final review and verification of the risk rescue process.



Documentation: the documentation phase will prepare user and other operational manuals.



Training: the user’s training for the various bank staff is required to run the ATM software, included installation instructions.



Distribute Software: in this process the final software version copy will deliver to the banks along with their manuals.



Install Software: after the acceptance of the software, the installation will take place with the cooperation of hardware and bank interface provider. Here the installers, programmers and network expert might work together to make sure that the ATM working fine.



Perform Adaptive Maintenance: the 1 day for the maintenance if needed



Perform Preventative Maintenance: the preventive cautions grace period provided by the software providers to the stakeholders for their queries and further assistance.

Page


3.2 Cost Estimation: The estimate covered under the strategic plan and feasibility study based on, top down and bottom up approach. The estimate breaks the project into its relevant component tasks. The plan exhaustive investigates the SLOC and LOCS of each identified step and then will consider the other recourses. 

Cost estimation for each activity will be performed by multiplying the amount of work expected from the daily rate for the resources connected to the activity.



The total estimated amount calculated for the multiple resource used in a single task.

Staff Recourses: documentation.

The staffing recourses arranged with the group of programmers, management, analysts,

Computer Recourses: the computer recourses are important evaluation for the estimation, included terminals, disk space and CPU’s; this is considered as out of scope. Overhead: included other support, meetings estimation, and performance assessment, project control system estimation, not covered.

3.3 Cost Estimation Table

Requirement Analysis

1

1.1

1.2

8

Page

Task Name

Duratio n

Start

Finish


64 days

Mon 12/9/13

Thu, 3/6/14

Develop System Architecture

20 days

Mon 12/9/13

Fri, 1/3/14

Requirement Analysts-1

$64,000.00

12 days

Mon 12/9/13

Tue, 12/24/13

Communication Expert

$76,800.00

Interview

Resource Names

Cost $540,800.00

1.3

Define & Develop Software Requirements

14 days

Mon 12/9/13

Thu, 12/26/13


$44,800.00

1.4

Define Interface Requirement

14 days

Fri, 12/27/13

Wed, 1/15/14

Business Analyst, DB2 Expert

$89,600.00

1.5

Prioritize and Integrate Requirements

11 days

Wed, 12/25/13

Wed, 1/8/14


$35,200.00

1.6

System Security Analysis

22 days

Mon 1/6/14

Tue, 2/4/14

Security Specialist

$70,400.00

1.7

Software Quality & Risk Analysis

14 days

Thu, 1/16/14

Tue, 2/4/14

Project Leader, Requirement Analysts-1

$89,600.00

1.8

Create Software Requirements Specification Report (SRS)

22 days

Wed, 2/5/14

Thu, 3/6/14


$70,400.00

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ System Designing

Coding

2

System Designing

67 days

Wed, 2/5/14

Thu, 5/8/14

2.1

Perform Architectural Designing

21 days

Wed, 2/5/14

Wed, 3/5/14

Software Architect-1

$67,200.00

2.2

Design Interfaces

21 days

Fri, 3/7/14

Fri, 4/4/14


$67,200.00

2.3

Develop Algorithm

12 days

Thu, 3/6/14

Fri, 3/21/14


$38,400.00

2.4

Design Test Cases

12 days

Mon 4/7/14

Tue, 4/22/14


$38,400.00

2.5

Perform Detailed Design

8 days

Mon 3/24/14

Wed, 4/2/14

Software Architect-4, Software Architect-1

$51,200.00

2.6

Create Software Design Specification

24 days

Mon 4/7/14

Thu, 5/8/14


$76,800.00

Coding

47 days

Fri, 5/9/14

Mon 7/14/14

3.1

Create Test Data

19 days

Fri, 5/9/14

Wed, 6/4/14

Database Specialist

3.2

Create Source Code

19 days

Fri, 5/9/14

Wed, 6/4/14

Front-end Designer & Programmer-5-6, Front-End Designer & Programmer-5

$121,600.00

3.3

Generate Object Code

30 days

Fri, 5/9/14

Thu, 6/19/14

Java Programmer, Front-End Designer & Programmer-5-7

$192,000.00

7 days

Fri, 6/20/14

Mon 6/30/14

Front-end Designer & Programmer-5-8

$22,400.00

3

3.4

Testing

9

Page

Plan Integration

$339,200.00

$518,400.00 $60,800.00

3.5

Perform integration

9 days

Tue, 7/1/14

Fri, 7/11/14

Front-end Designer & Programmer-5-9, Java Programmer

$57,600.00

3.6

Document Program Model

10 days

Tue, 7/1/14

Mon 7/14/14

Front-end Designer & Programmer-5-10, Front-End Designer & Programmer-5

$64,000.00

Testing

60 days

Tue, 7/15/14

Mon

4

$278,400.00

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ 10/6/14 4.1

Develop, Test Requirement

24 days

Tue, 7/15/14

Fri, 8/15/14

Software Testers-1

$76,800.00

4.2

Unit Testing

14 days

Mon 8/18/14

Thu, 9/4/14

Software Testers-2

$44,800.00

4.3

Component Testing

22 days

Mon 8/18/14

Tue, 9/16/14

Software Testers-1

$70,400.00

13 days

Mon 9/5/14

Wed, 9/23/14

Software Testers-2

$41,600.00

Software Testers-1

$44,800.00

4.4

Operation & Maintenance

System Testing

4.5

Provide Feedback to Programmers

14 days

Wed, 9/17/14

Mon 10/6/14

5


50 days

Tue, 10/7/14

Mon 12/15/14

5.1

Final checks and verification

28 days

Tue, 10/7/14

Thu, 11/13/14

Project Leader

5.2

Documentation & User Manual

17 days

Tue, 10/7/14

Wed, 10/29/14

Document Writer1, Document Writer-2

$108,800.00

$307,200.00

5.3

Training

8 days

Tue, 10/7/14

Thu, 10/16/14

Training & Installation Specialists-1 [0%]

$25,600.00

5.4

Distribute Software

5 days

Fri, 11/14/14

Thu, 11/20/14

Training & Installation Specialists-2

$16,000.00

12 days

Fri, 11/14/14

Mon 12/1/14


$38,400.00


$28,800.00

5.5

Install Software

5.6

Perform Adaptive Maintenance

9 days

Tue, 12/2/14

Fri, 12/12/14

5.7

Perform Preventative Maintenance

1 day

Mon 12/15/14

Mon 12/15/14

$0.00

Total Other Expenses

10

Page

$89,600.00

=

1984000 16000


4

PROJECT PLANNING PROCESS: [Planning Identifier: PPP-01-01-14-1.0] The planning process will cover the successful implementation of project activities, it worked as a group of linked techniques & methods that offers the featured list of activities, also responsible how the work will get done, by whom, when, and for how much, somehow I tried to explain in this chart showing below.

This Project Planning includes scheduling diagrams using Gantt where activities and links represent task dependencies as follows. 

Define Activity



Identify Activity



o

Activity based approach

o

Product based approach

o

Hybrid approach

Network Planning Model

The task performed using CPM (Critical path method) to visualize the project as a network followed by start and end. 4.1

Task Dependency Specification for WBS:

1

Task Name

Duration


64 days

2


20 days

3

Interview

12 days

11

Page

Predecessors

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ 4


14 days

5


14 days

5

6


11 days

4

7


22 days

3

8


14 days

6

9

Create Software Requirements Specification Report (SRS)

22 days

7,8

System Designing

10

67 days

11


21 days

9

12

Design Interfaces

21 days

10

13

Develop Algorithm

12 days

12

14

Design Test Cases

12 days

13

15


8 days

14

16


24 days

13

Coding

17

47 days

18

Create Test Data

19 days

17

19

Create Source Code

19 days

17

20


30 days

15,17,16

21

Plan Integration

7 days

20,21,19

22

Perform integration

9 days

22

23


10 days

22

Testing

24

60 days

25

Develop Test Requirement

24 days

24,23

26

Unit Testing

14 days

26

27

Component Testing

22 days

26

28

System Testing

13 days

27

29


14 days

28

30


31


28 days

30,29

32


17 days

30

33

Training

8 days

30

34

Distribute Software

5 days

32,33,34

35

Install Software

12 days

32

36


9 days

36,35

37


1 day

37

12

Page

50 days

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ Forward & Backward Pass Calculation for WBS 4.2

Forward Pass EST Develop System Architecture =0 EST System Security Analysis = EFT Develop System Architecture EST Create Software Requirements Specification Report(SRS) = MAX(EFT System Security Analysis, EFT Prioritize and Integrate Requirements ) =42 EST Design Interfaces =EFT Design Test Cases =64 EST Create Software Design Specification =EFT Design Interfaces=85 EST Generate Object Code = MAX(EFT Perform Detailed Design, EFT Design Test Cases, EFT Create Software Design Specification )=109 EST Plan Integration = max(EFT Create Test Data , EFT Create Source Code, EFT Generate Object Code )=139 EST Document Program Model = EFT Plan Integration =146 EST Develop Test Requirement = MAX(EFT Perform integration, EFT Document Program Model )=156 EST Component Testing =EFT Develop Test Requirement =180 EST Provide Feedback to Programmers = EFT Component Testing=202 EST Final checks and verification = EFT Provide Feedback to Programmers =216 EST Install Software =EFT Final checks and verification =244 EST Perform Adaptive Maintenance =MAX(EFT Distribute Software, EFT Install Software)=256 EST Perform Preventative Maintenance =EFT Perform Adaptive Maintenance =256

4.3

Backward Pass LFT Develop System Architecture =LST Develop System Architecture =20 LFT System Security Analysis = LST Create Software Requirements Specification Report(SRS) =42 LFT Create Software Requirements Specification Report(SRS)s =LST Design Interfaces =64 LFT Design Interfaces =MIN(LST Design Test Cases, LST Create Software Design Specification )= 85 LFT Create Software Design Specification = LST Generate Object Code =109 LFT Generate Object Code =LST Plan Integration =139 LFT

Plan Integration

LFT Document

=MIN(LST Perform integration, LST Document Program Model)=146

Program Model

=LST Develop Test Requirement =156

LFT Develop Test Requirement = MIN(LST Unit Testing, LFT Component Testing)=180 LFT Component Testing =LST Provide Feedback to Programmers =202 LFT Provide Feedback to Programmers =MIN(LST Final checks and verification, LST Documentation & User Manual, LST Training)=216 LFT Final checks and verification =LST Install Software =244 LFT Install Software =LST Perform Adaptive Maintenance =256 LFT Perform Adaptive Maintenance =LST Perform Preventative Maintenance =265 LFT Perform Preventative Maintenance =EFT Perform Preventative Maintenance =266 4.4

Work Breakdown Structure:

The Critical Path attached in the Appendix C. The Project Plan designs in the Microsoft Project 2010 attached to the report. 13

Page


5

RISK ASSESMENT PROCESS [Risk Identifier: RI-01-01-14-1.0] According to Roger L. Van Scoy – the Risk is a part of some activity that can never be eliminated, can all risks ever be known. A risk may not register a problem, but expected anytime in the entire project life cycle. Based on these analyzed phrases we essentially learned to establish balance between the negative and possible benefits. Thru, these norms we shall discuss and evaluate the risk of this project. The assessment of the risk in the project has been constructed on the assumptions. I evaluated the assumption and planned the estimate and detect the errors. The analysis said that when there are no assumptions and everything goes smoothly in the project, formulate the indication of bugs. However, the assumptions could eliminate if they have no longer validation on the project, but the major bugs may not ignore in the project life cycle.

Hazard 5.1

problem

Risk

Phase 1, concept exploration With this phase will deal with the communication and interview between the staff, management and stakeholder. Sharing ideas and concept exploration helps to identify the risk with the various solutions. During the assessment the documentation and program drafting will help to organize the project and may help to eliminate the risk impartially. All the explorations and gathered concepts will be documented in this phase to carry forward the project.

5.2

Phase 2, program Risk assessment The assumptions in the project carried bugs in the project. The project will tie up with the high level network development that must communicate and connect successfully with the software provided by the bank. The project will work only with the software component where physical components (Hardware) are out of scope that will raise the probabilities of risks. If we assess the team and its expertise, the risk prospects may increase because the new technology will be used. Another constraint is the schedule of the project which has to complete on time, the management should capable enough to be committed. The other factor is budget limitation may increase the possibility of risk. Furthermore the security issues also a kind of constraints. Each function, transactions, payments and any act that's being performed by the customer or the structure itself would precis and real.

5.3

Phase 3, Capability Improvement SSADM suits very well to ATM project because the re-structural attitude. Importantly, the experts and programmers are required to improve their efficiency in their selected language and platform. The System development should focus precisely on the secured communication between their selected language and bank software and interfaces.

5.4

Phase 4, prototype This phase emphasizes the work on the capable progress efforts that last from phase two of the improved system model. The application will develop in a balanced approach and tested by the end of this phase and may enter in the final release version.

14

Page


Process Architecture

The Proposed Major Risk Diagram Technical Risk

Decision Merge

Project Kick -Off and Live date, in 12 month time New platform SSADM and Waterfall Methodology New platform C++ and DOT NET Technology

ATM Software & Network Collaboration Software Components using C++ DOT Net Technology

Bank

Computer

ATM Simulation

Interface

Development Risk

Dependency Risk Hardware Document

5.6

Risk Identification

5.7

The Software Development Risk Taxonomy

Hardware, Available in Time at the final stage.

According to Taxonomy, classification, the Software Development Risk categorized in three parts. 5.7.1

Product Engineering This class covered the physical activities that require product on time, which included software and documentation together become the classes that focused the performance of the work and include the following elements. (Reference Taxonomy)

5.7.2



Requirements: software product behavior, how it will function and how it will be used, becomes the important factor for the project development. The major failure of the software application might face in the network communication because it is difficult to combine processes, systems, languages into one using new technology. In this critical analysis the most important part is to provide the accuracy.



Design: C++ and .NET together will communicate with the several different languages provided by different banks, might become the cause of risk.



Code and Unit Test: so far the C++ language and .Net developed as successful languages. Insufficient experience might face incompetency with other applications. The successful testing may eliminate the risk of the project.

Development Environment This environment concerned with the project environment where the product will be plotted. The below few elements we would like to discuss in the consideration of risk analyses. Development Process: the communication of the methods and procedures, planning, documentation, suitability and enforcement used to develop the product.

15

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ Work Environment: the levels of cooperation, communication of the employee played a very import role in the development environment. Management process and methods: management process includes planning, controlling, budgeting and schedule task which help to eliminate the risk. 5.7.3

Program Constraints Many projects rely on the schedule and cost signs, but they must examine their plans and control technical risks with the intention to accomplish project quality. The top approach is to achieve the control upon the risks in the entire software development life series.

5.8



Resources: According to time management the team must be experienced and cooperation. So better to have high paid staff will help to complete their task in a short period based on their experience.



Dependency: We have dependency in the project i.e. Hardware providers, must define a timeline and contract between them with the legal lines.

The Risk Assessment Table & Project Risk

The following categorized table will be maintained for the duration of the project, listed the risk range from 1 to 10 and its severity (Negligible, critical and marginal) that obtained by the current risk factors. Risk Assessment Datasheet Risk Assessment Area Level 1 Mission And Goal Factor Management Risk

16

Page

Level 2 Project fit

Risk Rank

Severity

2

Negligible

Comments

Application factors -Nature of the application

5

Marginal

-Expected size of the application

4

Negligible

Project team stability

5

Marginal

-Experience and skills

8

High

Experience with application development projects, management plan and set the target to monitor the performance.

-Appropriateness of experience

8

High

New experience in this type developing, Management has to hear experts with the same skills and experience

-Staff satisfaction

5

Marginal

Staff involved since many projects and the staffing is not an issue for the Datacenter.

-Staff turnover rates

7

High

The more you pay, more you gain strategy need to apply by the management to avoid the hazard

-Project Factors

8

Marginal

The management so far planned and decided factor, required more attention and documented.

-Project objective

5

Marginal

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ -Cost estimation 5.8.1

8

High

Risk in cost escalation due to variance from estimate

Technical risks Risk Assessment Datasheet Risk Assessment Area

Level 1

Level 2

Technical Risk

Risk Rank

Probability Level Network Factor

-Network communication issue

9

Critical

Many external, unfamiliar

-Network security issue

8

Marginal

The security issue is most important for the reliability and trust of the stockholder and the customer satisfactions.

- ATM network and hardware supply

8

High

Available on time, at a later stage, the ATM network does not work independently

-Clint / Server issue

8

High

How to communicate with the bank server in the collaboration with the bank.

Interfaces from the banks will communicate over the network. The expectation of the risk becomes high and critical.

Hardware and software factors External Software Communication

10

Critical

Compatibility factor will may occur that will arise the failure of the final software application.

- External hardware

7

Marginal

Delay and tolerance will turn into risk.

Hardware interface documentation

Too Soon

-Cross platform development

Too soon

Software development factor

6

Marginal

The experience is new and the compatibility will be at high risk, the development factor may arise during development phase.

--Product knowledge Issue

8

High

New platform, lack of skills to execute the project and on time.

--Language Issue

5

Marginal

So far team has experience in other languages, but new in C++.

Changeover Factors & Project Content Factor -‘All-in-one’ changeover

17

Page

5

Marginal

The change control process that has not been followed, or is ineffective return a huge change process


5.8.2

- Early identification of defects

2

Negligible

Peer reviews are used sporadically.

- System dependencies

6

Medium

Some basics of the system are not yet understood.

Test & acceptance

6

Marginal

Requirement of stockholder and customer need to be satisfied.

Business risks

Threaten the viability of the software to be built (market risks, strategic risks, management risks, budget risks) Risk Assessment Datasheet Risk Assessment Area Level 1

Level 2

Risk Rank

Comments

COMMERCIAL RISK Supplier Factors

6

Marginal

Too soon

-Late delivery of hardware

9

High

The possibility is too high

-Instability of hardware

8

High

During installation of hardware and software might not compatible with each other.

-Changes in environment such as hardware platforms

7

Marginal

Possible

External Risk The likelihood that the event will occur - Estimate probability that event will occur

1

Too soon

Risk probability (percentage)

1

Too soon

*Risk ranking 0 to 10, 10 assumed as highest/*Probability is rated as critical, High, Marginal and negligible.

18

Page


RISK ASSESSMENT & RISK REGISTER

Risk Record Risk ID

R01

Risk Title

Software Crash & Failure

Owner

XYZ

Date Raised

December 2013

Status

Critical

Risk Description Technical risk appears when the application, techniques, theories and principles failed to generate the required software. In the ATM software development many external, unfamiliar interfaces and software involved with the different platform from the various banks and the ATM software has to work together in order to establish the communication between the bank and ATM. In many ATM network projects, the more challenges and efficiency required without any compromises in terms of skills, language experience and planning. The application failure most common factor in this kind of development. It is extremely difficult to work with different software, system languages and processes with the new technology like C++ with the DOT NET. In this environment, providing the accuracy and stability that will be required in order the expected tasks by customers to be completed successfully. Compatibility factor may emerge the failure of the final software application that ended with the software crash and become challenging at certain complex individual cases. Impact Description: The security impact a lot on the image of the software provider because the stockholder expectation into more quality standard and capabilities. Therefore, considering that a tiny defect may cause some inconsistency. Recommended Risk mitigation: The approach to control technical risks is to manage them in the entire software development process. This can result in more successful software programs and reduce the major crash risk. Focus on the development and risk monitoring through the testing only the resolution. Last, The management concentrates on capable and expertise resources in the development process and includes the risk specialist in the team.

Portability / Impact Values Portability

Impact Cost

Duration

Quantity

Pre mitigation

Less costly

15 to 30 days

2

Post Mitigation

Costly

Unexpected time

More than expected

Incident Action History Date

Incident / Action Progress

5.10

Actor Management

Outcome / Comments Suggested action plan

Risk Reduction

19



The technical criteria, the proper communication between the different systems.



The important issues are the security and privacy issues. The privacy of user activity, their essential information and money transactions must secure. All the safety measures must be applied.



The compatibility issues of the new system developer may occur.



The testing becomes easier during the development phase, the short and understandable coding best approach to fix the error.

Page


RRL 

RE before  RE after risk reduction cost

10.16= $2000000- $1820800 = $179200

5.11



Based on Paying RRL calculation I Estimated and included expenses on paying salaries to reduce risk of losing key personnel, i.e. Software Quality & Risk Analysis, and Final checks and verification on Risk Reduction. Therefore RE before = $2 million, RE after =$1810800, reduction cost = $179200, calculated 10.16.



According to the calculation of Risk leverage greater than 1.00, attractive propositions.

Hazard Prevention The idea behind is that IT manager has to prepare the backup plan, security plan and backup of man power. He should prepared staff for the alternative with the motivation and communication, along with the interviews frequently.

5.12

Likelihood reduction Higher experts or train existing staff, compatibility in the software development, work hard to meet the time schedule both start and end time. Meeting budgeted expenses and /or inadequate funds, cost escalation due to variance from estimate, i.e. LOC 48k, 800 per month for each programmer and 400 pounds per day.

5.13

Quality Check The import quality is to provide the privacy and security of the sensitive private data. The quality characteristic combine’s 1.

Customers' service quality

2.

Automated systems quality

3.

Banking product quality

If we provide the best system, but lack of security, will be a huge loss for the company's fame, customer reliability. Conclusion: Overall in IT Project management, if the risks are not meeting the deliverable criteria, key milestones, budget constraints, or any other aspect of the project may identify as a key success criteria by the stakeholders of each project phase.

6

CRITICAL ANALYSIS EARLY FINISHED PROJECT The project is dependent on other sub-projects, and no specific cost advantage can be grabbed to complete the project sooner than the deadline, as a result crashing will not be under consideration. However, crashing the project using an established crashing process might end up with the negotiation in the cost and timing. Overall due to the schedule bound and cost consideration the project crashing and rescheduling for the reduced time will may indication of the big loss in terms of cost and reputation.

20

Page


7

TEST PLAN BASED ON IEEE 829 STANDERED

Test Plan Identifier: MTP-01-01-14-1.0 7.1 7.1.1

Introduction Objective We have created the Master Test Plan for the ATM Simulation project introducing the first version followed by IEEE 829 recommended standards. The version should use the computer’s monitor to simulate the ATM screen and the computer keyboard to simulate the ATM keypad. This proposal will discuss only dedicated item that is directly associated with the ATM transaction method, both directly and indirectly pretentious parts will be discussed. The scope of this strategy is to make sure that the ATM provides the authenticated and accurate information from the bank and offer a secured transaction to the existing customer using an ATM card.

7.1.2

Scope The test scope mainly works on unit, system and acceptance testing. The approach section will address the details for each level and will further these levels will define specific strategies. The projected time is for an ATM project is pushy; for example, any postponements in the development or delay in the delivery of hardware might face significant impact on the test plan.

7.2

Test Item The following list of the items to need be tested: 

7.3

Requirements specification o

Specific requirement

o

Non functional requirement

o

Functional requirement



Classes



Program files



Interfaces



Functions

Features to Test 



21

Data flows o

Use-Cases

o

State diagrams

o

Activity diagram

o

Sequence diagrams

Functions

Page

o

Withdraw cash

o

Balance inquiries

o

Transactions

o

Deposit

o

Sessions

o

Operator panel / key operated switch

o

Screen




7.4

7.5 7.5.1

o

Keypad

o

Cash dispenser

o

Deposit slot

o

Messages

o

Slot reader

o

Logs

Interfaces o

The screen that displays a message to the user

o

A keypad that receives numeric input from the user

o

Cash dispenser that dispenses cash to the user

o

Deposit slot that receives envelop from the customer

o

Key operation switches to allow operator to start and stop the machine

Features Not To Test 

Hardware components



Bank Integration software with the ATM hardware



Bank database Security

Refinement Approach Testing levels The testing for the ATM simulation project will consist of apparent, unit, system and acceptance test levels will completed by the test specialist and the development team participation. Unit Testing performed by the testers includes list of cases, tester output and bug information must be provided before unit testing will be accepted and passed. System Testing: The Ellipse best suitable testing tool is acceptable for this project. The criteria say that the two major defects can be avoidable; provided as they do not obstruct testing of the program. The entire system test will be completed by the Testers in order to provide acceptance document to the team management. Acceptance Testing will completed by the ATM stockholder in order to confirm the system achieved its requirements. The programs Acceptance test will complete when all the major defects will be corrected, the critical and foremost defects must be corrected and verified by the stockholder. This will require careful coordination of the control table for the manufacturing system to avoid post testing into the system.

7.5.2

Configuration & Change Control The configuration and change control will look into the movement of programs, from the development portion of the ‘RED’ sign system to the test portion of the ‘RED’ sign. This will ensure that program under development/test and in the same version controls and tracking of changes. The exact process will use to migrate the programs from the development/test ‘RED’ system to the production ‘BLUE’ system once all testing has been completed as per plans and guidelines. All changes, enhancements and other modification requests to the system will be handled through the published change control procedures. Any modifications to the standard procedures are identified in the change control section.

22

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ 7.5.3

Testing Tools

7.5.4

Meetings The test specialist will conduct a meeting with the developer and project leader regularly to evaluate progress to date and to identify error trends and problems as early as possible. Otherwise meetings can be called for any urgency.

7.5.5

Measures and Metrics The following below descriptions will be collected by the development team during the Unit testing process. This constraint or information will forward to the test specialists at the time of handover of the testing, provided by the project team on a biweekly basis. 

Withdrawal not allowed between 2.00 a.m. and 4.00 a.m. for the maintenance purpose.



The computer will OFF during operation.



The deposit will not allow between 2.00 am to 4.00 am.



Balance display will not allow between 2.00 am to 4.00 am.



Session duration has only some limits.



300 daily withdrawal limit per card is enforced.



Cannot turn the ATM off while in the middle of a customer session



The new customer transactions cannot start unless the card not removed.



The requirement follows the waterfall architecture.



Hardware unavailable

The following information will be gathered from the test specialist during all testing phases.

7.6



All the model and severity defects.



The defect source such as design, code and requirement



Calculated time spent for any major & critical bug investigation.



Total number of times a program submitted to test specialist.



Defects found at advance level that should have been caught at lower levels of testing.

Testing Task (test identifier) 

Account Information



23

Page

o

TC0.. – Machine is accepting ATM Card

o

TC0.. – Machine is rejecting expired Card

o

TC0.. – Successful entry of PIN Number

o

TC0.. – Operation Failed due to enter PIN more than 3 attempts

o

TC0.. – Successful selection of account type

o

TC0.. – Failure due to invalid account type

o

TC0.. – Bank communicate properly with the bank

o

TC0.. – Concurrent access to the same account correctly

Transactions, Session & Logs o

TC0.. – System Allow multiple transactions.

o

TC0.. – Check the customer and Transaction information logged












o

TC0.. – Session completed correctly when the customer finish or cancel the transaction.

o

TC0.. – The system performs valid transaction for deposit correctly

Withdrawal o

TC0.. – Successful selection amount to withdraw

o

TC0.. – Successfully withdraw

o

TC0.. – Expected messages due to amount greater than day withdrawal limit

o

TC0.. – Expected message to withdraw due to selection amount greater than the account balance.

o

TC0.. – Withdrawal operation unsuccessful due to selection cancels option.

Deposit o

TC0.. – Unsuccessful withdraw due to lack of amount in the dispenser

o

TC0.. – System Accept Cash Amount entered by Customer to deposit

o

TC0.. – Depots Transaction cancels by the customer any time before the envelop insert in the slot.

o

TC0.. – Get a receipt after deposit envelope.

Checking Balance o

TC0.. – Balance check against valid account

o

TC0.. – Get receipt after the balance check

ATM Operation o

TC0.. – ATM Operator function Testing (Switch ON /OFF)

o

TC0.. – Connection between banks and ATM is established

o

TC14 – Bank connection terminated when the ATM shut down

User Interface o

TC0.. – Screens visual have proper format and text

o

TC0.. – Check Welcome screen display after insert the card

o

TC0.. – Buttons correspond to proper items on screen

o

TC0.. – Keypad entries are properly displayed

o

TC0.. – Can backspace to delete entries

Note: TC0.. (Dot denotes as the number given by the tester to complete the test specification number) 7.7

Fail & Pass Slandered The test method will completed once the initial set of stockholder have successfully sent and reassigned to the team leader to complete the failure task. In the test completion process the initial set of providers must pass the data comparison test, the application is considered live till the end of this process. All additional activations will be ready, if the stockholder is ready and their data is verified.

24



All withdraw cash tests must pass



90% of check account balance must pass.



All deposits must pass

Page


7.9

Suspension Criteria 

Interface not ready on time



Software delay



Staff Unavailable, long and unexpected

Resumption Criteria The overall testing accomplished with the reasonable amounts of data, which can only be derived from actual program from the software set.

7.10

Schedule The schedule for each activity is allocated to the project. The team is required for each procedure in the project timeline and project plan. The entire team group will be handled by the project leader in conjunction with the development and test specialist.

7.11



Assessment of requirements document and initial creation of classes, sub-classes and objectives of test personnel.



Development of Master test plan for at least two reviews of plan within the time allocated.



Revised the System design document by test personnel that provide to the team with an understanding of the application structure.



Development of a System and acceptance test plans with time allocated for minimum two reviews of the plans by the test specialist and other essential personnel.



Unit test time allocation.



Allocated time for the system and acceptance test cycle.

Test Deliverables

25



Acceptance test plan



System test plan



Unit test plans / turnover documentation



Screen patterns



Report mock-ups



Defect / incident reports and summaries



Test logs and turnover reports

Page


8

BLACK BOX TEST Reference No: BBT-14-01-14-1-1.0 Black box or functional testing is used to test apparently system’s functionality without knowing its inner detail, a method of test design and applicable to all levels of software testing, functional testing, integration and unit testing. Black box testing focuses on the quality of the system. These tests are reusable after making changes conform changes.

Input

Output Black Box Testing

Black box testing strategies are discussing about the functional point of view. The numbers of the following types of the tests are available.

8.1



Equivalence Partitioning



Boundary Value Analysis Based Testing



State Transition Testing



Decision tables



Error Guessing



Use case testing

Test Case Specification for ATM withdrawal System Test Case Identifier: TCI-01-01-14-1.0

8.1.1

Purpose This ATM test case based on functionality of withdrawal, all the required tests will be done without its code specification. The test recognizes its functionality based on requirements. I choose below Use-Case specification because it is reliable, easy to use and accepted widely in all the major system test requirements.

8.1.2

Test case specification identifier for the withdrawal operation Test Code

Test Case Specification

TC001

Inquiry, Balance $80

TC002

Withdraw $20 from a valid account, check with $80

TC003


TC004


TC005


TC006


TC007


TC008


TC009


TC010


TC011


TC012


26

Page


8.1.3

TC013


TC014


TC015

Inquiry, Account 1 Checking

TC016

Inquiry, Account 2 Saving

TC017

Inquiry, Account 3 Money Market (Invalid Account Check)

TC018

Invalid Card with

TC019

Invalid PIN

Test items



A customer must able to withdraw from any suitable account linked to the card, in multiples of $20.00. This approval must be obtained from the bank before cash is dispensed.



A customer must check its own account; the other accounts must invalidate the transaction.



A customer required to withdraw less than or equal to its account balance.



A customer must withdraw limited amount daily.



The customer may check its balance to confirm the total account balance before the withdrawal.



Software code: Withdrawal ()

8.1.4

Input / Output or Results specifications The following below list expected to use as input in order to collect results from the ATM simulation testing. Condition: Inserted, 20 entries. TEST SPECIFICATION

INPUT

OUTPUT

Balance Enquiry

Checking

Success, Balance Enquiry: CARD# 1 TRANS# 1, TOTAL BAL: $100.00

20

WITHDRAW CARD# 1 TRANS# 2 FROM 0 NO TO $20.00, SUCCESS, Dispensed: $20.00, TOTAL BAL: $80.00

Withdraw Checking

money

From

Account

Checking 40 Checking 60 Checking

20

Eject and reenter same card

Checking Withdraw money For Account Saving

20 Saving

Withdraw Checking

27

Page

money

From

Account

20 Checking

Success, Message: WITHDRAW CARD# 1 TRANS# 3 FROM 0 NO TO $40.00, Dispensed: $40.00, TOTAL BAL: $40.00 Message: WITHDRAW CARD# 1 TRANS# 4 FROM 0 NO TO $60.00, Response: FAILURE Insufficient available balance Success, Message: WITHDRAW CARD# 1 TRANS# 5 FROM 0 NO TO $20.00, Dispensed: $20.00, TOTAL BAL: $20.00 Success, WITHDRAW CARD# 1 TRANS# 5 FROM 1 NO TO $20.00, TOTAL BAL: $980.00 Success, WITHDRAW CARD# 1 TRANS# 6 FROM 0 NO TO $20.00, TOTAL BAL: $0.00

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ Withdraw money For Account Saving

200 Saving

Eject and Reentered Card

40 Checking


100 Saving

40 Saving

200 Saving


40 Saving

Inquiry

Withdrawal Account Invalid Account

Message: WITHDRAW CARD# 1 TRANS# 7 FROM 1 NO TO $200.00, Response: FAILURE Daily withdrawal limit exceeded WITHDRAW CARD# 1 TRANS# 9 FROM 0 NO TO $20.00, FAILURE Insufficient available balance, TOTAL BAL: $0.00 Message: WITHDRAW CARD# 1 TRANS# 13 FROM 1 NO TO $100.00, Response: SUCCESS, Dispensed: $100.00, TOTAL BAL: $880.00 Message: WITHDRAW CARD# 1 TRANS# 15 FROM 1 NO TO $40.00, Response: SUCCESS, Dispensed: $40.00, TOTAL BAL: $840.00 Message: WITHDRAW CARD# 1 TRANS# 16 FROM 1 NO TO $200.00, Response: FAILURE Daily withdrawal limit exceeded Message: WITHDRAW CARD# 1 TRANS# 17 FROM 1 NO TO $40.00, Response: SUCCESS, Dispensed: $40.00, TOTAL BAL: $800.00

1Checking

Message: INQUIRY CARD# 1 TRANS# 18 FROM 0 NO TO NO AMOUNT, Response: SUCCESS, TOTAL BAL: $0.00

2- Saving

Message: INQUIRY CARD# 1 TRANS# 20 FROM 1 NO TO NO AMOUNT, Response: SUCCESS, TOTAL BAL: $800.00

3- Money Market

Message: WITHDRAW CARD# 1 TRANS# 21 FROM 2 NO TO $60.00, Response: FAILURE Invalid account type

Insert Invalid Card

WITHDRAW CARD# 4 TRANS# 22 FROM 0 NO TO $20.00, Response: FAILURE Invalid card

Insert Invalid PIN

WITHDRAW CARD# 1 TRANS# 23 FROM 0 NO TO $20.00 Response: INVALID PIN Retained Card

8.1.5  8.1.6

Environmental needs GetAccountBalance (), SetAccountBalance (), Withdrawal () Special procedural requirements



Convert pounds into pence

8.1.7

Inter-case dependencies



Test data load 28

Page


Java runtime environment



Installation of Ellipse

8.2

Black Box Technique

The black box testing has various testing types, but as discussed, our selected Use Case test manual based on test case specification above. 8.2.1

Use Cases Testing Main Scenario

Step

Description

S: System

1

A: Insert Card

A: Actor

2

S: Ask PIN

3

A: Enter PIN

4

S: Allow Access to Account

5

S: Ask for TT with 4 Options

AT: Account Type TT: Transaction Type

1-Withdrawal 2-Deposit 3-Transfer 4-Balance 6

A: Input 4

7

S: Ask AT options 1-2-3 1-Checking 2-Saving 3-Money Market

8

A: Input 1

9

S: Display Balance and Dispatch Receipt S: Ask More Transaction (1-2) 1- Yes 2- No

8a

A: Inputs 1

5a

S: Repeat Step 5

8b

A: Input 1

10

S: Display menu withdraws with options 1-5 1-20 2-40 3-60 4-100 5-200

29

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ 12

A: chooses options and perform Transaction

13

S: 3 Transaction Failed A: Eject Card and Reentered card

5b

Step Repeat 1 to 5

8c

A: Perform Transaction for both the account

15

S: Exceed Daily Withdraw Limit

13a

A: Eject Card and Reentered card

5c

Step Repeat 1 to 5

8d

A: Perform Transaction for both the account

15a

S: Exceed Daily Withdraw Limit

16

A: inquiry for both Account A: Access Invalid account

17

S: Invalid Account

9a

S: Ask More Transaction (1-2) 1- Yes 2- No

18

A: Input 2

19

S: Eject Card

1a

Insert Card

5d

S: Ask More Transaction (1-2) 1- Yes 2- No

8e

A: Input 1

7a

S: Ask AT options 1-2-3 1-Checking 2-Saving 3-Money Market

20

S: Invalid Card S: Wait For Another Transaction

21

Repeat Step 1-7 S: Invalid PIN S: Message and ask Reenter PIN

21a

S: Invalid 3 times S: Retained Card

30

Page


8.4

Identify Specific Errors 

The invalid card confirmation notified when a customer entered selected amount into the withdrawal procedure. In real ATM system, the invalid card recognition detects after the PIN entered by the customer and in response the card eject by the system immediately.



Invalid PIN verified after the customer entered account type which is not normal. The Invalid PIN has to reject in the beginning. The ATM simulation asks unnecessary inputs and message to the customer after 7 steps performed by the customer.



The Timeout function hasn't been used in the system, the ATM machine has no time limit to cancel the session during the transaction process, as a result the ATM, wait for unlimited time, even it stays remain more than the limits unless customer respond the next transaction or hit cancel transition option. Results:

The test specification enclosed almost all the requirement for the withdrawal system. In our test I created charts and filled one by one all our results in response during our tests. As above I discussed many weaknesses in the simulation that are showing unexpected results, but on the other hand it was responding accurately for the major requirement.

31

Page


8.4.1 JUnit Test Case For Money.Java Reference No: JUT-14-01-14-1-1.1 8.5

Money.java Testing Coding: package nas.atmtest; import static org.junit.Assert.*; import banking.*; import org.junit.Test;

public class ATMMoneyTest { public boolean bl; public String str; public Money mn,availBal,totBal,money,result; public Balances bal; @Test

public void TestMoney()throws Exception {

availBal =new Money(80); totBal=new Money(80);

//copy constructor

bal=new Balances(); bal.setBalances(availBal, totBal); mn=new Money(availBal); mn.getClass(); mn.hashCode(); if (mn.lessEqual(availBal) && mn.lessEqual(totBal)) {

money=new Money(20); //constructor cent and dollar part result =new Money(60); mn.subtract(money); assertEquals( "Result",result.toString(),mn.toString()); } { money=new Money(20,12); //constructor dollar result =new Money(80,12); mn.add(money); assertEquals( "Result",result.toString(),mn.toString());

32

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ }

} } 8.5.1

Result: I compared the automatically generated result of the system from the Money type object and the result generated manually in the coding and the result was matching. The Result found 100% accepted without failure and error. The following attached screenshot for the result.

8.6

Message Testing Coding

package nas.atmtest;

import static org.junit.Assert.*; import banking.*; import org.junit.Test; public class ATMMessageTest { private

boolean bl;

private

String str;

private Integer int1,int2,int3,int4,int5; public Money mon,mn;

33

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ Card crd,getcrd; Message msg ; @Test public void testMessage()throws Exception { Money money=new Money(20) ; mon=new Money(money); crd= new Card(1); msg =new Message(0, crd, 42, 1, 1, 0,money); bl=msg.equals(money); int1=msg.getFromAccount(); int2=msg.getPIN(); int3=msg.getToAccount(); mon=msg.getAmount(); msg.equals(money); getcrd=msg.getCard();

//not responding

msg.setPIN(0); int4=msg.getSerialNumber(); int5=msg.getMessageCode(); str=""; switch (msg.getMessageCode()) { case 0: msg =new Message(0, crd, 42, 1, 1, 0,money); //str += "WITHDRAW"; case 1: msg =new Message(1, crd, 42, 1, 1, 0,money); //str += "INIT_DEP"; case 2: msg =new Message(2, crd, 42, 1, 1, 0,money); // str += "COMP_DEP"; case 3: msg =new Message(3, crd, 42, 1, 1, 0,money); //str += "TRANSFER"; case 4: msg =new Message(4, crd, 42, 1, 1, 0,money); str += "INQUIRY "; } str += " CARD# " + crd.getNumber(); str += " TRANS# " + int4; if (int1>=0) str += " FROM

34

Page

" + int1;

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ else str += " NO FROM"; if (int3 >= 0) str += " TO

" + int3;

else str += " NO TO"; if (! mon.lessEqual(new Money(0))) str += " " + money; else str += " NO AMOUNT"; assertEquals("Result",msg.toString(),str); } }

8.6.1

Result:

Successful result found in the Message testing using assertEquals function, following are the result short screen.

9

CODE COVERAGE

For the code coverage we used EclEmma for the Eclipse tool. Code coverage is a white box testing procedure that requires knowledge to access the code rather than simply using the interface. Code coverage, perhaps most useful during the module testing phase, though it has also benefited during integration testing, but depends absolutely on how and what you are testing. 9.1

Classes for the Test: 

Message.java 35

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________  9.2

9.3

Money.java Created Test Classes:



ATMMoneyTest.java



ATMMessageTest.java Result:

Here we run the ATMMoneyTest.java test in code coverage and found 100% coverage. I found that lexical function has not coverage, 100% due to the function coding itself, showing errors in the Money.java class as below can be viewed on the screen shortly

36

Page


9.4

The Message Test Coverage:

In the Message coverage we spend maximum time and changed many codes, finally we decided the final coding with a maximum 89 %. The Message just chooses the message card for the Message parameters and accordingly displays messages. The percentage coverage is not 100% because of conditions, these conditions are based on the requirement and it would not possible to satisfy all in one.

37

Page


10 FORMAL TESTING METHODCORN Reference No: FTM-14-01-14-1-1.0 In software development system the validation and verification recognized as vital activities and testing plays an important role for these two. They are valuable and use in early stage in the development process, error finding during the specification and design fees are much cheaper than later in the development process. The formal methods included any activities that are based on mathematical representations of software and dependent on formal specification. Formal methods can use at every stage of the system development process which helps to write a precise specification of the system, using verification of the specification reliability and implementation satisfied its specification. Formal = mathematical Methods = structure approach, strategy Using mathematics in a structured way to analysis and describe a problem 10.1 Promise of Formal Method Every aspect has its advantages and disadvantages, these two marks can find in the various technologies. Likewise Formal method has the same attitude of advantages and disadvantages. Moreover a formal method has the following promises, but keeping the following weakness: 

It discovers ambiguity, incompleteness, and inconsistency in the software.



Offers defect-free software, which may have cost effective.



Incrementally grows ineffective solution after each iteration



This model does not involve high complexity rate.



Formal specification language semantics verify self-consistency.

Its Weakness 

Time consuming and expensive



Difficult to use this model as a communication mechanism for non-technical personnel



Extensive training is required since only a few developers have the essential knowledge to implement this model; those have mastered in the mathematical approach.

10.2 Categories of Formal methods 

Abstract State Machines - The Abstract State Machine (ASM) thesis implies that any algorithm can be modeled by an appropriate ASM.



B-Method - method for the development of program code from a specification in the Abstract Machine Notation.



Z – A specification language used for describing computer-based systems; based set theory and first order predicate logic



Unified Modeling Language (UML) provides system architects with one consistent language for specifying, visualizing, constructing, and documenting the artifacts of software systems.



38

o

Visual notation for OO modeling

o

Extensible

o

Independent of programming languages

o

The formal basis for understanding the modeling language

Others types include:

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ o

Community

o

Estelle

o

Esterel

o

Lotus

o

Overture Modeling Language

o

Petri Nets

o

RAISE

o

SDL

o

TRIO, Unity, and VDM

o

Any programming language

10.3 Proposed Method for the Testing Based on above study, we would propose Unified Modeling Language for the ATM PIN testing. This approach is new in the technology with its various qualities, such as it is easy to understand and implement; moreover eliminate the complexity by using Java behavior. Due to its natural supportive design, the Unified language allowing specifications to be written in the form of preconditions, post conditions, class invariants, and an abstract model of an object’s state. The main contribution of JML-Unit testing is to eliminate the writing codes that decide the success and failure of the testing on hand. Moreover the JML-Unit detects a test failure when a post condition is violated after the method under test is called, or when a precondition violation occurs during execution of the method. The test will be meaningless if the test violated in the precondition before execution, but JML tell us whether the method is behaving correctly or not timely. Furthermore JML Unit provided the reusability that relaxing more writing and giving abstract and robust method to test. JML Is Java + FO Logic + pre/post-conditions, invariants + more. . .

The other most important reason to select this technique is to escape from the high cost estimation and extra resources. As we have Java specialist in the team to understand the language during the development process, test group can utilize his expertise in finding the bugs even during coding. In this way we can gather the various ideas and include other team members to find the bugs that help the tester with elimination of errors during implementation.

Formal Specification Methods

Formal

Formal

Formal

Proofs

Checking

Abstraction

Specifications

10.4 Very informal Specification of enterPIN (int pin) Enter the PIN that belongs to the current bank card inserted into the ATM Card reader. If a wrong PIN is entered three times in a row, the card retained. The customer is considered as authenticated user from the bank, only after entering a valid PIN number by the customer.

39

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ 10.5 Method Proposed The proposed method below is an essential requirement for the PIN testing based on the requirement specification for the ATM system. It could more refine and more precise if considered to be implemented. @ public normalBehavior @ requires insertCard != null; @ requires !UserAuthenticated; @ requires PIN!= insertCard.ValidPIN; @ requires wrongPINCounter >= 2; @ ensures insertCard == null; @ ensures \old(insertCard).invalid; @ ensures UserAuthenticated == \old(UserAuthenticated); @ ensures wrongPINCounter == \old(wrongPINCounter); @*/ public void enterPIN (int PIN) {} 



In precondition: preconditions are boolean JAVA expressions o

Marked by requires

o

!UserAuthenticated

o

pin == insertCard.correctPIN

o

wrongPINCounter >= 2;

In post condition: is boolean JAVA expressions Specification case has two post condition (marked by ensures)



o

\old(insertCard).invalid

o

Ensures UserAuthenticated == \old(UserAuthenticated)

o

Ensures wrongPINCounter == \old(wrongPINCounter);

o

insertdCard == null

Normal behavior Specification Case o

40

Page

The method guaranteed not to trigger any exception


11 CRITICAL ANALYSIS SUMMERY AND DISCUSSION 11.1 Task 5: The Black box testing has a great experience. Testing obvious a great challenge and precise of the specialists. We study the material and understand the technique, then moved on the various techniques for the Black Box Testing for the withdrawal operation. The followings are the explanations to choose Use Case: Equivalent Partitioning: The technique is to derive the subsets from main sets. The drawback of this technique is that the negative bounding values could not be exercised. It is sometimes difficult to identify and partition classes that contain values which will uncover defects downstream in a complex network of interrelated path. Boundary Value Analysis: The Technique is used for finding the error in the boundary area. Because there is a chance the developer missed out. The main disadvantage of the BVA is Programs with too many types of inputs. It cannot test all combinations of inputs and therefore cannot identify problems resulting from unexpected relationships between input types. State Transition Testing: Their biggest limitation is that they are not good at describing behavior that involved several objects. In these cases use an interaction diagram or an activity diagram. Decision tables: Decision tables do not scale up well. We need to "factor" large tables into smaller ones to remove redundancy. Error Guessing: There are no specific tools and techniques for this, but we can write test cases depending on the situation which are documented requirements and also those requirements that are not documented. So this technique not suitable for the large network testing where assumptions and guessing may fail. Use case testing: The purpose of this kind of testing is to check the apparent requirements of functional specifications. Because the ATM simulation system based on functional and nonfunctional requirements and the Use case reference to the source of information used in test case designing, without caring its functional or nonfunctional program attributes. The Use case helps to identify the test case that implemented on the whole transaction from start to end and reaches to the end user requirement and stakeholder. Functional specification=description of intended behavior (Formal or informal) The black box testing has various testing types, but we have to select Use Case testing that suitable for the withdrawal function. Looking back to the requirement for the withdrawal function and finding all the minor or major test condition is challenging. The test has covered all the best possible expectations. We found the Use case that describes the process flow by using actors, not using system, based on its most likely use that needs only functional approach for the withdrawal system. The withdrawal system in ATM system is the most important and major activity having lot functional requirements, therefore use case will help to identify the minor or major missing approaches. Test Experience In the first section that required writing a test case specification based on IEEE slandered. We started with the requirements and created the test case specification identifiers for each test case that recognize throughout the development period. We created an expected test items list that reflects the requirement of the system. The specification discussed various related leafs in this specification that help to understand the specification in detail. Although we noticed it is time consuming, but overall an easy exercise, having understandable language, a step by step procedure. During our testing with the withdrawal function, we received messages like ‘no more cash’ for the day, but once we ejected and reinserted the card than we found expected results. We guess this might be unavailability of the database and the process of re-initialization of the values. We started with the balance inquiry to make sure we have enough amount and then accordingly we tested, the test went through all its valid accounts, tested up to zero. Some blunt and abruptly testing done to check the functionality and found expected results like withdraw greater amount, withdraw even no amount available, withdraw from invalid account, withdraw the highest amount even this amount available in the account, withdrawal limits for the day etc. In the Use case, manual testing, We tested withdrawal and found expected results based on testing specification. As our analysis the Use case testing covered apparent withdrawal functionality without knowing its inner detail. 41

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ The Use Case it is very easy to use that using common language without caring typical inner coding that could be understandable by anyone or ATM stockholder even, as a result the withdrawal functional defects or hidden requirements can be found easily by this testing and stockholder will verify. 11.2 Task 6: We selected Ellipses for the JUnit Testing. We created the environment in the Ellipse and write 2 test codes using separate folder advised in the LAB. These test codes are dedicated to the respective classes, called each function in the test code and run the test environment successfully. During our testing, we found that few functions are not responding and throwing errors whenever calling them, but the rest of the functions called and responded properly. The Message class has many multiple calls from one construction. This construction works for all other messages such as withdraw, deposit, balance and other messages too. This Message class has many functions to test that required to get the various values passed in the constructor. For example getCard(), getPIN() etc. We used a switch statement for the various construction calls for the different requirement. Finally, we tested result in the assurtEquals () function. For the expected result, we disable few coding, if you noticed, but this will not affect the testing because the purpose of testing to test all the function working as per requirement. Similar purposely we haven’t used break statement in each case because we want to move cursor in each case to hit all the transactions. We found sometime Message functions are not responding, but sometimes responding well. We called other class objects to pass the parameter in the message construction like Card class. We have tried to create the test environment, but bound with some partially completed functions such as notifying and wait, truly they are not required as such, but they are inherited functions in the Money.java class, as a result we tested all the functions declared in the Money.java. The result throws no error and found none of any other failure. The test went through logics to test the requirements of the system. The main intention of the test plan was to test withdrawal and deposit of an amount. These two functions are entirely different process required different environment. The Money.java class has three constructors, one is for withdrawal and second is for the deposit amount, last is to copy constructors. We called all constructors in order to test them. To start, we called other class operations i.e. balance to set the total and available balance to the environment, although it is not required but we tried to neutralize our test environment. So the coding started with calling packages, declaration and initialization of the object. The avialableBal and Total Balance is a Money type that set the initial amount in the balance class also these objects comparing the amount availability before withdrawal amount. If the lessEqual() function return true that means the available balance and total balance greater than the withdrawal amount, then the subtraction function will activate for the withdrawal.we declared result object ‘Money’ type to check the expected result in the assertEqual function which required both the parameter object type as same. Last we called mn.subtract(money) function to subtract the given amount and tested expected result in the assertEqual function. To test the add() function not required any condition to check, but required the constructor for dollar and cent as per requirement stated that deposit money essentially calculates the cents procedure for the test, therefore simply called this function with the given expected result. In the code coverage we used EclEmma tools, experienced an easy to install and adoptable. When we run coverage code we found the best results more than 88% to 100% presently. The coverage actually indicates your coding perfection. When we used code coverage, we realized that we are missing coding and this realization helped me to do the correction in our test coding, and covered almost functions. 11.3 Task 7: The formal technique based on mathematics and formal logic, a foundation of most descriptions of complex systems. It defines external behavior without describing implementation using logical and structural division. The formal technique identified undocumented or unexpected assumptions and clarify the in the high level designs. On the other hand the PIN verification system in the ATM is a critical approach that must satisfy the bank requirement authentication. This Pin verification must accurate and exact in its approach, therefore the formal method will identify the unexpected bugs in the PIN verification process. We selected JML Unit testing for the PIN verification that generated automatically JUnit test case. We do not require much experience in Java, and this tool cooperated in general and creates the formal method for the testing. This method is based on mathematical approach that exactly works on the critical issues. Our preference for JML Unit formal method for the PIN will provide the unexpected approach towards finding error and bugs in pre and post condition, the detection of unclear and hidden bugs for such a complex system would help to build a bug free 42

Page

Automation Teller Machine (XYZ-ATM) ______________________________________________________________________________________ and secured system. Although this method has a precondition for selecting test inputs and post conditions provides the properties to check the test results approach will identify the bugs in the PIN function. In the proposed section we created the PIN test code to give a better idea in the selection.

43

Page


APPENDIX A - GLOSSERY 

Coley Consulting (2009) IEEE 829 Documentation. http://www.coleyconsulting.co.uk/IEEE829.htm.



IEEE Xplore (2009) IEEE 829-1988 Standard for Software Test Documentation. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&isnumber=16010&arnumber=741968&punumber=5976



Software Engineering Technical Committee of the IEEE Computer Society, USA (1998) IEEE 829-1988 Standard for Software Test Documentation. 0-7381-1443-X



The course slides consider as references through the report.



Software Engineering using Formal Methods Java Modeling Language by Wolfgang Ahrendt, Moa Johansson acceptance criteria



Acceptance testing - Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEEE-STD-610], Taxonomy-Based Risk Identification Marvin J. Carr



Project Cost Estimating Manual Fifth Edition March 2012

44

Page


APPENDIX- B

Organization Chart (General Description)

45

Page


A Finance Director

XYZ International Banking & Finance Services Group

B Deputy Director C Project Leader XYZ Management Team

A Requirement Analyst

Software Architect and Designer

B Requirement Analyst

A Front End ATM Designers and Programmers

F Front End ATM Designers and Programmers

C Requirement Analyst

B Front End ATM Designers and Programmers

G Front End ATM Designers and Programmers

D Requirement Analyst

C Front End ATM Designers and Programmers

H Front End ATM Designers and Programmers

D Front End ATM Designers and Programmers

I Front End ATM Designers and Programmers

E Front End ATM Designers and Programmers

J Front End ATM Designers and Programmers

Development Team

46

Page

A Software Testers

A Document Writer

B Software Testers

B Document Writer

A Training & Installation Specialist B Training & Installation Specialist

Business Analysts

Communication Expert

DB2 Expert

Security Specialist

Database Specialist

Java Programmer

Client / Server Interface Developer


APPENDIX- C

Work break down Structure

47

Page


48

Page


49

Page


50

Page


51

Page


52

Page


53

Page


54

Page


Project Planner in MS Project 2010 Sta rt Sla ck Lat e Fini sh

Lat e Sta rt

Earl y Fini sh

Earl y Sta rt

Cos t

Res our ce Gro up

Res our ce Na me s Pre dec ess ors

Page

Fini sh

Sta rt

Dur ati on

Tas k Na me

55


XYZ ATM System

0 days

Mon 12/9/13

Mon 12/9/13

£0.00

Mon 12/9/13

Mon 12/9/13

Wed 10/8/14

Wed 10/8/14

217 days


64 days

Mon 12/9/13

Thu 3/6/14

£540,800.00

Mon 12/9/13

Thu 3/6/14

Mon 12/9/13

Wed 3/12/14

0 days


20 days

Mon 12/9/13

Fri 1/3/14


Requirement Analysts

£64,000.00

Mon 12/9/13

Fri 1/3/14

Mon 12/9/13

Fri 1/3/14

0 days

12 days

Mon 12/9/13

Tue 12/24/13

Communication Expert[200%]

Communications Expert

£76,800.00

Mon 12/9/13

Tue 12/24/13

Fri 1/3/14

Mon 1/20/14

19 days


14 days

Mon 12/9/13

Thu 12/26/13



£44,800.00

Mon 12/9/13

Thu 12/26/13

Tue 1/14/14

Fri 1/31/14

26 days


14 days

Fri 12/27/13

Wed 1/15/14

5

Business Analyst,DB2 Expert

Business Analyst,DB2 Expert

£89,600.00

Fri 12/27/13

Wed 1/15/14

Mon 2/3/14

Thu 2/20/14

26 days


11 days

Wed 12/25/13

Wed 1/8/14

4



£35,200.00

Wed 12/25/13

Wed 1/8/14

Tue 1/21/14

Tue 2/4/14

19 days


22 days

Mon 1/6/14

Tue 2/4/14

3

Security Specialist

Security Specialist

£70,400.00

Mon 1/6/14

Tue 2/4/14

Mon 1/6/14

Tue 2/4/14

0 days


14 days

Thu 1/16/14

Tue 2/4/14

6

Project Leader, Requirement Analysts-1

Management, Requirement Analysts

£89,600.00

Thu 1/16/14

Tue 2/4/14

Fri 2/21/14

Wed 3/12/14

26 days

Create Software Requirements Specification Report(SRS)

22 days

Wed 2/5/14

Thu 3/6/14

7,8



£70,400.00

Wed 2/5/14

Thu 3/6/14

Wed 2/5/14

Thu 3/6/14

0 days

System Designing

67 days

Wed 2/5/14

Thu 5/8/14

£339,200.00

Wed 2/5/14

Thu 5/8/14

Fri 3/7/14

Thu 5/8/14

22 days


21 days

Wed 2/5/14

Wed 3/5/14

9


Front End ATM as Designers

£67,200.00

Wed 2/5/14

Wed 3/5/14

Thu 3/13/14

Thu 4/10/14

26 days

Design Interfaces

21 days

Fri 3/7/14

Fri 4/4/14

10



£67,200.00

Fri 3/7/14

Fri 4/4/14

Fri 3/7/14

Fri 4/4/14

0 days

Develop

12

Thu 3/6/14

Fri 3/21/14

12

Software

Front End ATM

£38,400.00

Thu 3/6/14

Fri 3/21/14

Fri 4/11/14

Mon

26

Interview

56

Page


Algorithm

days

Architect-3

as Designers

13



12 days

Mon 4/7/14

Tue 4/22/14


8 days

Mon 3/24/14

Wed 4/2/14

14

Software Architect4,Software Architect-1


24 days

Mon 4/7/14

Thu 5/8/14

13


Coding

47 days

Fri 5/9/14

Mon 7/14/14

Create Test Data

19 days

Fri 5/9/14

Wed 6/4/14

Design Test Cases

Create Source Code

19 days

Fri 5/9/14

Wed 6/4/14

£38,400.00

Mon 4/7/14

Tue 4/22/14

Wed 4/23/14

Thu 5/8/14

12 days


£51,200.00

Mon 3/24/14

Wed 4/2/14

Tue 4/29/14

Thu 5/8/14

26 days


£76,800.00

Mon 4/7/14

Thu 5/8/14

Mon 4/7/14

Thu 5/8/14

0 days

£518,400.00

Fri 5/9/14

Mon 7/14/14

Fri 5/9/14

Mon 7/14/14

0 days

Database Specialist

Database Specialist

£60,800.00

Fri 5/9/14

Wed 6/4/14

Mon 5/26/14

Thu 6/19/14

11 days

17

Front-End Designer & Programmer5-6,FrontEnd Designer & Programmer5


£121,600.00

Fri 5/9/14

Wed 6/4/14

Mon 5/26/14

Thu 6/19/14

11 days

OOPS,Front End ATM as Designers

£192,000.00

Fri 5/9/14

Thu 6/19/14

Fri 5/9/14

Thu 6/19/14

0 days

Front End ATM as

£22,400.00

Fri 6/20/14

Mon 6/30/14

Fri 6/20/14

Mon 6/30/14

0 days


30 days

Fri 5/9/14

Thu 6/19/14

15,17,16

Plan Integration

7 days

Fri 6/20/14

Mon 6/30/14

20,21,19

Front-End Designer &

Page

days

17

Java Programmer, Front-End Designer & Programmer5-7

57

4/28/14


Programmer5-8

Perform integration

9 days

Tue 7/1/14

Fri 7/11/14

Designers

22

Front-End Designer & Programmer5-9,Java Programmer

Front End ATM as Designers, OOPS

£57,600.00

Tue 7/1/14

Fri 7/11/14

Wed 7/2/14

Mon 7/14/14

1 day

22

Front-End Designer & Programmer5-10,FrontEnd Designer & Programmer5


£64,000.00

Tue 7/1/14

Mon 7/14/14

Tue 7/1/14

Mon 7/14/14

0 days

£278,400.00

Tue 7/15/14

Mon 10/6/14

Tue 7/15/14

Mon 10/6/14

0 days


10 days

Tue 7/1/14

Mon 7/14/14

Testing

60 days

Tue 7/15/14

Mon 10/6/14

Develop Test Requirement

24 days

Tue 7/15/14

Fri 8/15/14

24,23

Software Testers-1

Software Testers

£76,800.00

Tue 7/15/14

Fri 8/15/14

Tue 7/15/14

Fri 8/15/14

0 days

Unit Testing

14 days

Mon 8/18/14

Thu 9/4/14

26

Software Testers-2

Software Testers

£44,800.00

Mon 8/18/14

Thu 9/4/14

Fri 8/29/14

Wed 9/17/14

9 days

Component Testing

22 days

Mon 8/18/14

Tue 9/16/14

26

Software Testers-1

Software Testers

£70,400.00

Mon 8/18/14

Tue 9/16/14

Mon 8/18/14

Tue 9/16/14

0 days

System Testing

13 days

Fri 9/5/14

Tue 9/23/14

27

Software Testers-2

Software Testers

£41,600.00

Fri 9/5/14

Tue 9/23/14

Thu 9/18/14

Mon 10/6/14

9 days


14 days

Wed 9/17/14

Mon 10/6/14

28

Software Testers-1

Software Testers

£44,800.00

Wed 9/17/14

Mon 10/6/14

Wed 9/17/14

Mon 10/6/14

0 days


50 days

Tue 10/7/14

Mon 12/15/14

£307,200.00

Tue 10/7/14

Mon 12/15/14

Tue 10/7/14

Mon 12/15/14

0 days

58

Page



28 days

Tue 10/7/14

Thu 11/13/14

£89,600.00

Tue 10/7/14

Thu 11/13/14

Tue 10/7/14

Thu 11/13/14

0 days

£108,800.00

Tue 10/7/14

Wed 10/29/14

Fri 10/31/14

Mon 11/24/14

18 days

Training and Installation Specialists.

£25,600.00

Tue 10/7/14

Thu 10/16/14

Thu 11/13/14

Mon 11/24/14

27 days

30,29

Project Leader

Management

30

Document Writer1,Document Writer-2

Document Writers

17 days

Tue 10/7/14

Wed 10/29/14

Training

8 days

Tue 10/7/14

Thu 10/16/14

30

Training & Installation Specialists1[0%]

Distribute Software

5 days

Fri 11/14/14

Thu 11/20/14

32,33,34



£16,000.00

Fri 11/14/14

Thu 11/20/14

Tue 11/25/14

Mon 12/1/14

7 days

Install Software

12 days

Fri 11/14/14

Mon 12/1/14

32



£38,400.00

Fri 11/14/14

Mon 12/1/14

Fri 11/14/14

Mon 12/1/14

0 days


9 days

Tue 12/2/14

Fri 12/12/14

36,35



£28,800.00

Tue 12/2/14

Fri 12/12/14

Tue 12/2/14

Fri 12/12/14

0 days


1 day

Mon 12/15/14

Mon 12/15/14

37

£0.00

Mon 12/15/14

Mon 12/15/14

Mon 12/15/14

Mon 12/15/14

0 days

Finish Task

0 days

Mon 12/15/14

Mon 12/15/14

38

£0.00

Mon 12/15/14

Mon 12/15/14

Mon 12/15/14

Mon 12/15/14

0 days


59

Page


Tracking Gantt chart

60

Page


61

Page


62

Page


Resource Usage

63

Page


64

Page


65

Page


66

Page


67

Page


68

Page


69

Page


70

Page


71

Page


72

Page


73

Page


74

Page


75

Page


76

Page


77

Page


78

Page


79

Page


80

Page


81

Page


82

Page


Bufget Cost Report

83

Page


84

Page


85

Page


86

Page


87

Page


88

Page


89

Page


90

Page


91

Page