GEETHANJALI COLLEGE OF ENGINEERING AND TECHNOLOGY

(UGC Autonomous)
Cheeryal (V), Keesara (M), Medchal Dist., Telangana-501301

20CS31L01-SOFTWARE ENGINEERING LAB

B.Tech. CSE - III Year, I Sem.
L T P/D C
Prerequisite(s): None - - 2 1

Course Objectives
Develop ability to
1. Understand the basis of software development process.
2. Design the requirements of the customer.
3. Elaborate the design process of software development.
4. Identify various project and process metrics.
5. Apply software testing and its importance in assuring quality.

Course Outcomes (COs)

At the end of the course, student would be able to
CO1. Identify various software process models and its
techniques. CO2. Analyze the requirements and specifications
of the project. CO3. Design software architecture & its process.
CO4. Evaluate the project using process and project
metrics. CO5. Confirm the quality of the software through
testing.

1. For a given a problem statement, analyze using any one of the software process models of
your choice.

ATM SYSTEM CASE STUDY The ATM System is the project which is used to access
their bank accounts in order to make cash withdrawals. Whenever the user needs to make
cash withdrawals, they can enter their PIN number (personal identification number) and it
will display the amount to be withdrawn in the form of 100s 500s and 1000s. Once their
withdrawal was successful, the amount will be debited in their account. The ATM System
project will be developing in VB.Net and backend database as Microsoft-Access. VB.Net
is the one of the powerful versions of Framework and object oriented programming.
Hence we use this software in our project.

The ATM will service one customer at a time. A customer is required to enter ATM Card
number, personal identification number (PIN) – both of which will be sent to the database
for validation as part of each transaction. The customer will then be able to perform one
or more transactions. Also customer must be able to make a balance inquiry of any
account linked to the card. The ATM will communicate each transaction to the database
and obtain verification that it was allowed by the database. In the case of a cash
withdrawal, a second message will be sent after the transaction has been physically
completed (cash dispensed or envelope accepted). If the database determines that the
customer‟s PIN is invalid, the customer will be required to re-enter the PIN before a
transaction can proceed.
If a transaction fails for any reason other than an invalid PIN, the ATM will display an explanation of
the problem, and will then ask the customer whether he/she wants to do another transaction.
The ATM will provide the customer with a printed receipt for each successful transaction, showing the
date, time, machine location, type of transaction, account(s), amount, and ending and available
balance(s) of the affected account (“to” account for transfers).
Adopt the following software development strategy
 Water fall model
 Iterative model
 Rapid-prototyping model
 Spiral model
 Unified Process
 Software documentation Standard to follow: IEEE standard or DOD-2167A

Milestones in the project:

1. Problem Analysis and Project Planning
Thorough study of the problem – Identify project scope, Objectives, infrastructure, and plan
for the project; Document it.
2. Software Requirement
Analysis describes the individual Phases/ modules of the project, Identify deliverables;
Document it
3. Data Modeling
Use work products – use case diagram, data flow diagram, Flow chart
4. Software Development and Debugging
Choose programming language of your choice
5. Software Testing
Prepare test plan, perform validation testing, coverage analysis, test case
prioritization.

NOTE:
 Each student can adopt different software development life cycle (such as Water fall model,
iterative model, spiral model, RAD, prototyping model etc…) and programming language
combination so that each student work in unique but still conform to over all deliverable.
 Teams to be formed containing 5 in each to make the software engineering activities effectively
with good coordination.
 Any other systems like(Library Management system, hospital management system, course
registration system, railway reservation system) can also be done.
 If the problem statement is not mentioned explicitly, first the problem statement can be written,
then follow the same flow.
Week1: To understand various software process models used for software
development.

Week2:To write the problem statement for the given ATM system

Week3:To identify project scope ,objectives, infrastructure and plan for the
system
Experiment 2

Given a problem statement, analyze it using any one of the software process models of your choice for the
ATM system project.

Objective:
To understand the various software process models and to use them in the software development process
using software engineering concepts.

Outcome:

Students will be able to apply the knowledge of various CASE tools used in the software engineering lab.

Description:

Problem Statement for ATM

Customers felt inconvenient with the transaction technique because it was in the hands of bank staff. The
project entitled ATM system has a radical alteration to that of the older version of banking system. The
aforesaid concern is solved in our ATM system because all transactions are completed in person by the
consumer, making them feel comfortable and secure. By authenticating the pin number, our system's
application assists the customer in checking the balance and transaction of the money. As a result, the ATM
is more user-friendly. Some customers may have taken advantage of special offers on their ATM cards; this
must be addressed, and the necessary data must be handled.

