Project Management, Software Testing: September 2015

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/281464117
Project Management, Software Testing
Research · September 2015

DOI: 10.13140/RG.2.1.4038.0642
CITATIONS READS
0 33,070
1 author:
Nasreen Ahmad
De Montfort University
17 PUBLICATIONS 1 CITATION
SEE PROFILE
All content following this page was uploaded by Nasreen Ahmad on 04 September 2015.
The user has requested enhancement of the downloaded file.

Automation Teller Machine (XYZ-ATM)
______________________________________________________________________________________
Project Management, Software Testing

Nasreen Iqbal
Msc. Software Engineering
P13194231@myemail.dmu.ac.uk
De Montfort University
1 INTRODUCTION
1.1 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:
 Budget
o 2 Million
o Should not exceed
 Time
o 12 Months
 Staff
o 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.
1.4 Schedule & Budget Details
 The project kick-off: 09 December, 2013
 Software ready for operation: 09 December, 2014
1.5 Project Promises
The following items listed are the deliverables to the ATM project manager.
 Software documentation
1 Page
______________________________________________________________________________________
o Installation documentation
o End-user detailed document
 Software installation
 Software training provided to the staff
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
2 DESCRIPTION
2.1 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
Bank Bank
Computer Database
ATM System Bank Bank

Computer Database
ATM
ATM
Network
Bank Bank
Computer Database
Bank Bank
Computer Database
ATM NETWORK
Conceptual ATM Model
Card Reader
Cash Dispenser
KeyPad
ATM Deposit Slot
Screen
Printer
Operator
2 Page
______________________________________________________________________________________
Conceptual Flow Diagram of ATM
[Incorrect]
Verify Handle Incorrect
Access Code Access Code
[Correct]
Ask forAmount
[Resolved]
[Note
Resolved]
[Amount not
available]
[Amount
available]
Deposit Slot
Prepare to print
Dispense Cash
Receipt
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
______________________________________________________________________________________
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.
 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.
5 Page
______________________________________________________________________________________
 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.
 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++.
6 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.
 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.
7 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: The staffing recourses arranged with the group of programmers, management, analysts,
documentation.
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
Task Name Duratio Start Finish Resource Names Cost
n
Requirement 1 Requirement 64 days Mon 12/9/13 Thu, $540,800.00

Analysis Analysis 3/6/14
1.1 Develop System 20 days Mon 12/9/13 Fri, 1/3/14 Requirement $64,000.00
Architecture Analysts-1
1.2 Interview 12 days Mon 12/9/13 Tue, Communication $76,800.00

12/24/13 Expert
1.3 Define & 14 days Mon 12/9/13 Thu, Requirement $44,800.00

Develop Software 12/26/13 Analysts-4
Requirements
1.4 Define Interface 14 days Fri, 12/27/13 Wed, Business Analyst, $89,600.00
Requirement 1/15/14 DB2 Expert
1.5 Prioritize and 11 days Wed, Wed, Requirement $35,200.00

Integrate 12/25/13 1/8/14 Analysts-3
Requirements
1.6 System Security 22 days Mon 1/6/14 Tue, 2/4/14 Security Specialist $70,400.00
Analysis
1.7 Software 14 days Thu, 1/16/14 Tue, 2/4/14 Project Leader, $89,600.00
Quality & Risk Requirement
Analysis Analysts-1
1.8 Create Software 22 days Wed, 2/5/14 Thu, Requirement $70,400.00

Requirements 3/6/14 Analysts-2
Specification
Report (SRS)
8 Page
______________________________________________________________________________________
System 2 System Designing 67 days Wed, 2/5/14 Thu, $339,200.00

Designing 5/8/14
2.1 Perform 21 days Wed, 2/5/14 Wed, Software $67,200.00

Architectural 3/5/14 Architect-1
Designing
2.2 Design 21 days Fri, 3/7/14 Fri, 4/4/14 Software $67,200.00

