Академический Документы
Профессиональный Документы
Культура Документы
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
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 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 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.
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.
the following table define the different risk and the impact of developing a project the
affectivity and the fact.
The system may fail to give the business wants and may leave to an impact to their
transaction with the clients.
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.
Lack of traini
Employee Risk 30% 1
ng and experience
Technology
Obsolete technology 10% 2
Risk
1 Catastrophic
2 Critical
3 Marginal
4 Negligible
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
In this section the Project team identify different risk in developing project and try
to create a solution on how to manage those risks.
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.
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.
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.
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.
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.
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.
1.0 Introduction
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
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
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
2.1.1 Description
Identify changes
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.
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.
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.1 Description
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
2.3.1 Description
Result of changes, the version of the number of various modules will be increased
accordingly.
A changes request is filed; a change report will be created. After the change is
finalized, it will be document.
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.
We do not foresee any change in major version number. The module will be labeled as
version 2.
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 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.
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
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.
As stated in 1.2, SQA Organization Role, All members must work together and
use Software Development Lifecycle (SDLC) step by step process:
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.
Here are the FTR that the team will conduct during the software process:
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.
Reviews mainly focus on the integrations of the part of the design (such as
interfaces, form, and database.).
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.
System specification usually changed after each weekly meeting, after each
meeting with our client. Most of the system designs have been settle down.
The purpose of Software Project Plan is over look of the whole project. for more
information, please see the document titled “System Project Plan”.
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”.
The Architectural Design document is about the whole project design, layout and
data flow. For Architectural Design, please see the document titled “Architectural
Design”.
Up on the request of the client, team will redesign the interface from previous
version.
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 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.
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.
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.
All members must work together and use Software Development Lifecycle (SDLC) step
by step process:
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
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.
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.
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.
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.
There are two kind of reviews well do, review case with the client and the other
case with other teammates.
As stated in 1.2, SQA Organization Role, All members must work together and
use Software Development Lifecycle (SDLC) step by step process:
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.
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.
Reviews mainly focus on the integrations of the part of the design (such as
interfaces, form, and database.).
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.
System specification usually changed after each weekly meeting, after each
meeting with our client. Most of the system designs have been settle down.
The purpose of Software Project Plan is over look of the whole project. for more
information, please see the document titled “System Project Plan”.
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”.
The Architectural Design document is about the whole project design, layout and
data flow. For Architectural Design, please see the document titled “Architectural
Design”.
Up on the request of the client, team will redesign the interface from previous
version.
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.
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.
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.
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 .
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.
As stated in 1.2, SQA all Organization Role, All members must work together and
use Software Development Lifecycle (SDLC) step by step process:
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
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
1.0 Introduction
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.
The following general requirements were laid out for our project named Accounts
Payable and receivable:
Interface Enhancements
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
This section describes overall system function and the information domain in which
it operates.
Aging Report
Will print a report showing the amounts due, by month, for each vendor and totals
for month.
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
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
Collection
1. Name of company
2. Amount paid in words and figure
3. Sales invoice number
2.2.2 Relationships
The primary goal is to make the interface much more flexible then its current state.
- 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.
Database Restructuring
- Using the standard needs and equipping future hardware and
software to improve the function and the interface.
1.3 System Context
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
1.0 Introduction
This section describes the design for the waste management inspection tracking
system
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
Interface Enhancements
Staff members of WMD have requested a lot of interface enhancements
that will increase the usability of the product for the staff.
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
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.
3.1.1 Overall
Login
Main Screen
3.1.5 Approval
1. Login Screen
User Name
Password
Ok
Cancel
If the user wishes to exit the program, hit the ”cancel” button.
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.
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.
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.
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
Data repeater
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
Treeview
Status bar
A status bar is a graphical control element which poses an information area typically
found at the window's bottom.
Toolbar
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.
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.
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
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).
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.
Unit Testing
- Desktop Application
- Database
Integration Testing
- Desktop Application
- Database
Validation Testing
- Desktop Application
- Database
High-order Testing
- Desktop Application
- Database
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.
The team want the project to be bug free, also want to make sure that there are no
defects in the project.
2.1.1 Interfaces
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.
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.
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.
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.
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.
We have to make sure that our units are working properly for minimizing the stress
that the user taking.