Requirement Analysis
• The software to be designed will control a simulated automated teller machine (ATM) having a
magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for
interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of
$20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start
or stop the machine. The ATM will communicate with the bank's computer over an appropriate
communication link. (The software on the latter is not part of the requirements for this problem.)
• The ATM will service one customer at a time. A customer will be required to insert an ATM card and
enter a personal identification number (PIN) - both of which will be sent to the bank for validation as
part of each transaction. The customer will then be able to perform one or more transactions. The card
 will be retained in the machine until the customer indicates that he/she desires no further transactions,
at which point it will be returned - except as noted below.

The ATM must be able to provide the following services to the customer:
• A customer must be able to make a cash withdrawal from any suitable account linked to the card, in
multiples of $20.00. Approval must be obtained from the bank before cash is dispensed.
• A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or
checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to
manual verification when the envelope is removed from the machine by an operator. Approval must
be obtained from the bank before physically accepting the envelope.
• A customer must be able to make a transfer of money between any two accounts linked to the card.
• A customer must be able to make a balance inquiry of any account linked to the card.

• A customer must be able to abort a transaction in progress by pressing the Cancel key instead of
responding to a request from the machine.

 The ATM will communicate each transaction to the bank and obtain verification that it was allowed
by the bank. Ordinarily, a transaction will be considered complete by the bank once it has been
approved. In the case of a deposit, a second message will be sent to the bank indicating that the
customer has deposited the envelope. (If the customer fails to deposit the envelope within the timeout
period, or presses cancel instead, no second message will be sent to the bank and the deposit will not
be credited to the customer.)

 If the bank determines that the customer's PIN is invalid, the customer will be required to re-enter the
PIN before a transaction can proceed. If the customer is unable to successfully enter the PIN after
three tries, the card will be permanently retained by the machine, and the customer will have to
contact the bank to get it back.

 If a transaction fails for any reason other than an invalid PIN, the ATM will display an explanation of
the problem, and will then ask the customer whether he/she wants to do another transaction.

 The ATM will provide the customer with a printed receipt for each successful transaction, showing
the date, time, machine location, type of transaction, account(s), amount, and ending and available
balance(s) of the affected account ("to" account for transfers).

 The ATM will have a key-operated switch that will allow an operator to start and stop the servicing of
customers. After turning the switch to the "on" position, the operator will be required to verify and
enter the total cash on hand. The machine can only be turned off when it is not servicing a customer.

 When the switch is moved to the "off" position, the machine will shut down, so that the operator may
remove deposit envelopes and reload the machine with cash, blank receipts, etc.

 The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities arising
from a hardware failure in the middle of a transaction. Entries will be made in the log when the ATM
is started up and shut down, for each message sent to the Bank (along with the response back, if one is
expected), for the dispensing of cash, and for the receiving of an envelope. Log entries may contain
card numbers and dollar amounts, but for security will never contain a PIN.
Planning
Analysis Design

ATM
- id: int
- place: String
- bankName: String
- bankAddress: InetAddress
- cardReader: CardReader
- cashDispenser: CashDispenser
- customerConsole: CustomerConsole
- envelopeAcceptor: EnvelopeAcceptor
- log: Log
- networkToBank: NetworkToBank
- operatorPanel: OperatorPanel
- receiptPrinter: ReceiptPrinter
- state: int
- switchOn: boolean
- cardInserted: boolean
- OFF_STATE: final int
- IDLE_STATE: final int
- SERVING_CUSTOMER_STATE: final int
+ ATM(id: int, place: String, bankName: String, bankAddress: InetAddress)
+ run()
+ switchOn()
+ switchOff
+ cardInserted()
+ getID(): int
+ getPlace(): String
+ getBankName(): String
+ getCardReader(): CardReader
+ getCashDispenser(): CashDispenser
+ getCustomerConsole(): CustomerConsole
+ getEnvelopeAcceptor(): EnvelopeAcceptor
+ getLog(): Log
+ getNetworkToBank(): NetworkToBank
+ getOperatorPanel(): OperatorPanel
+ getReceiptPrinter(): ReceiptPrinter
- performStartup()
- performShutdown()
CardReader
- atm: ATM
+ CardReader(atm: ATM)
+ readCard(): Card
+ ejectCard()
+ retainCard()