Interfaces Architect-2
2.3 Develop 12 days Thu, 3/6/14 Fri, Software $38,400.00

Algorithm 3/21/14 Architect-3
2.4 Design Test 12 days Mon 4/7/14 Tue, Software $38,400.00

Cases 4/22/14 Architect-3
2.5 Perform 8 days Mon 3/24/14 Wed, Software $51,200.00

Detailed Design 4/2/14 Architect-4,
Software
Architect-1
2.6 Create Software 24 days Mon 4/7/14 Thu, Software $76,800.00
Design 5/8/14 Architect-2
Specification
Coding 3 Coding 47 days Fri, 5/9/14 Mon $518,400.00

7/14/14
3.1 Create Test 19 days Fri, 5/9/14 Wed, Database $60,800.00
Data 6/4/14 Specialist
3.2 Create Source 19 days Fri, 5/9/14 Wed, Front-end $121,600.00

Code 6/4/14 Designer &
Programmer-5-6,
Front-End
Designer &
Programmer-5
3.3 Generate 30 days Fri, 5/9/14 Thu, Java Programmer, $192,000.00
Object Code 6/19/14 Front-End
Designer &
Programmer-5-7
3.4 Plan Integration 7 days Fri, 6/20/14 Mon Front-end $22,400.00
6/30/14 Designer &
Programmer-5-8
3.5 Perform 9 days Tue, 7/1/14 Fri, Front-end $57,600.00
integration 7/11/14 Designer &
Programmer-5-9,
Java Programmer
3.6 Document 10 days Tue, 7/1/14 Mon Front-end $64,000.00
Program Model 7/14/14 Designer &
Programmer-5-10,
Front-End
Designer &
Programmer-5
Testing 4 Testing 60 days Tue, 7/15/14 Mon $278,400.00
9 Page
______________________________________________________________________________________
10/6/14
4.1 Develop, Test 24 days Tue, 7/15/14 Fri, Software Testers-1 $76,800.00
Requirement 8/15/14
4.2 Unit Testing 14 days Mon 8/18/14 Thu, Software Testers-2 $44,800.00
9/4/14
4.3 Component 22 days Mon 8/18/14 Tue, Software Testers-1 $70,400.00
Testing 9/16/14
4.4 System Testing 13 days Mon 9/5/14 Wed, Software Testers-2 $41,600.00
9/23/14
4.5 Provide 14 days Wed, 9/17/14 Mon Software Testers-1 $44,800.00
Feedback to 10/6/14
Programmers
Operation & 5 Operation & 50 days Tue, 10/7/14 Mon $307,200.00

Maintenance Maintenance 12/15/14
5.1 Final checks and 28 days Tue, 10/7/14 Thu, Project Leader $89,600.00
verification 11/13/14
5.2 Documentation 17 days Tue, 10/7/14 Wed, Document Writer- $108,800.00

& User Manual 10/29/14 1, Document
Writer-2
5.3 Training 8 days Tue, 10/7/14 Thu, Training & $25,600.00
10/16/14 Installation
Specialists-1 [0%]
5.4 Distribute 5 days Fri, 11/14/14 Thu, Training & $16,000.00
Software 11/20/14 Installation
Specialists-2
5.5 Install Software 12 days Fri, 11/14/14 Mon Training & $38,400.00
12/1/14 Installation
Specialists-1
5.6 Perform 9 days Tue, 12/2/14 Fri, Training & $28,800.00
Adaptive 12/12/14 Installation
Maintenance Specialists-2
5.7 Perform 1 day Mon Mon $0.00

Preventative 12/15/14 12/15/14
Maintenance
Total = 1984000
Other Expenses 16000
10 Page
______________________________________________________________________________________
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:
Task Name Duration Predecessors
1 Requirement Analysis 64 days

2 Develop System Architecture 20 days
3 Interview 12 days
11 Page
______________________________________________________________________________________
4 Define & Develop Software Requirements 14 days

