Вы находитесь на странице: 1из 53

RISK MITIGATION, MONITORING, AND MANAGEMENT PLAN

1.0 INTRODUCTION
1.1 SCOPE AND INTENT OF RMMMA ACTIVITIES
1.2 RISK MANAGEMENT ORGANIZATIONAL ROLE
2.0 FUNCTIONAL DATA DESCRIPTION
2.1 RISK TABLE
21.1 DESCRIPTION OF RISK M
21.2 PROBABILITY AND IMPACT FOR RISK M

3.0 RISK MITIGATION, MONITORING AND MANAGEMENT

3.1 RISK MITIGATION FOR RISK M


3.1.1 PRODUCT SIZE
3.1.2 BUSINESS IMPACT
3.1.3 CUSTOMER (USER) RISKS
3.1.4 PROCESS RISKS
3.1.5 TECHNOLOGY RISKS
3.1.6 DEVELOPMENT RISKS
3.1.7 EMPLOYEE RISKS (TEAMMATES)

3.2 RISK MONITORING FOR RISK M

3.2.1 PRODUCT SIZE

3.2.2 BUSINESS IMPACT

3.2.3 CUSTOMER (USER) RISKS

3.2.4 PROCESS RISKS

3.2.5 TECHNOLOGY RISKS

3.2.6 DEVELOPMENT RISKS

3.2.7 EMPLOYEE RISKS (TEAMMATES)

4.0 SPECIAL CONDITIONS

Accounts Payable and Receivable Page 1


1.0 Introduction

This section gives the overview of Risk mitigation, Monitoring and Management Plan
for the Accounts Payable and Receivable (A/P and A/R).

1.1 Scope and intent of RMMM activities

1.1 The Team wants the Accounts Payable and Receivable system to lessen the
difficulties in tracing error, adjusting the entries and the managing information.
To be safe the team should have a risk management plan to minimize the
problem in risk and to know how to handle any risk that can encounter in
Accounts Payable System.
To avoid risk in Accounts Payable and Receivable system both developer and
client must work together.
The client must know the process, the function in the system and to give their
suggestion, changes, opinion, and the approval in the changes in project.

1.2 Risk Management Organizational Role

1.2 All Team members have a responsibility of maintaining the risk. If all member are
participated and focus to all the details during the early phase of the software
development many risk can be avoid.
 Software development can avoid having risk by double checking of the
team leader in the schedule of meeting with the client and with the team
member.
 Customer can avoid risk by providing all necessary information that can
help. The Team member must Create survey to know and to get
information in the satisfaction of customer
 Client can avoid the risk by attending all meeting. One of the member have
to meet the customer to discuss the function and to know the suggestions
of client.

Accounts Payable and Receivable Page 2


2.0 Risk description

The team may encounter risk while developing this project. When a data
Gathering and develop there is a chance that the team will get wrong
information. The implementation of idea and transferring to reality base are
difficult the project may incorrect it can cause a headache for your business and
your customer.to avoid the risk in implementation the team must establish
alignment between its strategic goal and IT-related.

2.1 Risk table

the following table define the different risk and the impact of developing a project the
affectivity and the fact.

2.1.1 Description of Risk m

Business Impact Risk

The system may fail to give the business wants and may leave to an impact to their
transaction with the clients.

Accounts Payable and Receivable Page 3


Customer Risk

When the clients may be disappointed if the software fails to give the needs of the
customer

Development Risk

With lack of equipment the software may fail its development and it may take time to the
software development team to have their resources and the software development may
fail greatly.

Employee Risk

The employee may not have the ability and experience to have working software or they
have no time to use the software faster.

Process Risk

The software may not pass the standard that the customer set and may leave to a poor
performance of the software.

Product Size

The development team may not get the real scope or the budget of the team may be
small or large.

Technology Risk

The development team may not have the new technologies to keep up with the current
technology.

Accounts Payable and Receivable Page 4


2.1.2 Probability and impact for risk m

Category Risks Probability Impact

Lack of traini
Employee Risk 30% 1
ng and experience

Process Risk Low product quality 20% 1

Where size estimate could be


Product Size 35% 2
wrong
Development
Insufficient resources 25% 2
Risk

Customer Risk Customer may fail to participate 15% 3

Technology
Obsolete technology 10% 2
Risk

Business Risk Product may harm the business 10% 3


Table – Risks Table (sorted)

Impact Values Description

1 Catastrophic

2 Critical

3 Marginal

4 Negligible

Accounts Payable and Receivable Page 5


3.0 Risk Mitigation, Monitoring and Management

The Development team can evaluate analyze the detail and descried the Risk
Mitigation, Monitoring, Management all possible risk that the team can encounter. It is to
avoid the risk in mitigation, monitor and manage.

3.1Risk Mitigation for Risk m

The Development team can identified the possible solution to minimize and avoid the
risk that encounter’s in doing the project and conduct a plan to avoid it.

3.1.1 Product Size

It is concern in the estimations of the system code and other software needed. The
overestimation and underestimation of code can cost fatal error and size of the
software. To avoid it the Development team can overestimate a little in the code and
size of software. if the system finish early the team member can limit the risk of system.

3.1.2Bussines Impact

It is concern in the quality of the system that created by the team. Having difficulties in
wants or the satisfaction of the business in their transaction can have error information.
To avoid it the Development team must be ask the user and the client what is their
needs to business environment. If they’re a problem that team encounter the team can
fix it with proper information came from the client and user.

3.1.3Customer (User) Risk

It is concern in the user’s presence and need. The fail in participation of the user in
gathering information cannot recognize error. to avoid it the Development team must
spend time to know the better option in creating project that satisfy their needs.

Accounts Payable and Receivable Page 6


3.1.4 Process Risk

It is concern in a quality and standard of the process and procedure. To meet the
standard of the customers with high quality. To avoid it Development team must create
guideline in the standard and quality of the system.

3.1.5 Technology Risk

It is concern in the technology .The fast innovation of technology. To avoid it the


Development team must research the latest software and hardware.

3.1.6 Development Risk

It is concern in developing process. The lack of equipment or materials. To avoid it the


Development team must plan budget the cost that required in producing the project.

3.1.7 Employee Risk (Team member)

It is concern to the Employee Knowledge and willingness to help. The lack of