CashDispenser
- log: Log
- cashOnHand: Money
+ CashDispenser(log: Log)
+ setInitialCash(initialCash: Money)
+ checkCashOnHand(amount: Money): boolean
+ dispenseCash(amount: Money)
CustomerConsole
+ CustomerConsole()
+ display(message: String)
+ readPIN(prompt: String): int throws Cancelled
+ readMenuChoice(prompt: String, menu: String []): int throws Cancelled
+ readAmount(prompt: String): Money throws Cancelled
EnvelopeAcceptor
- log: Log
+ EnvelopeAcceptor(log: Log)
+ acceptEnvelope() throws Cancelled
Log
+ Log()
+ logSend(message: Message)
+ logResponse(status: Status)
+ logCashDispensed(amount: Money)
+ logEnvelopeAccepted()
NetworkToBank
- log: Log
- bankAddress: InetAddress
+ NetworkToBank(log: Log, bankAddress: InetAddress)
+ openConnection()
+ closeConnection()
+ sendMessage(message: Message, out balances: Balances): Status
OperatorPanel
- atm: ATM
+ OperatorPanel(atm: ATM)
+ getInitialCash(): Money
Session

- atm: ATM
- pin: int
- state: int
- READING_CARD_STATE: final int
- READING_PIN_STATE: final int
- CHOOSING_TRANSACTION_STATE: final int
- PERFORMING_TRANSACTION_STATE: final int
- EJECTING_CARD_STATE: final int
- FINAL_STATE: final int
+ Session(atm: ATM)>
+ performSession()
+ setPIN(int pin)
Transaction
# atm: ATM
# session: Session
# card: Card
# pin: int
# serialNumber: int
# message: Message
# balances: Balances
- TRANSACTION_TYPES_MENU: final String []
- nextSerialNumber: int
- state: int
- GETTING_SPECIFICS_STATE: final int
- SENDING_TO_BANK_STATE: final int
- INVALID_PIN_STATE: final int
- COMPLETING_TRANSACTION_STATE: final int
- PRINTING_RECEIPT_STATE: final int
- ASKING_DO_ANOTHER_STATE: final int

# Transaction(atm: ATM, session: Session, card: Card, pin: int)

+ makeTransaction(atm: ATM, session: Session, card: Card, pin: int): Transaction throws Cancelled
+ performTransaction(): boolean throws CardRetained
+ performInvalidPinExtension(): Status throws Cancelled, CardRetained
+ getSerialNumber(): int
# getSpecificsFromCustomer(): Message throws Cancelled
# completeTransaction(): Receipt throws Cancelled
Withdrawal

- from: int
- amount: Money
+ Withdrawal(atm: ATM, session: Session, card: Card, pin: int)
# getSpecificsFromCustomer(): Message throws Cancelled
# completeTransaction(): Receipt
Deposit
- to: int
- amount: Money

+ Deposit(atm: ATM, session: Session, card: Card, pin: int)

# getSpecificsFromCustomer(): Message throws Cancelled
# completeTransaction(): Receipt throws Cancelled
Transfer

- from: int
- to: int
- amount: Money

+ Transfer(atm: ATM, session: Session, card: Card, pin: int)

# getSpecificsFromCustomer(): Message throws Cancelled
# completeTransaction(): Receipt
AccountInformation

+ ACCOUNT_NAMES: final String[]

+ ACCOUNT_ABBREVIATIONS: final String []
Balances
- total: Money
- available: Money

+ Balances()
+ setBalances(total: Money, available: Money)
+ getTotal(): Money
+ getAvailable(): Money
Card

- number: int

+ Card(number: int)
+ getNumber(): int
Message

+ WITHDRAWAL: final int

+ INITIATE_DEPOSIT: final int
+ COMPLETE_DEPOSIT: final int
+ TRANSFER: final int
+ INQUIRY: final int
- messageCode: int
- card: Card
- pin: int
- serialNumber: int
- fromAccount: int
- toAccount: int
- amount: int
+ Message(messageCode: int, cardNumber: Card, pin: int, serialNumber: int, fromAccount: int, toAccount: int,
amount: Money)
+ toString(): String
+ setPIN(pin: int)
+ getMessageCode(): int
+ getCard(): Card
+ getPIN(): int
+ getSerialNumber(): int
+ getFromAccount(): int
+ getToAccount(): int
+ getAmount(): Money
Money

