WEEK 4

OCEAN'S 10

SHAMIM AHMED

Role - TECHNICAL LEAD

Revision History
Week
Number

Author

Shamim

Shamim

Shamim

Description of changes

Began work on the project, we have assembled

some startup code and assigned roles for the
week. We spent much of the week organizing
ourselves and getting the project ready (hosting,
what platform, etc.)
Made a good amount of progress on the project,
we have a prototype shell that runs on an Android
platform allowing the user to sign up for their own
account. We have a temporary storage location for
this new account information. Our next goal is to
integrate a database that will allow us to store
multiple accounts and allow for secure log-ins.
Updated sections of this file to reflect where we
are currently at.
We've decided to implement SQLite for our
database storage and we were able to successfully
set up a log-in system dealing with numerous
accounts. We're currently working on tweaking
the aesthetics of our program and improving the
log-in functionality. Edited some info in this Team
Lead document to reflect where we're currently at.

1. Development Team Technical Proficiency plan

For this particular bank account project, we have decided to work via
Android development, specifically using the Eclipse Android SDK. My
teammates and myself came to this decision after analyzing the strengths of
each of our members. We found that the best way for us to interact and host
all of our work was via github. We all have the correct compiler and tools

WEEK 4

OCEAN'S 10

SHAMIM AHMED