Knowledge and willingness of the Employee to help. To avoid it the Development team
must know all the process, procedure , research and share to one another to meet the
goal.

3.2 RISK MONITORING FOR RISK M

In this section the Project team will identify the condition and purpose to monitor to
determine whether risk m is become more effective or less effective.

3.2.1 Product size

To monitor the risk, the Project team will keep tracking the amount of all function of the
project in the entire development for a future needs. This will tell if the project may come
up with risk in future. The project team must track the codes and the required of the
project.

3.2.2 Business Impact

Accounts Payable and Receivable Page 7


In monitoring the risk, the Project team will setup user’s meeting to show and
instruct in what is the process and procedure of the project. The Project team must have
a meeting every week in the user to show the improvement of the project.

3.2.3 Customer (User) Risk

To monitor this risk, The Project team must monitor the success of the meeting
by tracking the attendance of the user’s. If the meeting is having low in attendance, The
Project team may use a attendance form of the user’s.

3.2.4 Process Risks

To monitor the risk, the Project team must review and double check each other’s
works to achieve better quality. Setting a guideline’s and guides each other to produce
the brilliant ideas.

3.2.5 Technology Risk

to monitoring this phase the Project team have to know the latest technology and
keep on knowing the weakness of the new technology. It helps the Project team to get
and to build more efficient technology.

3.2.6 Development Risks

To monitoring this phase the Project team must know the quality and effectively
of the tools that they’re going to use in developing the project. The Project team must
know the best in choosing tools in developing.

3.2.7 Employee Risk (teammates)

Monitoring in this phase is most important of all the Project team must work in
each of their ability but if there members having problem in he/she’s task or work the
other must help their member .the Project team must share their knowledge and
teaching each other.

3.3 Risk Management for Risk m

In this section the Project team identify different risk in developing project and try
to create a solution on how to manage those risks.

Accounts Payable and Receivable Page 8


3.3.1 Product size

If the process having problem in overestimation and underestimations after


monitoring Phase the Project team must work hard and take more man hours.

3.3.2 Business Impact

If there is error that comes up, the user must provide the correct information to fix
the error by conducting meeting and more conversation to plan and meet the desired
project.

3.3.3 Customer (User) Risk

If the users are not interested or not attending meeting the Project team must
conduct a survey to gather information or making an interview questioner.

3.3.4 Process Risk

If the problem is quality and standards the quality management plan revise in the
manage plan or search the work of the member that not meet the quality and standards.

3.3.5 Technology Risk

In developing stages, if there are latest technology that can connect and use in
the project that can’t cost major revise in the project.

3.3.6 Development Risk

If the budget of the Project team are not enough the phase or the procedure of
the project must stop in a moment and reschedule in working of that phase.

3.3.7 Employee Risk (Team member)

in this phase the monitoring and the managing of this risk is same, the Project
team must work in each of their ability but if there members having problem in he/she’s
task or work the other must help their member .the Project team must share their
knowledge and teaching each other.

4.0 Special Conditions

Accounts Payable and Receivable Page 9


Software Configuration Management Plan
1.0 INTRODUCTION
1.1 SCOPE AND INTENT OF SCM ACTIVITIES
1.2 SCM ORGANIZATION ROLE
2.0 SCM TASKS
2.1 IDENTIFICATION
2.1.1 Description
2.1.2 Works products and documentation
2.2 CONFIGURATION CONTROL
2.2.1 Description
2.3 VERSION CONTROL
2.3.1 Description
2.3.2 Increasing Version Number
2.3.3 Work Products and Documentation
2.4 CONFIGURATION STATUS ACCOUNTING (CSA)
2.4.1 Description
2.4.2 Work Products and Documentation
3.0 SOFTWARE QUALITY ASSURANCE OVERVIEW
SCOPE AND INTENT OF SQA ACTIVITIES
REVIEW AND AUDITS
3.1 Generic Review Guidelines
3.2 Formal Technical Reviews
3.3 SQZ Audits

Accounts Payable and Receivable Page 10


3.4 PROBLEM REPORTING AND CORRECTIVE ACTION/FOLLOW-UP
3.4.1 Reporting Mechanisms
3.4.2 Responsibilities
3.4.3 Data Collection and Valuation

SOFTWARE CONFIGURATION MANAGEMENT PLAN

1.0 Introduction

In software developing phase the development team always encounter changes to


the 1st plan. In that case Software configuration management plan is develop to
identify the changes, control the changes, implement correctly and to report to other
Members.

1.1 Scope and Intent of SCM Activities

The purpose of SCM is to create report and track the any changes made in the 1st
plan. it is use in planning, implementing and controlling the flow of information and
the finished project for ultimate distribution to the customer.
And help the development team to know what to be changes and easy solution to
changes for minimizing the problem

1.2 SCM organizational role

All member of the development team must agree or accept the responsibility for
software configuration management. If one of the member makes a changes the
member must report to other to implement, this will reduce the confusion between

Accounts Payable and Receivable Page 11


the team members regarding the changes with the project and also inform the user
or client about the changes and ask for he/she’s approval.

2.0 SCM Tasks

In this section the development team will identify the SCM tasks and assign the
responsibility of each member and inform the user or client about the changes.

2.1 Identification

It describes and identify for the software configuration management plan.

2.1.1 Description

 Identify changes

In developing phase some member suggest changes in the software then


the team must work together on the suggested and identify if it is necessary
and justified.

 Approval

Any member can’t change the software without consult or approval of the
other member, this can cost technical problems for the software. To avoid it
the team must have a meeting every before the end of the day.

 Ensure that changes is being properly implemented

We want to have team members looking over the changes. Since all
members are work together there are one member how monitor the
implementation and to finalize the changes.

 Document the change.

Accounts Payable and Receivable Page 12


Changes has to be documented from the time of suggestion to the finalized,
to change, the member must ask to the other member. to approve, all
member must agree.

2.1.2 Work products and documentation

 Identify changes
Once the changes is identify a changes will work together and implement.
 Control changes
After the changes, the team will evaluate if the suggested changes are
necessary to do.
 Ensure that change is being properly implemented
 Document the change.
Once the changes are approved we will document.

2.2 Configuration Control

2.2.1 Description

The team will be taken in order to control changes.

 Suggest change
 Evaluate change by the team
 Change report to the other member
 Finalizing the decision in change made.
 If the change is approved
