Академический Документы
Профессиональный Документы
Культура Документы
FIDEConline
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
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
Objectives to resolve
Elements to be
Functional Issues
problem
considered
7/17/2016
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
7/17/2016
Convenience
Constraints
Maintainability
Serviceability
Cost effective
Scalability, ease
of modification
Conformance
FIDEConline 7
7/17/2016
FIDEConline 8
7/17/2016
FIDEConline 9
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
Post-condition: The external electronic mail module is enabled and should automatically
forward notifications to the customer.
7/17/2016
FIDEConline 11
Post-condition: A copy of the transaction receipt must be printed automatically for the customer.
7/17/2016
FIDEConline 12
FIDEC needs
Functional Requirements
Architectural/Design Elements
Implementation
Test
Cases
U1
FR.1 Client-server
architecture
Operating
network
Environment
TBD
U2
Security
Protocols
TBD
U3
Login Module
TBD
Web interface
TBD
U7
Database
Module
TBD
U8
U9
Develop
pseudocodes
and source
code package
TBD
U4
U5
U6
U10
U11
U13
U14
U15
7/17/2016
TBD
TBD
Structural and behavioral
diagrams to model the business
processes and information flow
for the loan management module
TBD
FIDEConline 13
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
7/17/2016
FIDEConline 14
Ensure the initial design and system drawings satisfies the stated product requirements
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
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