necessary to complete our work in our own time, though we decided that it
would be best to finish the majority of our work in the actual labs on campus.
As I've noticed from our discussions and meetings, our team has a
varying degree of experience with this sort of project; from beginner to very
experienced. We needed to find out which programming language was the
most comfortable for the entire team and we reached a consensus on using
the Java programming language as many of us have had the majority of our
programming experience in UCSD courses that were Java based. Since we
have programmers who are well versed in constructing projects of this
magnitude, we've decided that it would be best to have one of our more
experienced team members to serve as aids to help guide the project along
smoothly on any given week.
2. Onboarding/ Zero-day bootup plan
The main repository through which my teammates and myself will be
working throughout the project is located at:
https://github.com/bhn013/CSE110-Ocean-s-10
We felt that github would be the most useful site through which we can
host the project and keep track of any updates/changes we make to the
project itself. Github allows for us to look through the various revisions and
keep track of the project through various stages. It also makes it very easy
for us to share the latest version of any code without having to jump through
any unnecessary hoops. Seeing as we've all taken CSE15L, we all have some
experience with github, thus it is a simple matter of brushing up specifics.
Due to our team being split using two different operating systems
(Windows and Apple), we've decided to use Android Studio and Eclipse Indigo
as the main programs through which we will code this project. As of now,
we're still testing out the pros and cons of each of them, though Android
Studio seems to be the favorite. We're using the Android SDK
(https://developer.android.com/sdk/index.html?hl=i) which will provide us
with the tools necessary to build, test and debug our app for use on an
Android system.
We are now four weeks into the project and these are the major artifacts
we have been working with to this point:

WEEK 4

OCEAN'S 10

SHAMIM AHMED

MainActivity.java -- The main screen of our program, what users will

see at startup

SignupActivity.java -- The page that pops up after clicking "Sign Up" on

the main page

SignupNextActivity.java -- The page following initial sign up, asks for

more information

LoginActivity.java -- If sign in button is pushed on main page, move to

the log-in page

Each of these Java files have an accompanying xml file for its layout.
Additionally, we have a number of generated xml files that are included in
the repository. If a new member were to come aboard onto our development
team, they would simply need to gain access to the central repository if they
wished to see these (less significant) files.
3. Technical Artifacts Delivery Plan
Our current delivery plan contains the following in order of priority:
1. Create User Account (5 Days est., priority 10) [COMPLETE]
2. Log in to user account (5 Days est., priority 10) [COMPLETE]
3. View/Check Balance (3 Days est., priority 10)
4. Credit the Account (5 days est., priority 20)
5. Debit the Account (5 days est., priority 20)
6. Transfer Money (5 days est., priority 20)
7. Delete account (3 days est., priority 50)
8. Penalty for low balance (3 days est., priority 40)
9. Calculate Interest (4 days est., priority 40)
10.

Create multiple user accounts (1 days est., priority 30)

11.

Print account statements (2 days est., priority 20)

4. Version control system and adaptation plan

Our team will be managing code and various versions through using
github to host the project. We are planning on keeping our project updated
with descriptive commit tags so that we can keep track of what we have

WEEK 4

OCEAN'S 10

SHAMIM AHMED

done thus far. All of our members have taken CSE 15L, thus we all have some
experience with using git. If a refresher is necessary, we are planning on
going through the git demo individually so that we all become familiar with
it.
Our team seems to be quite comfortable with the system, thus I do not
believe that we will need to change to anything else in the near future. We're
planning on hosting our entire project on github.
Our production and release cycle will be monitored and updated on a
weekly basis. The release cycle would depend upon the time that is needed
to finish certain parts of user stories. For example, to create a user account
we would allocate 5 days worth of time, after which we expect to have it
working. We make sure to establish contact between all of our members via
phone/text/Facebook so that we are all on the same page and aware of the
current state of our project. By doing so, we can account for any problems
that might arise in the midst of development and react accordingly.
Workflow For Version Control
We have been using github as our means of controlling version control
for this project. We've decided to work using a Centralized Workflow by
using a central repository to serve as the point-of-entry for all changes that
are made to the project. We simply commit any major changes to the
master branch of the repository.
When we initially began, we each cloned a copy of the central
repository to our computers and then we'd work on them on our own at
home or together during lab hours/weekly meet-ups. If there was
significant progress made on a particular part of the project
(implementation of the user database, improved login functionality, etc.)
we'd have the person push their local branch into the central repository so
that we could all view the changes and adjust our local versions of the
project accordingly.
For instance, in the last week our team was working upon improving
the login functionality of our bank application as well as creating a working
database that would allow us to store log-in information for multiple users.
We got most of our work done during the lab hours and during our weekly
Friday meeting, but we worked out a few kinks on our own at home.
Whenever we'd make an update that would improve the functionality of
the program, we would simply have those updates committed into the

WEEK 4

OCEAN'S 10

SHAMIM AHMED

central repository. From there, the rest of the team could view the same
changes and we could begin discussion on our next implementation for the
program and any particular problems that could arise.
Prior to our demo session with a TA on Monday, we meet up in the labs
and run our bank application through a handful of tests to ensure that it is
functioning correctly. We then double-check our git repository to make sure
that we have already committed the latest working version of the project
so that we may make any necessary changes.
Production and Release Cycle
We are currently following the timeline that has been provided to us as
a reference for what we should have finished on any given week. As a
group, we meet up on Mondays during lab hours to demo our most recent
implementations and discuss what we'll need to finish up by the end of the
week. We like to come out of the Monday lab section with a clear idea of
what our goals should be for the week, and we begin implementation on
our own throughout the week. We meet again on Fridays for about 2-3
hours, discuss any problems we've run into and what we still need to solve,
and then work on the project some more by tackling the major
components that are necessary for our next turn-in. Then, we spent parts
of the weekend tweaking and fixing any slight problems to the program it
until we have a working version ready for demo on Monday. Our release
schedule to this point has been:

Week

Goals

- Create user stories

- Research on existing
bank applications
1

- Figure out how/where

we will be storing our
project files, jot down a
list of programs that we
might use

Key Technical
Challenges
- We need an IDE that is
accessible for all of our
team members to work
through
- We need to familiarize
ourselves with
whatever programs we
choose to utilize

WEEK 4

OCEAN'S 10

SHAMIM AHMED

- Finish up user stories,

begin implementation
of the actual
application

- How do we create an
account?

- Make sure that we are

able to create an
account

- What platform would

be most efficient for
this project?

- Begin implementation
of log-in functionality
for the bank account
(find a means of storing
information; database)

- How do we match up
an account with the
necessary log-in
information?

- Improve on the
aesthetics of the
application, add more
security fields when
registering

- Where should we store

information?

- What if a user has

multiple accounts (i.e.
checking/savings)?
- What if a user forgets
their password/login?

- Have a basic working

version of the
application ready for
use on an Android
platform

- Implement
functionality that will
allow the user to add or
remove money from
their account as well as
view their balance

- How do we keep track

of these variables?

- Must allow for a

simple, efficient
interface that will make
it easy to move
around/view money in
the account

- What if a person has

multiple accounts?

- How do we access
these variables so that
they can be readily
accessible?

- How can we allow

multiple debit/credit
commands to an
account? Should there
be a transaction limit?

WEEK 4

OCEAN'S 10

5/6

7/8

9/10

SHAMIM AHMED

- Implement features
that would allow a user
to transfer money as
well as close the
account.

- How do we clear all of

a users information?
Should there be
multiple pages/security
checks before doing so?

- Fix up any prior issues

from the previous
iteration, further
improve our aesthetics.

- How can we transfer

money from one
account to another?
Install checks to make
sure that an inputted
amount can be
transferred/max
limit/etc.

- Implement account
penalties, interest and
allow a person the
ability to register
multiple accounts

- Need to keep track of

account balance,
maybe use a timer that
resets at a given point?

- Review our database

storage and figure out
how to integrate a
multiple account
feature

- Final stretch of the

project, focus upon
having everything
ready and a working
version of the complete
app.

- Interest needs to be
compounded monthly,
how do we deal with big
deposits/withdrawals?
- How can we allow a
single person the ability
to make multiple
accounts? Should we
link up pre-existing
accounts?
- Test to make sure that
it works on multiple
platforms (i.e. multiple
phones)
- Test a number of
cases that could arise

- Run the application

(i.e. negative balance,
through various tests to extremely high balance,
make sure that it is
transactions, etc.)
perfectly functional

WEEK 4

Use-Case Diagram

OCEAN'S 10

SHAMIM AHMED

WEEK 4

OCEAN'S 10

SHAMIM AHMED