1. Define error
2. Make necessary changes
3. Apply SQA activities
4. Apply testing activities
5. Rebuilt the software

Accounts Payable and Receivable Page 13


6. Distribute the software
 If the change is not approved
1. The suggested changes will be mark not approved.

2.3 Version Control

2.3.1 Description

Result of changes, the version of the number of various modules will be increased
accordingly.

2.3.2 Increasing Version Number

A changes request is filed; a change report will be created. After the change is
finalized, it will be document.

<Major update>.<Minor update><Bug fix>

Bug Fix

If the bug fix has been done on the module the bug fix portion of the version number will
be increased. The number of user visible bug fix will also affect when the bug fix
number is increased.

If functionality is added to the module that will increase the user-friendliness /


performance but does not change the way a function //interface work, the minor update
number may be Minor Update increased.

Accounts Payable and Receivable Page 14


Major Update

We do not foresee any change in major version number. The module will be labeled as
version 2.

2.4 Configuration status Accounting (CSA)

The team different way to communicate with the team and to inform others those
changes may concern.

2.4.1 Description

The team will use to communicate with other members or the people associated with
software development.

 Online Communications

The team can communicate through social network in conversation to the project,
opinion, suggestion and reports, and to contact the client.

 Verbal Communication

The team must communicate verbally to easy understanding and to determine


the idea and to justify their opinion.

3.0 Software Quality Assurance Overview

The description of the methods for software quality assurance please refer to
Software Quality Assurance Plan (SQA).

SQA focus on the function of software quality that assures that the standards,
processes, and procedures are appropriate for the project and are correctly
implemented.

Scope and intent of SQA Activities

The objectives of SQA are:

Accounts Payable and Receivable Page 15


 A quality Management approach
 Control of software documentation and the changes made to it
 Small to Zero Defects After Installation
 Customer Satisfaction
 Well Structured

Reviews and Audits

A formal technical review (FTR) is a software quality assurance activity that is


performed by software engineers. The objectives of the FTR are:

(1) To uncover errors in function, logic, or implementation for any representation of


the software;
(2) To verify that the software under review meets its requirement;
(3) To ensure that the software has been represented according to predefines
standard;
(4) To archive software that is developed in a uniform manner;
(5) To make project more manageable.

3.1 Generic Review Guidelines

ISO 9001 is the quality assurance standard that applies to software engineering. The
following are the 20 requirements delineated by them. And the team are try to follow
them as our quality assurance plan.

- Management Responsibility
- Quality system
- Contract review
- Design Contract
- Document and Data control
- Purchasing
- Control of customer Supplied Product
- Product Identification and Trace Ability

Accounts Payable and Receivable Page 16


- Process Control
- Inspection and Testing
- Control of Inspection Measuring, and Test Equipment
- Inspection and Test Status
- Control of Nonconforming Product
- Corrective and Preventive Action
- Handling, Storage, Packaging, Preservation, and Delivery
- Control of Quality Audits
- Training
- Servicing
- Statistical techniques

3.1.1 Conduction a Review

There are two kind of reviews well do, review case with the client and the other
case with other teammates.

The changes that affect the client performance when they use the software. The team
have to consult them first but before consulting to the client the team must agree in
changes of software.

3.1.2 Role and Responsibilities

As stated in 1.2, SQA Organization Role, All members must work together and
use Software Development Lifecycle (SDLC) step by step process:

3.1.3 Review Work Product

Each member must create report, and the problems encountered, this will help the
team in documentation and creating help menu.

In meeting to the client, the team have to record the answer of the client in the interview
but before that the team must create the question and gather information. Request
opinion on the current work and schedule the next meeting.

3.2 Formal Technical review

Here are the FTR that the team will conduct during the software process:

Accounts Payable and Receivable Page 17


- Walkthroughs
- Inspections

After each form (interface) we design, we’ll do the test on the interface using block box
testing method. And for each week, the team will ask the team meats to do a inspection
on the interface, do a walkthroughs of all the interfaces.

3.2.1 Description of review Walkthroughs

3.2.1.1 Description and Focus of Review

Reviews mainly focus on the integrations of the part of the design (such as
interfaces, form, and database.).

3.2.2 Description of review Inspection

3.2.2.1 Description and Focus of Review

Reviews mainly focus on the correctness of the parts that we designed. Usually
allow the other two team-members to do a private test, without the designer’s interrupt.

3.2.1 System Specification Review

System specification usually changed after each weekly meeting, after each
meeting with our client. Most of the system designs have been settle down.

3.2.2 Software Project Plan review

The purpose of Software Project Plan is over look of the whole project. for more
information, please see the document titled “System Project Plan”.

3.2.3 RMMM Review

RMMM, Risk Mitigation, Monitoring & Management, is use to prevent, monitor,


and manage the risk. For more information, please see the document titled “RMMM”.

3.2.4 Requirements Reviews (Models, specification)

Accounts Payable and Receivable Page 18


Software requirement stated the data requirement, specifications. For more
information, please see the document titled “Requirement Plan”.

3.2.5 Data Design Review

Data design document is about the data flow between each form (interface), and
forms to the database. For Data Design Flow please see the document titled “Data
Design Review”.

3.2.6 Architectural Design Review

The Architectural Design document is about the whole project design, layout and
data flow. For Architectural Design, please see the document titled “Architectural
Design”.

3.2.7 Interface (GUI)

Up on the request of the client, team will redesign the interface from previous
version.

3.2.9 Code Review

3.2.10 Test Specification Review

3.2.11 Change Control Review and Audits

3.3 SQA Audits

 The team member will have a weekly report on their individual performance for
the past week. Any problem, question regardless on the performance of the
other team members will also note there.
 Any change to the project that can affect will be consult to other member before
changing the project.

3.4 Problem Reporting and Corrective Action/Follow-up

Accounts Payable and Receivable Page 19


These sections describe problem reporting mechanisms that occur as a
consequence of the FTRs that are conducted and the means for corrective action and
follow-up.

3.4.1 Reporting Mechanisms

The report mechanics of the project, the team must create a function that use the
web-based system or an information like contact no. and email That the client can ask
or report the problem, the team must teach the client on how to use to reporting
function.

3.4.2 Responsibilities