- cents: long
+ Money(dollars: int)
+ Money(dollars: int, cents: int)
+ Money(toCopy: Money)
+ toString(): String
+ add(amountToAdd: Money)
+ subtract(amountToSubtract: Money)
+ lessEqual(compareTo: Money): boolean
Receipt
- headingPortion: String []
# detailsPortion(): String []
- balancesPortion: String []
# Receipt(atm: ATM, card: Card, transaction: Transaction, balances: Balances)
+ getLines(): Enumeration
Status
+ toString(): String
+ isSuccess(): boolean
+ isInvalidPIN(): boolean
+ getMessage(): String

Inquiry

- from: int

+ Inquiry(atm: ATM, session: Session, card: Card, pin: int)

# getSpecificsFromCustomer(): Message throws Cancelled
# completeTransaction(): Receipt

Package Diagram for Example ATM System

The package diagram shows how the various classes are grouped into packages. There are two "top-level"
classes - ATMMain and ATMApplet - which allow the system to be run (respectively) as an application or as
an Applet. (Only one of the two would be instantiated in any particular use of the system.)

Each of these classes, in turn, depends on the package atm which contains the class ATM that represents the
system as a whole, and the class Session that represents one session. ATM depends on Session, and vice
versa - since the ATM creates Sessions, and each Session, in turn, uses the ATM to interact with the
customer.

The sub package transaction contains the classes used to represent individual transactions that a customer
initiates. The class Session depends on the transaction package because it creates individual transaction
objects. These, in turn, again depend on the ATM to interact with the customer.

The sub package physical contains the classes that represent the various physical components of the ATM.
For the purposes of this simulation, these are simulated by a GUI. A real ATM would have quite different
classes in this package - classes that actually control its physical components. The class ATM makes use of
these components, and Session and the various kinds of transaction gain access to them through ATM to
actually perform the needed operations.

Finally, the package banking contains classes that represent the banking enterprise itself and the information
communicated back and forth between the ATM and the bank - i.e. classes which might be the same in a
totally different implementation of an ATM that interacts with the same bank.

This is, of course, a simulation. However, most of the code that is specific to the simulation resides in the
package physical, plus the two top-level classes. Presumably, the other classes and packages might be similar
in a real system.

Software Engineering Lab Page 13

Construction:
Package Class - source code Class - javadoc

(No javadoc for this

(Top-level) ATMMain.java
class)
(No javadoc for this
(Top-level) ATMApplet.java
class)

atm ATM ATM

Session Session

atm.physical CardReader CardReader

CashDispenser CashDispenser
CustomerConsole CustomerConsole
EnvelopeAcceptor EnvelopeAcceptor
Log Log
NetworkToBank NetworkToBank
OperatorPanel OperatorPanel
ReceiptPrinter ReceiptPrinter

atm.transaction Transaction Transaction

Withdrawal Withdrawal
Deposit Deposit
Transfer Transfer
Inquiry Inquiry

banking AccountInformation AccountInformation

Balances Balances
Card Card
Message Message
Money Money
Receipt Receipt
Status Status
 Deployment:

This page lists various changes that might be made to the system. Modifying the various documents to
incorporate one or more of these changes would make an interesting exercise for the reader.

Corrective Maintenance
The careful reader will note that the requirement that "Entries will be made in the log when the ATM is
started up and shut down" has not been reflected in any of the diagrams or the code. What changes would be
needed to implement this requirement?
When the system asks the customer a question, it waits as long as necessary for the customer to
answer. This could cause a severe security problem if the customer were to leave at this point without
answering the question, since the ATM card would still be in the machine, generally with the customer's PIN
having already been entered, thus allowing another user to "hijack" the session and perform operations like
cash withdrawal from the customer's account.
While this seems unlikely, it is conceivable in some cases that a distracted customer might make this
mistake. For example, after performing a transaction, the system asks the user "Would you like to do another
transaction?". If the customer has just withdrawn cash, it is conceivable that the customer might place the
cash in his/her wallet and accidentally forget about answering the question and retrieving the card.
A real ATM typically has a timeout mechanism that begins beeping and ultimately ejects the card and
ends the session if the user fails to respond within a certain amount of time. While a customer who leaves
before this happens might inadvertently leave a card behind, at least the customer would not be "logged in"
with his/her PIN. (Thus, the security risk is comparable to that resulting from a lost card, with the customer's
account still PIN protected.) What changes would be needed to the system requirements, design, and code to
improve security this way?

Adaptive Maintenance

Many ATM's have cash dispensers that can handle two different denominations of bills - often $20 and $5 -
which allows a user to request cash in any amount that is a multiple of $5. Suppose the cash dispenser in the
example (which only handles $20 bills) were replaced with such a dispenser. What changes would be needed
to take advantage of the enhanced capabilities of such a dispenser?