5 Define Interface Requirement 14 days 5
6 Prioritize and Integrate Requirements 11 days 4
7 System Security Analysis 22 days 3
8 Software Quality & Risk Analysis 14 days 6
9 Create Software Requirements Specification Report (SRS) 22 days 7,8

10 System Designing 67 days
11 Perform Architectural Designing 21 days 9
12 Design Interfaces 21 days 10

13 Develop Algorithm 12 days 12
14 Design Test Cases 12 days 13
15 Perform Detailed Design 8 days 14
16 Create Software Design Specification 24 days 13
17 Coding 47 days
18 Create Test Data 19 days 17
19 Create Source Code 19 days 17
20 Generate Object Code 30 days 15,17,16
21 Plan Integration 7 days 20,21,19
22 Perform integration 9 days 22
23 Document Program Model 10 days 22
24 Testing 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 Provide Feedback to Programmers 14 days 28
30 Operation & Maintenance 50 days
31 Final checks and verification 28 days 30,29
32 Documentation & User Manual 17 days 30

33 Training 8 days 30
34 Distribute Software 5 days 32,33,34
35 Install Software 12 days 32
36 Perform Adaptive Maintenance 9 days 36,35
37 Perform Preventative Maintenance 1 day 37
12 Page
______________________________________________________________________________________
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 =MIN(LST Perform integration, LST Document Program Model)=146
LFT Document 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 problem Risk
5.1 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
______________________________________________________________________________________
5.5 Process Architecture
The Proposed Major Risk Diagram
Technical
Risk
Decision Merge
Project Kick -Off and Live Bank

ATM Software &
date, in 12 month time Network
Collaboration
New platform
Software Components
SSADM and using C++ DOT Net
Waterfall Technology
Computer
ATM
Methodology Simulation Interface
New platform C++ and Development

DOT NET Technology Risk
Dependency Hardware, Available

Risk in Time at the final
stage.
Hardware
Document
5.6 Risk Identification

5.7 The Software Development Risk Taxonomy
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)
 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.
5.7.2 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
______________________________________________________________________________________
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.
 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.
5.8 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 Level 2 Risk Rank Severity Comments
Mission And Project fit 2 Negligible
Goal Factor
Management Application factors
Risk
-Nature of the application 5 Marginal
-Expected size of the 4 Negligible
application
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 8 High New experience in this type
experience 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
16 Page
______________________________________________________________________________________
-Cost estimation 8 High Risk in cost escalation due to

variance from estimate
5.8.1 Technical risks
Level 1 Level 2 Risk Probability
Rank Level
Technical Network Factor
Risk
-Network 9 Critical Many external, unfamiliar
communication issue
Interfaces from the banks will
communicate over the network. The
expectation of the risk becomes high and
critical.
-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 8 High Available on time, at a later stage, the
hardware supply ATM network does not work
independently
-Clint / Server issue 8 High How to communicate with the bank server
in the collaboration with the bank.
Hardware and software factors
External Software 10 Critical Compatibility factor will may occur that
Communication will arise the failure of the final software
application.
- External hardware 7 Marginal Delay and tolerance will turn into risk.
Hardware interface Too Soon

documentation
-Cross platform Too soon
development
Software development 6 Marginal The experience is new and the
factor compatibility will be at high risk, the
development factor may arise during
development phase.
--Product knowledge 8 High New platform, lack of skills to execute the
Issue 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 5 Marginal The change control process that has not
been followed, or is ineffective return a
huge change process
17 Page
______________________________________________________________________________________
- Early identification of 2 Negligible Peer reviews are used sporadically.