All members of the team will be responsible for something ,Since the team use the
SDLC model, and have a leader that assist other member. But for the decision all
member must agree before to make a decision.

3.4.3 Data Collection and Validation

The properly conduct software quality assurance, data about the software
engineering process should be collected, evaluated, and disseminated. Statistical SQA
help to improve the quality of the project and the software process itself.

During each meeting, the team will present the work to the client and teach the function
and how to use, also ask the opinion of the client about the project and present different
option, and ask for the approval of the client.

Accounts Payable and Receivable Page 20


Software Quality Assurance Plan
I. TABLE OF CONTENTS
1.0 INTRODUCTION
1.1 SCOPE AND INTENT OF SQA ACTIVITIES
1.2 SQA ORGANIZATION ROLE
2.0 SQA TASKS
2.1 Task Overview
2.2 Standard, Practices and Conventions (SPC)
2.3 Resources
3.0 REVIEW AND AUDITS
3.1 Generic Review Guidelines
3.2 Formal Technical Review
3.3 SQA Audits
4.0 PROBLEM REPORTING AND CORRECTIVE ACTION/FOLLOW-UP
4.1 Reporting Mechanisms
4.2 Responsibilities
4.3 Date Collection and Valuation
4.4 Statistical SQA
5.0 SOFTWARE PROCESS IMPROVEMENT ACTIVITIES
5.1 Goal and Object of SPI
5.2 SPI Tasks and Responsibilities
6.0 SOFTWARE CONFIGURATION MANAGEMENT AND OVERVIEW
7.0 SQA TOOLS, TECHNIQUES, METHODS

Accounts Payable and Receivable Page 21


SOFTWARE QUALITY ASSURANCE PLAN
1.0 Introduction

In this section the overview of the Software quality Assurance Plan (SQA) for the
Accounts Payable and Receivable (A/P and A/R)
SQA focus on the function of software quality that assures that the standards,
processes, and procedures are appropriate for the project and are correctly
implemented.

1.1 Scope and intent of SQA Activities

The objectives of SQA are:

 A quality Management approach


 Control of software documentation and the changes made to it
 Small to Zero Defects After Installation
 Customer Satisfaction
 Well Structured

1.2 SQA Organization Role

All members must work together and use Software Development Lifecycle (SDLC) step
by step process:

Accounts Payable and Receivable Page 22


Software Quality Assurance (SQA) is a formal process for evaluating and
documenting the quality of the work products produced during each stage of the
Software Development Lifecycle (SDLC). The primary objective of the SQA process is
to ensure the production of high-quality work products according to stated requirements
and established standards. The word assurance means „guarantee‟. So the Quality
Assurance role is to guarantee that the product is of high quality. at specific times during
product implementation. Upon reviewing, the SQA team’s duties will be to evaluate the
software at its current development stage and recognize any defects in the subsequent
stage (design or implementation).

2.0 SQA Tasks

The main task of Software Quality Assurance is to examine the overall software
development process and to create and enforce standards and methods to improve
it with the goal of preventing bugs from ever occurring. With this definition, it is
imperative that the SQA helps an organization in continuous performance
improvement and strive for perfection

Here are the tasks that the development team have for the SQA:
- Voting system
- Close Contact with the client
- Extensive detail design
- Research on the subject

1.2 Task Overview

Accounts Payable and Receivable Page 23


Task that described above will cover the systems quality Controlling, Saving, Design,
Time & Cost, Minimize Error, Problem Tracking and Data Flow.

Voting System

The development team have a leader but not all the leader is always right, so the
development team use voting system to make decision for the changes of the project.

Close Contact with the client

The Development team must conduct a meeting to their client or user to gather
information and know the function of the project.

Each meeting development team must discuss the problem that they encounter in
developing the project.

Below is the table for the meeting.

Meeting Date Discussion /Subject Time


Project Background 9: 00 am to 7:00 pm
July 07,2014 Gather information
Interview to Client
Present draft of document 9: 00 am to 7:00 pm
July 12,2014 Present different option
Interview to client
July15 ,2014 Present the flow 1: 00 am to 6:00 pm
Interview to client
July 25,2014 Gather more information 9: 00 am to 7:00 pm
Interview to client
Present the changes 3: 00 am to 6:00 pm
August 5,2014 Interview to client
August 27,2014 Ask for the approval of 1: 00 am to 5:00 pm
changes
Interview to client
To be scheduled Present draft design To be scheduled
Present design Option
Interview to client
To be scheduled Present draft design To be scheduled
Present design Option
Interview to client
To be scheduled Present the Final Version To be scheduled

Extensive detail Design

Accounts Payable and Receivable Page 24


The last team who work on the Accounts Payable and Receivable version use
Visual Basic to implement the software. Even the client request the Development team
don’t have to use the same implementation method.

After Development team define the method, the Development team will use to design
the project, and start design and creating interface for the software.

The development team use their gathered information and use the suggested design of
your client and also suggests a design to the client and present a draft design to them.

The creating of interface and coding phase do as a same time to minimize the mistake
in miscommunication to the member create the design and the one how create the
code.

Research on the Subject

Version 1 has lot bugs or Unknown error. After Inspection and test on the
software not all of the function of version 1 have to changes development team
Enhance the version 1 to make user or client to get their satisfaction and always
changes the design to make it more nice and new in the eyes of the customer.

2.3 SQA Resources

3.0 Reviews and Audits

A formal technical review (FTR) is a software quality assurance activity that is


performed by software engineers. The objective of the FTR are:

(6) To uncover errors in function, logic, or implementation for any representation of


the software;
(7) To verify that the software under review meets its requirement;
(8) To ensure that the software has been represented according to predefines
standard;
(9) To archive software that is developed in a uniform manner;
(10) To make project more manageable.

3.1 Generic Review Guidelines

3.1.1 Conducting a Review

There are two kind of reviews well do, review case with the client and the other
case with other teammates.

Accounts Payable and Receivable Page 25


The changes that affect the client performance when they use the software. The
team have to consult them first but before consulting to the client the team must agree
in changes of software.

3.1.2 Role and Responsibilities

As stated in 1.2, SQA Organization Role, All members must work together and
use Software Development Lifecycle (SDLC) step by step process:

3.1.3 Review Work Product

Each member must create report, and the problems encountered, this will help the
team in documentation and creating help menu.