Perfective Maintenance

When the customer's card is retained, an entry should be made in the log to this effect.
Many ATM's offer the customer additional options beyond the basic four listed here - e.g. making a payment
on a loan the customer has from one of the accounts linked to his/her card. What changes would be needed to
make it possible for a customer to make a loan payment at the ATM?
Code for Example ATM System

This page contains links both to the actual Java code that implements the ATM simulation, and to javadoc
documentation generated from the code. The code is organized into a collection of packages, as shown in the
Package Diagram.
In addition to the classes and packages that have been discussed throughout the design, the GUI simulation
makes use of a package (called simulation) that contains the details of the GUI, including the code that does
the animation. This code takes the place of an actual hardware ATM, but has not been otherwise documented
in this series of web pages. The design of the simulation package is discussed briefly, and its code may be
accessed here if you want to see it.

Package Class - source code Class - javadoc

(Top-level) ATMMain.java (No javadoc for this class)
(Top-level) ATMApplet.java (No javadoc for this class)
atm ATM ATM
Session Session
atm.physical CardReader CardReader
CashDispenser CashDispenser
CustomerConsole CustomerConsole
EnvelopeAcceptor EnvelopeAcceptor
Log Log
NetworkToBank NetworkToBank
OperatorPanel OperatorPanel
ReceiptPrinter ReceiptPrinter
atm.transaction Transaction Transaction
Withdrawal Withdrawal
 Deposit Deposit
Transfer Transfer
InquiryInquiry
banking Account Information Account Information
Balances Balances
Card Card
Message Message
Money Money
Receipt Receipt
Status Status

Testing

By using Selenium tool we can test all scenarios.

Experiment 2

Thorough study of the problem – Identify project scope, Objectives, infrastructure, and plan for the
project, Document it

Objective:

To understand the given library management system and to write down the problem statement or problem
definition which helps to initially understand and identify the use cases and actors involved in the given
system or the application.

Outcome:

Students will be able to write problem definition or statement for any system.

Description:

Introduction
Banking is one of the common and day to day attribute of life. Now a days it is totally different from
that existed a few years ago banking has become completely computerized new facilities such as credit cards,
debit cards and ATM has been introduced. ATM is automatic teller machine which is basically used to with
draw money from an account.
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.

Project Scope

The scope of the project is to design an ATM system that will help in completely automatic banking
this software is going to be designed for withdrawal and deposit of money and register the transaction in the
database where the customer’s information is stored.

Objectives

The objective of this software is similar to ATM software installed in ATM center. It should first
validate the pin in the ATM card. Then the type of transaction is enquired and the information from the
customer is validated. If it is a withdrawal the amount is asked. After the money is delivered the transaction
just made is updated in the database where the customer’s information is stored.

Infra-Structure

Bank ATM is typically made up of several devices such as central processor unit (CPU),
cryptoprocessor, memory, customer display, function key buttons (usually located near the display),
magnetic
 and/or smart chip card reader, encrypting PIN Pad, customer receipt printer, vault, modem. Vault stores
devices and parts which require restricted access, including cash dispensing mechanism, deposit mechanism,
several security sensors (e.g. magnetic, thermal, seismic, gas), electronic journal system to maintain system
log, etc. Cash dispenser includes several removable cash cartridges and deposit mechanism - removable
deposit cartridges.
ATM is usually connected to the bank or interbank network via some modem (e.g. dial-up or ADSL) over a
public switched telephone line or a leased line. Network interface card (NIC) could be used as a high-speed
alternative in VPN connections.
The overview diagram below explains the composite structure diagram with elements of internal structure of
a structured classifier - roles, parts, connectors.

Product Viewpoint

The ATM network will work together with the software provided by the banks, where banks have
defined interfaces for the communication.
PROJECT PLANNING PROCESS:

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. The chart showing below is project planning.
Plan for the project (Work Break down Structure (WBS))

S.NO Task Name Duration Predecessors

1 Requirement Analysis 64 days
2 Develop System Architecture 20 days
3 Interview 12 days
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
Create Software Requirements Specification Report
9 22 days 7,8
(SRS)
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
Plan for the project (Work Break down Structure (WBS))

S.NO Task Name Duration Predecessors

1 Requirement Analysis 64 days
2 Develop System Architecture 20 days
3 Interview 12 days
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
Create Software Requirements Specification Report
9 22 days 7,8
(SRS)
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