FIDEConline 1

FIDEConline

CS457 Software Design

IP4: UML Development Practices
Design Implementation Proposal
FIDEConline
Edwin Ngwa
CTU Online
July 17, 2016

7/17/2016

FIDEConline 2

Table of Contents
Section 1: Introduction to the Implementation Proposal.............................................................3
Section 2: System Objectives and Constraints.........................................................................5
Section 3: Use Case and Activity Diagrams (UML)..................................................................7
3.1 Use Case Diagram.................................................................................................... 7
3.2 Activity Diagram..................................................................................................... 8
Section 4: Sequence Diagrams............................................................................................ 9
4.1. View Account Balance.............................................................................................. 9
4.2. Processing a Loan Request...................................................................................... 10
4.3. Account Deposit................................................................................................... 11
Section 5: Requirements Traceability matrix.........................................................................12
Section 6: Verification and Validation Plan...........................................................................13
6.1 Organization......................................................................................................... 13
6.2 Responsibilities..................................................................................................... 13
6.3 Methodology........................................................................................................ 14
6.4 Tools and Techniques.............................................................................................. 14
6.5 Schedule.............................................................................................................. 15
6.7 Resources............................................................................................................ 16
Section 7: Summary....................................................................................................... 17
Design documents are mostly visual diagrams used to translate the requirements into a graphical
representation and models of how the system will work. It enables the developers to communicate and
show to shareholders and other peers the interaction between the different elements of the system, the
sequence of activities and events, prototypes of the user interfaces deign, the entity relationship scheme of
the database and other the functionality of components............................................................17
References................................................................................................................... 18
https://users.ece.cmu.edu/~koopman/des_s99/verification/#verification_techniques.........................18

7/17/2016

FIDEConline 3

Section 1: Introduction to the Implementation Proposal

FIDEConline is a web based application to enable customer access to internet banking services
offered by FIDEC Financials. This application will provide a secure web interface for users to
login, view checking and savings account information and also be able to apply online for
consumer loans.
FIDEC Financials is a startup microfinance institution headquartered in Yaound, Cameroon.
With an estimated budget of one million dollar, it is currently staffed by 15 employees working
from the main office and five others at a geographically distant branch. FIDEC current IT
infrastructure revolves around a client-server architecture system extended by a virtual private
network to enable a secure and reliable sharing of resources between the remote site and the
main office. Two redundant servers providing database and file sharing services are located at
the main office. Four IT personnel working provide maintenance and support for a legacy
banking software which currently prevents the company and its customers to take full advantage
of the online banking experience and to deliver many of the digital promises already mainstream.
All banking transactions are currently made though the tellers at the counter.
To make the most of the opportunity to modernize, FIDEC current needs is to transition to a
system that will enable the smooth migration of its data and software services to support sales
and online account management with possibilities for a mobile applications in the future. The
deployed system should also offer a strong security software suite to protect the confidentiality
and integrity of sensitive business data as well as capabilities for disaster recovery and active
monitoring.

7/17/2016

FIDEConline 4

The purpose of this project is to create a design Implementation Proposal translating the
completed Software Requirement Specifications into a blueprint to allow for software
development to proceed with an understanding of what is to be built and how it is expected to
build (McEllrath, 2007).

7/17/2016

FIDEConline 5

Section 2: System Objectives and Constraints

Tasked with unearthing the functional issues plaguing the current system and disabling
FIDEC Financials in pursue of its business objectives, we developed the below table to
recapitulate how we shall convert these problems into solutions including the various elements to
be considered for conformance to standards and best practices.
Description of

Objectives to resolve

Elements to be

Functional Issues

problem

considered

The legacy banking software is a

desktop application requiring presence
within the local network to access and
manage customer accounts.
Each branch has a separate system. To
perform an operation on behalf of a
customer whose account was located in
another branch, the teller is required to
make a phone call for verification
Bank records have to be transported
from the branches to the main office for
accountants to aggregate or consolidate
reports for end of year declarations and
other reporting requirements
Loan application took on average 14
business days to be processed due to the
communication distance between a
branch and the final approving authority
located at the main office

The current architecture is a LAN/WIFI

network where communication between
nodes is not secured.
There is no mechanism to ensure the
confidentiality, integrity and availability
of information

7/17/2016

Current design is an application with a

web interface enabling accessibility
regardless of location for all users
connected to the corporate network
The proposed design will offer a
centralized database unifying all records.
Tellers will be able to view the account
information of all customers and perform
transaction without additional delays
We will integrate tools compatible with
money management and offering the
possibility to automatically generate the
commonly needed reports
Customers will be able to apply for loan
online using an interface with error
checking capabilities and the generated
application with justifying documents
attached will automatically be forwarded
through the approving chain for faster
processing and approval
The proposed architecture shall implement
cryptographic techniques to negotiate and
establish a secured layer connection
between the browser and the server
Access control and authentication best
practices shall be implemented to segment
information on a need to know basis and
protect access to critical information