In meeting to the client, the team have to record the answer of the client in the interview
but before that the team must create the question and gather information.

Request opinion on the current work and schedule the next meeting.

3.2 Formal Technical review

Here are the FTR that the team will conduct during the software process:

- Walkthroughs
- Inspections

After each form (interface) we design, we’ll do the test on the interface using block box
testing method. And for each week, the team will ask the team meats to do a inspection
on the interface, do a walkthroughs of all the interfaces.

3.2.1 Description of review Walkthroughs

3.2.1.1 Description and Focus of Review

Reviews mainly focus on the integrations of the part of the design (such as
interfaces, form, and database.).

3.2.2 Description of review Inspection

3.2.2.1 Description and Focus of Review

Reviews mainly focus on the correctness of the parts that we designed. Usually
allow the other two team-members to do a private test, without the designer’s interrupt.

Accounts Payable and Receivable Page 26


3.2.1 System Specification Review

System specification usually changed after each weekly meeting, after each
meeting with our client. Most of the system designs have been settle down.

3.2.2 Software Project Plan review

The purpose of Software Project Plan is over look of the whole project. for more
information, please see the document titled “System Project Plan”.

3.2.3 RMMM Review

RMMM, Risk Mitigation, Monitoring & Management, is use to prevent, monitor,


and manage the risk. For more information, please see the document titled “RMMM”

3.2.4 Requirements Reviews (Models, specification)

Software requirement stated the data requirement, specifications. For more


information, please see the document titled “Requirement Plan”.

3.2.5 Data Design Review

Data design document is about the data flow between each form (interface), and
forms to the database. For Data Design Flow please see the document titled “Data
Design Review”.

3.2.6 Architectural Design Review

The Architectural Design document is about the whole project design, layout and
data flow. For Architectural Design, please see the document titled “Architectural
Design”.

3.2.7 Interface (GUI)

Up on the request of the client, team will redesign the interface from previous
version.

3.2.9 Code Review

3.2.10 Test Specification Review

3.2.11 Change Control Review and Audits

Accounts Payable and Receivable Page 27


3.3 SQA Audits

 The team member will have a weekly report on their individual performance for
the past week. Any problem, question regardless on the performance of the
other team members will also note there.
 Any change to the project that can affect will be consult to other member before
changing the project.
 The client must notified of all the changes made to the project.

4.0 Problem Reporting and Corrective Action/Follow-up

These sections describe problem reporting mechanisms that occur as a


consequence of the FTRs that are conducted and the means for corrective action and
follow-up.

4.1 Reporting Mechanisms

The report mechanics of the project, the team must create a function that use the
web-based system or an information like contact no. and email That the client can ask
or report the problem, the team must teach the client on how to use to reporting
function.

4.2 Responsibilities

All members of the team will be responsible for something ,Since the team use the
SDLC model, and have a leader that assist other member. But for the decision all
member must agree before to make a decision.

4.3 Data Collection and Validation

The properly conduct software quality assurance, data about the software
engineering process should be collected, evaluated, and disseminated. Statistical SQA
help to improve the quality of the project and the software process itself.

Accounts Payable and Receivable Page 28


During each meeting, the team will present the work to the client and teach the function
and how to use, also ask the opinion of the client about the project and present different
option, and ask for the approval of the client.

4.4 Statistical SQA

For software SQA implies the following steps:

 Information about software defects is collected and categorized


 Once the vital few causes have been identified, move to correct the problems
that have caused the defects.

Although hundreds of different errors can be uncovered , even for a “small scale
”project like this, all can be tracked to one (or more) of the following causes .

 Incomplete or erroneous specification(IES)


 Misinterpretation of customer communication (MCC)
 Intentional deviation from specification (IDS)
 Violation of programming standard (VPS)
 Error in data representation (EDR)
 Incomplete or erroneous testing (IET)
 Inaccurate or incomplete documentation (IID)
 Error in programming language translation of design (PLT)
 Ambiguous or inconsistent human-computer interface (HCI)
 Miscellaneous (MIS)

5.0 Software Process Improvement Activities

5.1 Goal and Object of SPI

Here are some of the goals of SPI:

1. All error and defects are categorized by origin.


2. Cost to correct each error and defect is record
3. The number of errors and defects in each category are counted and ordered in
descending order.
4. The overall cost of errors and defects in each category is computed.

Accounts Payable and Receivable Page 29


5. Resultant data are analyzed to uncover the categories that result in highest cost
to the organization.
6. Plan are developed to modify the process with the intent of eliminating(or
reducing the frequency of occurrence of) the class of errors and defects that is
most costly

The graph below illustrates the error that the team expected for the project.

Field % Reason
Logic 40 All member have no experience in creating the
project, thinking of process are difficult.
Interface 25 One interface having many elements is difficult to
combines more than one interface with many
elements.
Data Handling 20 It is difficult to store and trace the data information
in each interface and elements to another
interface or data storages.
Error Checking 15 The client meets once in a week so that the error
are difficult to identify.
Standard 15 The client meets once in a week that cause many
changes in creating interface .
HW//SW 10 Know a day there are many hardware that we can
use in creating project like computes and easy to
have a software to improve project in free.

5.2 SPI Tasks and Responsibilities

As stated in 1.2, SQA all Organization Role, All members must work together and
use Software Development Lifecycle (SDLC) step by step process:

6.0 Software Configuration Management and Overview

In software developing phase the development team always encounter changes to


the 1st plan. In that case Software configuration management plan is develop to
identify the changes, control the changes, implement correctly and to report to other
Members. For further information on this topic, please go to the document titled
“Software Configuration Management Plan”.

6.1 SQA Tools, Techniques, Methods

We have described a lot tools, techniques, methods for SQA. Using voting systems,
close contact with the client, extensive detail design, and research on the subject to
minimize the errors. Different tools had been use for the SQA for this project. Using
software review, problem tracking, We try to follow the ISO 9001 Standard as our

Accounts Payable and Receivable Page 30


organizational structure, responsibilities, procedures, and resources for implementing
quality management.

SYSTEM SPECIFICATION
1.0 INTRODUCTION
1.1 GOALS AND OBJECTIVES
1.2 SYSTEM STATEMENT OF SCOPE
1.2.1 Version 1 General Requirements
1.2.2 Version 2 General Requirements
1.2.3 Extended Enhancement Requests
1.3 SYSTEM CONTEXT
1.4 MAJOR CONSTRAINTS
2.0 FUNCTIONAL DATA DISCRIPTION
2.1 SYSTEM ARCHITECTURE