defects
- 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.
5.8.2 Business risks
Threaten the viability of the software to be built (market risks, strategic risks, management risks, budget risks)
Level 1 Level 2 Risk Comments
Rank
COMMERCIAL RISK
Supplier Factors 6 Marginal Too soon
-Late delivery of 9 High The possibility is too high
hardware
-Instability of hardware 8 High During installation of hardware and
software might not compatible with
each other.
-Changes in 7 Marginal Possible
environment such as
hardware platforms
External Risk
The likelihood that the event will occur
- Estimate probability 1 Too soon
that event will occur
Risk probability 1 Too soon
(percentage)
*Risk ranking 0 to 10, 10 assumed as highest/*Probability is rated as critical, High, Marginal and negligible.
18 Page
______________________________________________________________________________________
5.9 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 Actor Outcome / Comments
Progress Management Suggested action plan
5.10 Risk Reduction
 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.
19 Page
______________________________________________________________________________________
RE before  RE after
RRL 
risk reduction cost
10.16= $2000000- $1820800

= $179200
 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.
5.11 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 Introduction
7.1.1 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:
 Requirements specification
o Specific requirement
o Non functional requirement
o Functional requirement
 Classes
 Program files
 Interfaces
 Functions
7.3 Features to Test
 Data flows
o Use-Cases
o State diagrams
o Activity diagram
o Sequence diagrams
 Functions
o Withdraw cash
o Balance inquiries
o Transactions
o Deposit
o Sessions
o Operator panel / key operated switch
o Screen
21 Page
______________________________________________________________________________________
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
7.4 Features Not To Test
 Hardware components
 Bank Integration software with the ATM hardware
 Bank database Security
7.5 Refinement Approach
7.5.1 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
______________________________________________________________________________________
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.
 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.
7.6 Testing Task (test identifier)
 Account Information
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
23 Page
______________________________________________________________________________________
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.
 All withdraw cash tests must pass
 90% of check account balance must pass.
 All deposits must pass
24 Page
______________________________________________________________________________________
7.8 Suspension Criteria

 Interface not ready on time
 Software delay
 Staff Unavailable, long and unexpected
7.9 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.
 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.
7.11 Test Deliverables

 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
25 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.
 Equivalence Partitioning
 Boundary Value Analysis Based Testing
 State Transition Testing
 Decision tables
 Error Guessing
 Use case testing
8.1 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
26 Page
______________________________________________________________________________________

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
8.1.3 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
Withdraw money From Account 20 WITHDRAW CARD# 1 TRANS# 2 FROM
Checking 0 NO TO $20.00, SUCCESS, Dispensed:
Checking
$20.00, TOTAL BAL: $80.00
40 Success, Message: WITHDRAW CARD# 1
TRANS# 3 FROM 0 NO TO $40.00,
Checking
Dispensed: $40.00, TOTAL BAL: $40.00
60 Message: WITHDRAW CARD# 1
Checking
Response: FAILURE Insufficient available
balance
Eject and reenter same card 20 Success, Message: WITHDRAW CARD# 1
Checking
Dispensed: $20.00, TOTAL BAL: $20.00
Withdraw money For Account Saving 20 Success, WITHDRAW CARD# 1 TRANS#
5 FROM 1 NO TO $20.00, TOTAL BAL:
Saving
$980.00
Withdraw money From Account 20 Success, WITHDRAW CARD# 1 TRANS#
Checking 6 FROM 0 NO TO $20.00, TOTAL BAL:
Checking
$0.00
27 Page
______________________________________________________________________________________
Withdraw money For Account Saving 200 Message: WITHDRAW CARD# 1

Saving
Response: FAILURE Daily withdrawal
limit exceeded
Eject and Reentered Card 40 WITHDRAW CARD# 1 TRANS# 9 FROM
0 NO TO $20.00, FAILURE Insufficient
Checking
available balance, TOTAL BAL: $0.00
Eject and Reentered Card 100 Message: WITHDRAW CARD# 1
Saving
Response: SUCCESS, Dispensed: $100.00,
TOTAL BAL: $880.00
Saving
TOTAL BAL: $840.00
Saving
Response: FAILURE Daily withdrawal limit
exceeded
Eject and Reentered Card 40 Message: WITHDRAW CARD# 1
Saving
TOTAL BAL: $800.00
Inquiry 1- Message: INQUIRY CARD# 1 TRANS#
Checking 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
Withdrawal Account Invalid Account 3- Money Message: WITHDRAW CARD# 1
Market 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 Environmental needs
 GetAccountBalance (), SetAccountBalance (), Withdrawal ()
8.1.6 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
AT: Account Type
3 A: Enter PIN
TT: Transaction Type
4 S: Allow Access to Account
5 S: Ask for TT with 4 Options

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
______________________________________________________________________________________
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.3 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.
8.4 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
______________________________________________________________________________________
}
}
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
______________________________________________________________________________________
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:
//str += "WITHDRAW";
case 1:
//str += "INIT_DEP";
case 2:
// str += "COMP_DEP";
case 3:
//str += "TRANSFER";
case 4:
str += "INQUIRY ";
}
str += " CARD# " + crd.getNumber();
str += " TRANS# " + int4;
if (int1>=0)
str += " FROM " + int1;
34 Page
______________________________________________________________________________________
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
______________________________________________________________________________________
 Money.java
9.2 Created Test Classes:
 ATMMoneyTest.java
 ATMMessageTest.java
9.3 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.
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:
38 Page
______________________________________________________________________________________
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 Abstraction
Specifications
Proofs Checking
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
______________________________________________________________________________________
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 The method guaranteed not to trigger any exception
40 Page
______________________________________________________________________________________
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
______________________________________________________________________________________
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
______________________________________________________________________________________
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 A A A Communication
Software Architect and Designer Software Document Training Business Analysts
Requirement Expert
Analyst Testers Writer &
Installation
B B Specialist DB2 Expert Security Specialist
B A F Software Document
Requirement
Front End ATM Front End ATM Testers Writer B
Designers and Designers and Training
Analyst Programmers Programmers
& Database Specialist Java Programmer
Installation
C B Specialist
G
Requirement Front End ATM Front End ATM
Analyst Designers and
Client / Server Interface Developer
Designers and
Programmers
Programmers
D
Requirement
C H
Analyst Front End ATM Front End ATM
Designers and Designers and
Programmers Programmers
D I
Front End ATM Front End ATM
E J
Front End ATM Front End ATM
Development Team
46 Page
______________________________________________________________________________________
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

me
Na
k
Tas
on
ati
Dur
rt
Sta
sh
Fini
s
me
Na
ce
our
Res
up
Gro
ce
our
Res
t
Cos
rt
Sta
y
Earl
sh
Fini
y
Earl
rt
Sta
e
Lat
sh
Fini
e
Lat
ck
Sla
rt
Sta
dec
Pre
ors
ess
55 Page
______________________________________________________________________________________
0 Mon Mon Mon Mon Wed Wed 217

XYZ ATM System £0.00
days 12/9/13 12/9/13 12/9/13 12/9/13 10/8/14 10/8/14 days
Requirement 64 Mon Mon Mon Wed 0

Thu 3/6/14 £540,800.00 Thu 3/6/14
Analysis days 12/9/13 12/9/13 12/9/13 3/12/14 days
Develop System 20 Mon Requirement Requirement Mon Mon 0

Fri 1/3/14 £64,000.00 Fri 1/3/14 Fri 1/3/14
Architecture days 12/9/13 Analysts-1 Analysts 12/9/13 12/9/13 days
12 Mon Tue Communication Communications Mon Tue Mon 19

Interview £76,800.00 Fri 1/3/14
days 12/9/13 12/24/13 Expert[200%] Expert 12/9/13 12/24/13 1/20/14 days
Define & Develop

14 Mon Thu Requirement Requirement Mon Thu Tue 26
Software £44,800.00 Fri 1/31/14
days 12/9/13 12/26/13 Analysts-4 Analysts 12/9/13 12/26/13 1/14/14 days
Requirements
Business Business
Define Interface 14 Fri Wed Fri Wed Mon Thu 26
5 Analyst,DB2 Analyst,DB2 £89,600.00
Requirement days 12/27/13 1/15/14 12/27/13 1/15/14 2/3/14 2/20/14 days
Expert Expert
Prioritize and
11 Wed Wed Requirement Requirement Wed Wed Tue 19
Integrate 4 £35,200.00 Tue 2/4/14
days 12/25/13 1/8/14 Analysts-3 Analysts 12/25/13 1/8/14 1/21/14 days
Requirements
System Security 22 Mon Security Security Mon Mon 0

Tue 2/4/14 3 £70,400.00 Tue 2/4/14 Tue 2/4/14
Analysis days 1/6/14 Specialist Specialist 1/6/14 1/6/14 days
Project Leader, Management,

Software Quality 14 Thu Thu Wed 26
Tue 2/4/14 6 Requirement Requirement £89,600.00 Tue 2/4/14 Fri 2/21/14
& Risk Analysis days 1/16/14 1/16/14 3/12/14 days
Analysts-1 Analysts
Create Software
Requirements 22 Wed Requirement Requirement Wed Wed 0
Thu 3/6/14 7,8 £70,400.00 Thu 3/6/14 Thu 3/6/14
Specification days 2/5/14 Analysts-2 Analysts 2/5/14 2/5/14 days
Report(SRS)
67 Wed Wed 22
System Designing Thu 5/8/14 £339,200.00 Thu 5/8/14 Fri 3/7/14 Thu 5/8/14
days 2/5/14 2/5/14 days
Perform
21 Wed Wed Software Front End ATM Wed Wed Thu Thu 26
Architectural 9 £67,200.00
days 2/5/14 3/5/14 Architect-1 as Designers 2/5/14 3/5/14 3/13/14 4/10/14 days
Designing
21 Software Front End ATM 0

Design Interfaces 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
days Architect-2 as Designers 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
56 Page
______________________________________________________________________________________
Algorithm days Architect-3 as Designers 4/28/14 days
12 Mon Tue Software Front End ATM Mon Tue Wed 12

Design Test Cases 13 £38,400.00 Thu 5/8/14
days 4/7/14 4/22/14 Architect-3 as Designers 4/7/14 4/22/14 4/23/14 days
Software
Perform Front End
8 Mon Wed Architect- Mon Wed Tue Thu 26
Detailed 14 ATM as £51,200.00
days 3/24/14 4/2/14 4,Software 3/24/14 4/2/14 4/29/14 5/8/14 days
Design Designers
Architect-1
Create
Front End
Software 24 Mon Thu Software Mon Thu Mon Thu 0
13 ATM as £76,800.00
Design days 4/7/14 5/8/14 Architect-2 4/7/14 5/8/14 4/7/14 5/8/14 days
Designers
Specification
47 Fri Mon Fri Mon Fri Mon 0
Coding £518,400.00
days 5/9/14 7/14/14 5/9/14 7/14/14 5/9/14 7/14/14 days
Create Test 19 Fri Wed Database Database Fri Wed Mon Thu 11
17 £60,800.00
Data days 5/9/14 6/4/14 Specialist Specialist 5/9/14 6/4/14 5/26/14 6/19/14 days
Front-End
Designer &
Programmer-
Front End
Create 19 Fri Wed 5-6,Front- Fri Wed Mon Thu 11
17 ATM as £121,600.00
Source Code days 5/9/14 6/4/14 End Designer 5/9/14 6/4/14 5/26/14 6/19/14 days
Designers
&
Programmer-
5
Java
Programmer,
OOPS,Front
Generate 30 Fri Thu Front-End Fri Thu Fri Thu 0
15,17,16 End ATM as £192,000.00
Object Code days 5/9/14 6/19/14 Designer & 5/9/14 6/19/14 5/9/14 6/19/14 days
Designers
Programmer-
5-7
Plan 7 Fri Mon Front-End Front End Fri Mon Fri Mon 0
20,21,19 £22,400.00
Integration days 6/20/14 6/30/14 Designer & ATM as 6/20/14 6/30/14 6/20/14 6/30/14 days
57 Page
______________________________________________________________________________________
Programmer- Designers
5-8
Front-End
Front End
Designer &
Perform 9 Tue Fri ATM as Tue Fri Wed Mon 1
22 Programmer- £57,600.00
integration days 7/1/14 7/11/14 Designers, 7/1/14 7/11/14 7/2/14 7/14/14 day
5-9,Java
OOPS
Programmer
Front-End
Designer &
Programmer-
Document Front End
10 Tue Mon 5-10,Front- Tue Mon Tue Mon 0
Program 22 ATM as £64,000.00
days 7/1/14 7/14/14 End Designer 7/1/14 7/14/14 7/1/14 7/14/14 days
Model Designers
&
Programmer-
5
60 Tue Mon Tue Mon Tue Mon 0
Testing £278,400.00
days 7/15/14 10/6/14 7/15/14 10/6/14 7/15/14 10/6/14 days
Develop Test 24 Tue Fri Software Software Tue Fri Tue Fri 0
24,23 £76,800.00
Requirement days 7/15/14 8/15/14 Testers-1 Testers 7/15/14 8/15/14 7/15/14 8/15/14 days
14 Mon Thu Software Software Mon Thu Fri Wed 9
Unit Testing 26 £44,800.00
days 8/18/14 9/4/14 Testers-2 Testers 8/18/14 9/4/14 8/29/14 9/17/14 days
Component 22 Mon Tue Software Software Mon Tue Mon Tue 0
26 £70,400.00
Testing days 8/18/14 9/16/14 Testers-1 Testers 8/18/14 9/16/14 8/18/14 9/16/14 days
System 13 Fri Tue Software Software Fri Tue Thu Mon 9
27 £41,600.00
Testing days 9/5/14 9/23/14 Testers-2 Testers 9/5/14 9/23/14 9/18/14 10/6/14 days
Provide
14 Wed Mon Software Software Wed Mon Wed Mon 0
Feedback to 28 £44,800.00
days 9/17/14 10/6/14 Testers-1 Testers 9/17/14 10/6/14 9/17/14 10/6/14 days
Programmers
Operation & 50 Tue Mon Tue Mon Tue Mon 0
£307,200.00
Maintenance days 10/7/14 12/15/14 10/7/14 12/15/14 10/7/14 12/15/14 days
58 Page
______________________________________________________________________________________
Final checks 28 Tue Thu Tue Thu Tue Thu 0

30,29 Project Leader Management £89,600.00
and verification days 10/7/14 11/13/14 10/7/14 11/13/14 10/7/14 11/13/14 days
Document
17 Tue Wed Writer- Document Tue Wed Fri Mon 18
Documentation 30 £108,800.00
days 10/7/14 10/29/14 1,Document Writers 10/7/14 10/29/14 10/31/14 11/24/14 days
& User Manual
Writer-2
Training &
Training and
8 Tue Thu Installation Tue Thu Thu Mon 27
Training 30 Installation £25,600.00
days 10/7/14 10/16/14 Specialists- 10/7/14 10/16/14 11/13/14 11/24/14 days
Specialists.
1[0%]
Training & Training and
Distribute 5 Fri Thu Fri Thu Tue Mon 7
32,33,34 Installation Installation £16,000.00
Software days 11/14/14 11/20/14 11/14/14 11/20/14 11/25/14 12/1/14 days
Specialists-2 Specialists.
Training & Training and
Install 12 Fri Mon Fri Mon Fri Mon 0
32 Installation Installation £38,400.00
Software days 11/14/14 12/1/14 11/14/14 12/1/14 11/14/14 12/1/14 days
Specialists-1 Specialists.
Perform Training & Training and
9 Tue Fri Tue Fri Tue Fri 0
Adaptive 36,35 Installation Installation £28,800.00
days 12/2/14 12/12/14 12/2/14 12/12/14 12/2/14 12/12/14 days
Maintenance Specialists-2 Specialists.
Perform
1 Mon Mon Mon Mon Mon Mon 0
Preventative 37 £0.00
day 12/15/14 12/15/14 12/15/14 12/15/14 12/15/14 12/15/14 days
Maintenance
0 Mon Mon Mon Mon Mon Mon 0
Finish Task 38 £0.00
days 12/15/14 12/15/14 12/15/14 12/15/14 12/15/14 12/15/14 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
View publication stats

Project Management, Software Testing: September 2015

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management, Software Testing: September 2015

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Project Management, Software Testing

Research · September 2015

The user has requested enhancement of the downloaded file.

Project Management, Software Testing

ATM System Bank Bank

Conceptual ATM Model

ATM Deposit Slot

Conceptual Flow Diagram of ATM

Finish Transaction &

3 EVALUTION OF THE PLAN

3.1 Duration & Resource Evaluation

 Generate Object Code: a sequence of instruction in a computer language, generating an executable by

3.2 Cost Estimation:

Requirement 1 Requirement 64 days Mon 12/9/13 Thu, $540,800.00

1.2 Interview 12 days Mon 12/9/13 Tue, Communication $76,800.00

1.3 Define & 14 days Mon 12/9/13 Thu, Requirement $44,800.00

1.5 Prioritize and 11 days Wed, Wed, Requirement $35,200.00

1.8 Create Software 22 days Wed, 2/5/14 Thu, Requirement $70,400.00

System 2 System Designing 67 days Wed, 2/5/14 Thu, $339,200.00

2.1 Perform 21 days Wed, 2/5/14 Wed, Software $67,200.00

2.2 Design 21 days Fri, 3/7/14 Fri, 4/4/14 Software $67,200.00

2.3 Develop 12 days Thu, 3/6/14 Fri, Software $38,400.00

2.4 Design Test 12 days Mon 4/7/14 Tue, Software $38,400.00

2.5 Perform 8 days Mon 3/24/14 Wed, Software $51,200.00

Coding 3 Coding 47 days Fri, 5/9/14 Mon $518,400.00

3.2 Create Source 19 days Fri, 5/9/14 Wed, Front-end $121,600.00

Operation & 5 Operation & 50 days Tue, 10/7/14 Mon $307,200.00

5.2 Documentation 17 days Tue, 10/7/14 Wed, Document Writer- $108,800.00

5.7 Perform 1 day Mon Mon $0.00

Other Expenses 16000

4 PROJECT PLANNING PROCESS:

Task Name Duration Predecessors

1 Requirement Analysis 64 days

4 Define & Develop Software Requirements 14 days

9 Create Software Requirements Specification Report (SRS) 22 days 7,8

12 Design Interfaces 21 days 10

25 Develop Test Requirement 24 days 24,23

32 Documentation & User Manual 17 days 30

Forward & Backward Pass Calculation for WBS

4.2 Forward Pass

4.3 Backward Pass

4.4 Work Breakdown Structure:

5 RISK ASSESMENT PROCESS

Hazard problem Risk

5.1 Phase 1, concept exploration

5.5 Process Architecture

The Proposed Major Risk Diagram

Project Kick -Off and Live Bank

New platform C++ and Development

Dependency Hardware, Available

5.6 Risk Identification

-Cost estimation 8 High Risk in cost escalation due to

Hardware interface Too Soon

- Early identification of 2 Negligible Peer reviews are used sporadically.

5.9 RISK ASSESSMENT & RISK REGISTER

Portability / Impact Values

10.16= $2000000- $1820800

7 TEST PLAN BASED ON IEEE 829 STANDERED

7.5.3 Testing Tools

7.8 Suspension Criteria

7.11 Test Deliverables

8 BLACK BOX TEST