Accessibility

Effectiveness
Performance

Efficiency

Transaction
speed

Security

Security

FIDEConline 6
Customer on the go were not able to
access account information let alone get
money from the nearest ATM

Maintenance of the current multiple

system is time consuming exercise
requiring a system administrator in each
branch
The current system cannot be upgraded
or modified to integrate a web interface
In addition to non-conformance to
applicable standards, a recent third party
audit discovered many departures from
established practices in the legacy
system

7/17/2016

A customer interface will integrate an

intuitive interface to accommodate
customer account inquiries. Interfacing the
system with ATM is out of scope and will
only be addressed in a future generation of
the project
The proposed design offers a unified
management interface to monitor and
manage the system from a central location
with less staffing overhead
Our object oriented approach favors the
reusability of objects to create new
components more effectively
Verifying and validating requirements to
ensure compliance with acceptable
standards and best practices is a central
component of our development
methodology

Convenience

Constraints

Maintainability
Serviceability
Cost effective
Scalability, ease
of modification

Conformance

FIDEConline 7

Section 3: Use Case and Activity Diagrams (UML)

3.1 Use Case Diagram

7/17/2016

FIDEConline 8

3.2 Activity Diagram

7/17/2016

FIDEConline 9

Section 4: Sequence Diagrams

4.1. View Account Balance
Precondition: The bank customer has successfully negotiated and established an encrypted
communication channel with the system through a secure socket layer

Post-condition: A submenu is presented to the user with options to print/save the requested
information and/or return to the main menu.

7/17/2016

FIDEConline 10

4.2. Processing a Loan Request

Precondition: The requested loan application information must be entered, stored correctly
and be retrieved from the database.

Post-condition: The external electronic mail module is enabled and should automatically
forward notifications to the customer.

7/17/2016

FIDEConline 11

4.3. Account Deposit

Pre-condition: The bank Teller must be login into the system with privileges to perform
account transactions

Post-condition: A copy of the transaction receipt must be printed automatically for the customer.

7/17/2016

FIDEConline 12

Section 5: Requirements Traceability matrix

ID

FIDEC needs

Functional Requirements

Architectural/Design Elements

Implementation

Test
Cases

U1

An operating environment for

the centralized administration
of customer accounts

FR.1 Client-server
architecture

Operating
network
Environment

TBD

U2

The environment shall protect

the CIA of information

FR2: Establish a secure layer

between the client and server

Security
Protocols

TBD

U3

User shall be authenticated

before login into the system
System shall offer an intuitive
web interface

FR3 :Authentication using

login credentials
FR4 : Access account
information

Login Module

TBD

Web interface

TBD

Customers should be able to

view account balance
apply for a loan online

FR5: Submit application

Network and deployment

diagrams for the overall view of
the system architecture and its
structural configuration
Use cases, Access controls, PKI
management and process flow
diagrams
Use case, process flow diagrams
for user login/ access control
Use cases , mockups, wireframes
employees and customer area
pages design to illustrate the User
interface design

U7

A centralized database shall be

used to store all information

FR6 Relational database

FR8: Persistent connection

Database
Module

TBD

U8

The user should be able to

query the database

FR9 respond to queries

U9

The users shall be able to view

response to the specific queries
Bank Tellers shall be able to
perform account transaction

Data flow and Entity

Relationship Diagram to model
the organization of data within
the database and its interaction
with the various objects
Class diagram to describe the
structure of a system to be created
and how the objects will be
manipulated

Develop
pseudocodes
and source
code package

TBD

U4
U5
U6

U10

U11

Account Managers should be

able to create accounts

U13

review loan applications

U14

Loan Officers should be able to

process application

U15

Bank Manager to make loan

decisions

7/17/2016

FR10 Show Results

FR11:Make withdrawal
FR12 Make deposits
FR13. Record transactions
FR14. Generate reports
FR 16 Print reports
FR17. Create account types
FR19.View Customer history
FR20 Make recommendations
FR21. Notify Loan officer
F22.Get Customer credit
ratings
F23. Make recommendation
F24.Notify Bank Manager
FR25. Approve loans
FR26. Reject loans
FR27. Notify Others

Use case, activity, sequence and

other behavioral diagrams to
show objects interaction and the
process flow

TBD

TBD
Structural and behavioral
diagrams to model the business
processes and information flow
for the loan management module

TBD

FIDEConline 13

Section 6: Verification and Validation Plan