2.2.1 Architecture Model

2.2.1 Current Subsystem Overview

2.2 DATA DESCRIPTION


2.2.1 Major Data Objects
2.2.2 Relationship
2.3 HUMAN INTERFACE DESCRIPTION
3.0 SUBSYSTEM DESCRIPTION
3.1 SUBSYSTEM FLOW DIAGRAMS
3.1.1 Create Checklist

Accounts Payable and Receivable Page 31


3.1.2 Print Checklist
3.1.3 General Letter
4.0 ENCHANCED INTERFACE PROTOTYPING
4.1 PROTOTYPING REQUIREMENTS

1.0 Introduction

1.1 Goals and Objectives

The main purpose of the Accounts payable and receivable is to help the easy
process in tacking, monitor and record the in and out transaction of the company.
The goals of Accounts payable and Receivable are:
 To minimize the amount of paper works.
 To manages the Accounts Payable and Receivable’s.
 To track the inflow and out flow transaction of the company.
 To Record the transaction and checks the Reports.
 To view Aging duration and the History of transaction.

1.2 system statement of Scope

1.2.1 General requirements

The following general requirements were laid out for our project named Accounts
Payable and receivable:

Accounts Payable and Receivable Page 32


 A way that the company can add purchase furniture’s and features, goods
and equipment.
 A way that the company can checks the payment, aging reports, payment,
and vendor bill.
 A way that the company can view the history.
 A way that the company can compare the invoices through electronic.
 A way that the company can record the in and out flow of transaction.
 A way that the company determine the maturity date.

 Interface Enhancements

Staff members of Accounts Payable and Receivable have requested some


interface enhancements that will increases the process.

 Database Administrative interface

 Online Help

To develop an extensive help menu for the users and also setup the
online help for the need of the help in the future.

 Training

The staff member have also requested through training for the use with
the software

1.3 System Context

1.4 Major Constraints


Time
- We only have two months to finish all documentation, we cannot implement
some of our ideas due to time constraints.

2.0 Function Data Description

This section describes overall system function and the information domain in which
it operates.

Accounts Payable and Receivable Page 33


2.1 System Architecture

2.2.1 Architecture Mode

2.2.1 Subsystem Overview

Aging Report

Will print a report showing the amounts due, by month, for each vendor and totals
for month.

View/Edit Historical data

Any past information can be searched and browsed here.

2.2 Data Description

2.2.1 Major Data Objects

Purchase Order (PO)

1. PO number
2. Date prepared
3. Company name
4. Vendor name
5. Name and Phone number of contact person
6. A description of the items being purchased
7. Quality
8. Unit prices

Accounts Payable and Receivable Page 34


9. Shipping method
10. Date needed
11. Other pertinent information

Vendor Invoice

1. Invoice Number
2. Vendor Name
3. Vendor Phone
4. Vendor Address
5. Date Prepared
6. PO Number
7. Terms
8. Quantity
9. Description
10. Unit price
11. Due date
12. Email

Bill

1. Vendor
2. Address
3. Term
4. Date
5. Ref. No.
6. Amount Due
7. Bill Due
8. Memo

Credit

1. Vendor
2. Address
3. Date
4. Ref. No.
5. Memo
6. Credit Amount Due

Statement of Account

1. Name Company
2. Date prepared

Accounts Payable and Receivable Page 35


3. Date of invoice
4. Invoice number
5. Sales invoice number
6. Amount Due

Collection

1. Name of company
2. Amount paid in words and figure
3. Sales invoice number

2.2.2 Relationships

2.3 Human Interface Description

3.0 Subsystem Description

3.1 Subsystem Flow Diagrams

Here are some of the diagrams regarding subsystem dataflow.

3.0 Enhanced Interface Prototyping

4.1 Prototyping Requirements

The primary goal is to make the interface much more flexible then its current state.

Software Requirements Specification


I. TABLE OF CONTENS
II. GRAPHICAL NATATIONS USED
1.1 Goals and Objectives
1.2 System Statement of Scope
1.2.1 General Requirements
1.2.2 Extended Enhancement
1.3 System Content
1.4 Major Constraints
2.0 USAGE OF SCENARIO
2.1 USER PROFILES
2.2 USER-CASES
Read/Write/Modify All Users
Full Control Users

Accounts Payable and Receivable Page 36


3.0 DATA MODEL AND DESCRIPTION

3.1 Data Description


3.1.1 Data Objects and Dictionary
3.1.2 Relationships

4.0 FUNCTIONAL MODEL AND DESCRIPTION

4.1 Subsystem Flow Chart

Accounts Payable and Receivable Page 37


4.2Human Interface

5.0 RESTRICTIONS, LIMITATIONS AND CONSTRAINTS

6.0 VALIDATION CRITERIA


1.1 Goals and Objectives

- To create a system that can store and secure the data of information, compute
the payable and receivable of the client/user and supplier in a fast and less paper
works.
- Organize the information and amount of the client inaccurate and easy way of
Payable and receivable.

1.2 System Statement of Scope


1.2.1 General requirements
- We need first the information of the client.
- Payments first before booking.
1.2.2 Extended Enhancement
- Specifically designed to add new Accounts
Receivable functionality to Sage 100 (formerly known as MAS 90
and MAS 200). In conjunction with our product partners, Blyth co
offers the following comprehensive accounts receivable solutions
for.

Database Restructuring
- Using the standard needs and equipping future hardware and
software to improve the function and the interface.
1.3 System Context

1.4 Major Constraints


Time
- We only have two months to finish all documentation; we cannot implement
some of our ideas due to time constraints.

2.0 Usage Scenario

2.1 User Profiles

 Full Control (Administrator)


 Read/Write/Modify All (Staff)
2.2 Use-cases
Read/Write/Modify All Users

Accounts Payable and Receivable Page 38


-this user level can manipulate records maintenance task
Full Control Users
-in this level of user administrative can manipulate the system settings.

3.0 Data Model


3.1 Data Description
3.1.1 Data Objectives and Dictionary

Administrator information