The goal of the overall Verification and Validation (V&V) plan is to check whether
the functional requirements specified and applicable standards were fully addressed in our design
documents (verification) and to determine that an application built based on the design will
correctly implement the business rules of FIDEConline (validation). The elements described
below will establish the essential building blocks to enable a successful deployment of our V&V
plan.
6.1 Organization
The V&V activities will fall under the umbrella of our Quality Assurance (QA) team
augmented by independent assessors to enable an objective review of our processes and
products. Selected members from teams who are not directly involved with the design can also
assist the QA team during peer reviews. A Quality team will be managed by a senior developer
with practical experience in software testing and project management.
6.2 Responsibilities
-

The Project Manager oversees the design review and ensures the required resources are

allocated
The QA Manager leads the review process and ensures the QA team follows established

procedures to certify that system requirements are adequately met

The QA Manager is also directly responsible to the project manager for defining the test
plan, develop test criteria, executing the plan and for checks to verify and validate the
design as well as other activities of the project.
QA Unit:

7/17/2016

FIDEConline 14

Ensure the initial design and system drawings satisfies the stated product requirements

and can be used to produce detail design documents

Ensure the level of detail provided in the final design documents are sufficient enough to

fully implement the source code needed to build the software

Verifies compliance of each design output with applicable standards and best practices
Develop and maintain matrices to check (validate) and trace back the relationships
between a design and the functional requirements
The Design Team

Ensure all identified issues in the reviews and audit reports are resolved
Document and keep a track of all changes, correction and modifications as they occur

6.3 Methodology
Trying to know if the design is suitable without having to build the system first is a daunting
task which will hope the selection of our methodology will help alleviate. Following the
recommendations of the Software Engineering Institute (SEI, n.d.) at the Carnegie Mellon
University, our methodology will combine a blend of a stakeholder-centric, scenario-based,
architecture evaluation method and an active design review (ADR) of design specifications and
the use of some static testing technique for verification and formal methods for validation
6.4 Tools and Techniques
Active design Review (ADR): ADR is technique which requires the engagement of stakeholders
to get their buy-in viability of the design and the active participation of developers who will be
involved in the actual coding to determine if the design is suitable for the overall system being
developed. This method consists of using the design in a series of scenarios to assess if it solves
the problem stated in the defined requirements. The QA facilitators will help uncover the

7/17/2016

FIDEConline 15

inconsistency and get the designers to refine the product until everyone can agree that a product
based on this design can be implemented (coded) efficiently and will satisfy the need of the
customer.
Static Testing: As opposed to dynamic testing, static testing is verification technique that does
not require the system to be operational. In our V&V plan, static testing will include:
-

Consistency testing to analyze the design artifacts for correct syntax, correct parameter
matching between procedures(SEI,2011) and an effective translation of the requirements

of the requirements
Traceability Analysis to ensure the design can be traced backwards to the stated

requirements and the requirements can be traced forward to the design description
Measurement techniques to evaluate the properties of the design to ensure they are
understandable, well structure and not prone to errors that will affect its implementation

Formal methods: This validation technique will come to play at the end of the design process. It
will involve using mathematical and logical methods to investigate whether the design documents
correctly express the business logic required to implement the intended functionalities of the
software.
6.5 Schedule
The V& V processes will around four main activities: internal, external, active and formal
reviews
-

The internal review process will consist of periodic checks, audits, walkthroughs and peer
reviews as the work unfolds to identify inconsistencies

7/17/2016

FIDEConline 16

Independent assessors separate from the internal organization team may be required to
verify and test critical segments of the design for their completeness and offer an outside

and fresh perspective to a subtle problem as part of external reviews.

Formal reviews which will be held at the end of each design phase to assess the overall

completeness, correctness and traceability of the design

Active Design Review will be scheduled to facilitate the brainstorming of ideas to improve
the quality of a design as needed

6.7 Resources
The human resources needed for the V& activity will be allocated by the program manager and
selected from a pool of developers with years of experience in software testing. A budgetary line
will be approved and set aside for the acquisition of the logistics (hardware, software, independent
consultants) needed to execute the plan

Section 7: Summary
Design documents are mostly visual diagrams used to translate the requirements into a
graphical representation and models of how the system will work. It enables the developers to
communicate and show to shareholders and other peers the interaction between the different

7/17/2016

FIDEConline 17

elements of the system, the sequence of activities and events, prototypes of the user interfaces
deign, the entity relationship scheme of the database and other the functionality of components.

References

7/17/2016

FIDEConline 18
McEllrath, R. (2007). XML Legal Document Utility Software Design Document. Retrieved from
https://www.oasis-open.org/committees/download.php/24846/ExampleSEI- Software Engineering Institute (n.d). Active Reviews for Intermediate Design. Retrieved from
http://www.sei.cmu.edu/architecture/tools/evaluate/arid.cfm

https://users.ece.cmu.edu/~koopman/des_s99/verification/#verification_techniques

7/17/2016