1. Administrator I.D
It identifies the user I.D number for the identity.
2. F_Name
The name of the user.
3. L_Name
The last name of the user
4. M.I
The middle name of the user
5. Password
The security of the user
6. Username
The identity of user.

3.1.2 Relationships

Accounts Payable and Receivable Page 39


4.0 Functional Model and Description
4.1 Subsystem Flow Diagrams

4.2 Human Interface


- Our mission is to bring insights to our clients that help them understand their
user’s needs from brand perception and loyalty to how they interact with products
and services. Understanding your end user enables you to create experiences
that are customer-focused, user friendly and loyalty and most importantly, that
drive loyalty.

5.0 Restrictions, Limitations and Constraints


Time
- - We only have two months to finish all documentation, we cannot implement
some of our ideas due to time constraints.
6.0 Validation Criteria

Accounts Payable and Receivable Page 40


Software Design Specification
1. TABLE OF CONTENTS
1.0 INTRODUCTION
1.1 GOALS AND OBJECTIVES
1.2 SYSTEM STATEMENT OF SCOPE
1.2.3 General Requirements

1.3 SYSTEM CONTEXT


1.4 MAJOR CONSTRAINTS
2.0DATA DESIGN
2.1 DATABASE DESCRIPTION
3.0 ARCHITECTURE AND COMPONENT – LEVEL DESIGN
3.1 PROGRAM STRUCTURE
3.1.1 OVERALL
3.1.5 APPROVAL
3.2DESCRIPTION FOR COMPONENTS
3.2.1 SWITCH USER
4.0 USER INTERFACE DESIGN
4.1 DESCRIPTION OF THE USER INTERFACE
4.1.1 SCREEN IMAGES
LOGIN SCREEN
SEARCH PAGES
APPROVAL QUEUE
4.1.2 OBJECTS AND ACTIONS
4.2 INTERFACE DESIGN RULES
4.3 COMPONENTS AVAILABLE
4.3.1 INTRINSIC CONTROLS

Accounts Payable and Receivable Page 41


4.3.2 ACTIVEX CONTROLS
5.0RESTRICTION, LIMITATIONS, AND CONSTRAINTS
TIME
EMPLOYEE SKILLS
INSUFFICIENT RESOURCES
6.0 TESTING ISSUES
6.1 CLASSES OF TEST
6.2 PERFORMANCE BOUNDS
6.3 IDENTIFICATION OF CRITICAL COMPONENTS

1.0 Introduction
This section describes the design for the waste management inspection tracking
system

1.1Goals and objectives

The main purpose of WMITS is to help automate the entire process that the Department
of Environment
Quality (DEQ) Waste Management Division (WMD) staff members perform throughout
an inspection
The goals of WMITS are:

𛈇
 To minimize the time span of any inspection
 To minimize the amount of paper work required
 To provide a searchable database of all past inspection
 To provide an automated channel for the public to request information
(under Freedom of information act)

Critique: The specific goals and objective of the WMITS design should also be
discussed

1.2 System Statement of scope

1.2.1 System Requirements

Accounts Payable and Receivable Page 42


The following general requirements were laid out for our project named WMITS.

 A way in which DEQ could add new facilities to the database.


 A way in which DEQ could generate electronic checklist.
 A search on all electronic checklist.
 A way in which they could generate letters to be sent out to facilities based
on inspection result
 A way in which all letters and checklists could be stored electronically
 A way to search for existing facilities.
 A way to print blank checklists and staff report.
 A way in which they could view data which was entered into the database
prior to our software.
 DEQ wanted a product that would allow them to easily add new checklist
and letters or change existing checklists and letters.

 Interface Enhancements
Staff members of WMD have requested a lot of interface enhancements
that will increase the usability of the product for the staff.

 Database Administrative interface


There is no current documented interface for WMD staff members to
maintain the checklist and letter templates. Should no such interface
existed, Cyber Rovers will have to implement one from scratch.

 Online Help
To develop an extensive help menu for the users and also to setup the
online help for the need of the help in the future

 Training
The staff members have also requested throughout training for the entire
staff for use with the software

1.3 System context.

Eventually, multiple users will be using the product simultaneously, Therefore,


concurrent connection will be an issue for implementation. In addition , this is a pilot
product that hopefully , if successful, can be used in other locations as well, this leads to
issues about future support for a larger user base.

1.4 Major constraints

Accounts Payable and Receivable Page 43


Time
We only have about two months to finish all documentation, software creation and
enhancements. We have a lot of ideas but cannot implement them due to time
constraint. One of the major ones is to move the application to be completely browser-
based.

Funding
To develop and implement the Palm Pilot integration, we will need funding to buy at
least one Palm Pilot. We Will request the funding from university of Michigan- Dearborn
should we decided to pursue this function.

2.0 Data design

2.1 Database description

Accounts Payable and Receivable Page 44


3.0 Architectural and Component

3.1 Program Structure

3.1.1 Overall

Login

Main Screen

File Accounts Accounts Maintenance Invoice Report Help


payable receivable

3.1.5 Approval

3.2.1 Switch User

3.0 user interface design


3.1 description of the user interface
3.1.1 Screen image

4.1.2 Objects and actions

1. Login Screen

User Name

Username can be ranged from 6 to 20 letters (numbers), as the industry standard. No


special characters, space. And mostly likely the users will use their DEQ user name for
this system as well.

Password

Password can be ranged from 6 to 20 letters (numbers), as the industry standard. No


special characters, space.

Ok

Accounts Payable and Receivable Page 45


If the users enter the right user name with the matching password, it will immediately
take them to the main interface.

Cancel

If the user wishes to exit the program, hit the ”cancel” button.

3.2 Components Available

Since we are using Java as our front-end development language, there the following list
of controls that we will be using for this software.

4.3.1 Intrinsic controls

Textbox

A text box, text field or text entry box is a graphical control element intended to
enable the user to input text information to be used by the program.

Label

A label control is graphical control you can use to display text that the user can’t change
directly.

Line a line is graphical control displayed as a vertical, horizontal or diagonal line.

Image

An image control can display a graphic from a bitmap, icon, or metafile, as well as
JPEG, or GIF files.

List box

A list box is a graphical control element that allows the user to select one or more items
from a list contained within a static, multiple line text box.

Scrollbars

Scroll bars provide easy navigation to a long list of items or large amount of information.

Command button

A graphical button that appears in a computer user interface, allowing a user to trigger
an event.

Accounts Payable and Receivable Page 46


Menu

In computing and telecommunications, a menu or menu bar is graphical control


element. It is a list of options or commands presented to an operator by a computer
or communications system.

Combo box

A combo box is a commonly used graphical user interface widget (or control).
Traditionally, it is a combination of a drop-down list or list box and a single-line
editable textbox, allowing the user to either type a value direct The term "combo box" is
sometimes used to mean "drop-down list".

Checkbox

Is a Graphical control element that permits the user to make a binary choice, i.e. a
choice between one of two possible mutually exclusive options. For example, the user
may have to answer 'yes' (checked) or 'no' (not checked) on a simple yes/no question.

Option Button

An option Button control display an option that can be turn on and off.

Shape

A graphical control that displays circle, rectangle, or rounded rectangle.

4.3.2 ActiveX control

Data repeater

Initializes a new instance of the Data Repeater class.

DateTimePicker

Represents a Windows control that allows the user to select a date and a time and to
display the date and time with a specified format.

MSFlexGrid

Accounts Payable and Receivable Page 47


Returns or sets a value that determines whether lines are drawn between cells, bands,
headers, indents, or unpopulated areas. These properties also determine the type of
lines that are drawn in the MSFlexGrid.

Treeview

Displays hierarchical data, such as a table of contents, in a tree structure.

Status bar

A status bar is a graphical control element which poses an information area typically
found at the window's bottom.

Toolbar

A toolbar is a graphical control element on which on-screen buttons, icons, menus, or


other input or output elements are placed.

Commondialog

The Common Dialog Box Library contains a set of dialog boxes for performing common
application tasks, such as opening files, choosing color values, and printing documents.

4.0 Restriction, Limitations, and Constraints

Time

Time is one of the biggest constraints for our project because we only have three
months to finish the project.

Employee Skills

It does not have a big impact on the project as time but it sure does limit us from doing
more additional to the project.

Insufficient Resources

Not having all the things that the project needs to finish past, we planned to use the
latest equipment but we don’t have a budget to buy the equipment we needed.

Accounts Payable and Receivable Page 48


5.0 testing issues

Test Specification
1.0 INTRODUCTION
0.1 GOALS AND OBJECTIVES
0.2 STATEMENT OF SCOPE
0.3 MAJOR CONSTRAINTS
2.0 TESTING PLAN
2.1 SOFTWARE (SCIs) TO BE TESTED
2.1.1 INTERFACE
2.2 STRATEGY
2.2.1 UNIT TESTING
2.2.2 INTEGRATION TESTING
2.2.3 VALIDATION TESTING
2.2.4 HIGH-ORDER TESTING
2.3 TESTING RESOURCES AND STAFFING
2.4 TEST RECORD KEEPING
2.5 TESTING TOOLS AND ENVIRONMENT

Accounts Payable and Receivable Page 49


2.6 TEST SCHEDULE
3.0 TEST PROCEDURE
3.1 SOFTWARE (SCIs) TO BE TESTED
3.2 TESTING PROCEDURES
3.2.1 UNIT TESTING
3.2.2 INTEGRATION TESTING
3.2.3 VALIDATION TESTING
3.2.4 HIGH-ORDER TESTING
3.3 TESTING RESOURCES AND STAFFING
3.4 TEST RECORD KEEPING AND LOG

TEST SPECIFICATION

1.0 Introduction
This section gives an over view the Test Specification for the Accounts Payable and
Receivable (A/P and A/R).

1.1 Goal and Objectives

The software has to go through a series of test before its final release. Error free is
extremely difficult to achieve. After all noting is perfect. Especially for software
development in a short time frame. But high quality can be achieved with a detailed test
specification. All are listed and follow it step by step, to test all the necessary object,
data flow, limit, boundaries, and constraints of the software.

The Team has to test specification to counter any difficulties that may impact the
development and the future performance of the software. The main goal is to assist the
team in developing a strategy to deal with any error.

1.2 Statement O Scope

Accounts Payable and Receivable Page 50


An overall plan for the integration of the software and a description of specific tests are
document in this section. Below are the different kinds of tests that team will take to
ensure the quality of the software.

 Unit Testing
- Desktop Application
- Database
 Integration Testing
- Desktop Application
- Database
 Validation Testing
- Desktop Application
- Database
 High-order Testing
- Desktop Application
- Database

1.3 Major Constraints

In this section the team will talk about the business, technical or resources related
constraint that may keep us from performing all test necessary.

1. The team does not know any hacker that can help the team to test the security.
2. The team also does not have a large enough group to have many people use the
applications at the same time to perform real stress related test.

2.0 Testing Plan

The team want the project to be bug free, also want to make sure that there are no
defects in the project.

2.1 Software (SCIs) to be tested

2.1.1 Interfaces

Accounts Payable and Receivable Page 51


The test to be carried in these interface window are describe.

2.2 Testing Strategy

In this section the team will describe the strategy. The team will use four different
methods to test our project.

2.2 In the following section we will describe the testing strategy. We will use four
different methods to test our product.

2.2.1 Unit testing

Unit tests ensure that code works as intended. They are also very helpful to ensure that
the code still works as intended in case you need to modify code for fixing a bug or
extending functionality. Having a high test coverage of your code allows you to continue
developing features without having to perform lots of manual tests.

2.2.2 Integration Testing

We have to test the software if they are functioning properly, and we make sure that
there is no loss of data or database anomalies in the product.

2.2.3 Validation testing

We should ensure the product meets requirements for its specific intended use which is
basically business requirement (does it work? can I control the lights from the UI?) but
testers will definitely work with the functional spec, making sure the checkboxes are
there, working, labeled, etc.

2.2.4 High – over testing

In this method several types of testing we have to use.

 Recovery Testing

We have to make sure that we can recover data that have accidentally lost or
already lost.

 Security Testing

We have to make the security of our software to track down the activity that is not
legal.

 Stress Testing

We have to make sure that our units can stand extreme conditions and for a long
time of use.

Accounts Payable and Receivable Page 52


 Performance Testing

We have to make sure that our units are working properly for minimizing the stress
that the user taking.

Accounts Payable and Receivable Page 53

Вам также может понравиться