bsit-4110.weebly.combsit-4110.weebly.com/uploads/3/1/6/5/...chapter_3.docx · Web viewRISK MITIGATION, MONITORING, AND MANAGEMENT PLAN. INTRODUCTION. SCOPE AND INTENT OF RMMMA ACTIVITIES

RISK MITIGATION, MONITORING, AND MANAGEMENT PLAN

1.0 INTRODUCTION1.1 SCOPE AND INTENT OF RMMMA ACTIVITIES1.2 RISK MANAGEMENT ORGANIZATIONAL ROLE

2.0 FUNCTIONAL DATA DESCRIPTION2.1 RISK TABLE

21.1 DESCRIPTION OF RISK M21.2 PROBABILITY AND IMPACT FOR RISK M

3.0 RISK MITIGATION, MONITORING AND MANAGEMENT

3.1RISK MITIGATION FOR RISK M3.1.1 PRODUCT SIZE3.1.2 BUSINESS IMPACT3.1.3 CUSTOMER (USER) RISKS3.1.4 PROCESS RISKS3.1.5 TECHNOLOGY RISKS3.1.6 DEVELOPMENT RISKS3.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.


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.


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.


2.1.2 Probability and impact for risk m

Category Risks Probability

Impact

Employee Risk Lack of training and experience 30% 1

Process Risk Low product quality 20% 1

Product Size Where size estimate could be wrong 35% 2

Development Risk Insufficient resources 25% 2

Customer Risk Customer may fail to participate 15% 3

Technology Risk Obsolete technology 10% 2

Business Risk Product may harm the business 10% 3

Table – Risks Table (sorted)

Impact Values Description

1 Catastrophic

2 Critical

3 Marginal

4 Negligible


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.


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


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.


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.


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.


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


Software Configuration Management Plan

1.0 INTRODUCTION1.1 SCOPE AND INTENT OF SCM ACTIVITIES1.2 SCM ORGANIZATION ROLE

2.0 SCM TASKS2.1 IDENTIFICATION

2.1.1 Description2.1.2 Works products and documentation

2.2 CONFIGURATION CONTROL2.2.1 Description

2.3 VERSION CONTROL2.3.1 Description2.3.2 Increasing Version Number2.3.3 Work Products and Documentation

2.4 CONFIGURATION STATUS ACCOUNTING (CSA)2.4.1 Description2.4.2 Work Products and Documentation

3.0 SOFTWARE QUALITY ASSURANCE OVERVIEWSCOPE AND INTENT OF SQA ACTIVITIESREVIEW AND AUDITS

3.1 Generic Review Guidelines3.2 Formal Technical Reviews3.3 SQZ Audits


3.4 PROBLEM REPORTING AND CORRECTIVE ACTION/FOLLOW-UP3.4.1 Reporting Mechanisms3.4.2 Responsibilities3.4.3 Data Collection and Valuation

SOFTWARE CONFIGURATION MANAGEMENT PLAN

1.0Introduction

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.1Scope 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.2SCM 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


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.0SCM 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.


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 changesOnce the changes is identify a changes will work together and implement.

Control changesAfter 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 error2. Make necessary changes3. Apply SQA activities4. Apply testing activities5. Rebuilt the software


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.


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.0Software 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:


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


- 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:


- 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


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)


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


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.


Software Quality Assurance Plan

I. TABLE OF CONTENTSI.0 INTRODUCTIONI.1 SCOPE AND INTENT OF SQA ACTIVITIESI.2 SQA ORGANIZATION ROLE

2.0 SQA TASKS2.1 Task Overview2.2 Standard, Practices and Conventions (SPC)2.3 Resources

3.0 REVIEW AND AUDITS3.1 Generic Review Guidelines3.2 Formal Technical Review3.3 SQA Audits

4.0 PROBLEM REPORTING AND CORRECTIVE ACTION/FOLLOW-UP4.1 Reporting Mechanisms4.2 Responsibilities4.3 Date Collection and Valuation4.4 Statistical SQA

5.0 SOFTWARE PROCESS IMPROVEMENT ACTIVITIES5.1 Goal and Object of SPI5.2 SPI Tasks and Responsibilities

6.0 SOFTWARE CONFIGURATION MANAGEMENT AND OVERVIEW7.0 SQA TOOLS, TECHNIQUES, METHODS


SOFTWARE QUALITY ASSURANCE PLAN

1.0Introduction

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:


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.0SQA 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


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

July 07,2014Project BackgroundGather informationInterview to Client

9: 00 am to 7:00 pm

July 12,2014Present draft of documentPresent different optionInterview to client

9: 00 am to 7:00 pm

July15 ,2014 Present the flowInterview to client

1: 00 am to 6:00 pm

July 25,2014 Gather more informationInterview to client

9: 00 am to 7:00 pm

August 5,2014Present the changesInterview to client

3: 00 am to 6:00 pm

August 27,2014 Ask for the approval of changesInterview to client

1: 00 am to 5:00 pm

To be scheduled Present draft designPresent design OptionInterview to client

To be scheduled

To be scheduled Present draft designPresent design OptionInterview to client

To be scheduled

To be scheduled Present the Final Version To be scheduled

Extensive detail Design


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.


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


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


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)

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.

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.

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 record3. 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.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 % ReasonLogic 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 organizational structure, responsibilities, procedures, and resources for implementing quality management.


SYSTEM SPECIFICATION

1.0 INTRODUCTION1.1 GOALS AND OBJECTIVES1.2 SYSTEM STATEMENT OF SCOPE

1.2.1 Version 1 General Requirements1.2.2 Version 2 General Requirements1.2.3 Extended Enhancement Requests

1.3 SYSTEM CONTEXT1.4 MAJOR CONSTRAINTS

2.0 FUNCTIONAL DATA DISCRIPTION2.1 SYSTEM ARCHITECTURE

2.2.1 Architecture Model

2.2.1 Current Subsystem Overview

2.2 DATA DESCRIPTION2.2.1 Major Data Objects2.2.2 Relationship

2.3 HUMAN INTERFACE DESCRIPTION3.0 SUBSYSTEM DESCRIPTION

3.1 SUBSYSTEM FLOW DIAGRAMS3.1.1 Create Checklist3.1.2 Print Checklist3.1.3 General Letter

4.0 ENCHANCED INTERFACE PROTOTYPING4.1 PROTOTYPING REQUIREMENTS


1.0Introduction

1.1Goals 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.2system statement of Scope

1.2.1 General requirements

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

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.3System Context

1.4Major ConstraintsTime

- 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.

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 number2. Date prepared3. Company name4. Vendor name5. Name and Phone number of contact person6. A description of the items being purchased7. Quality8. Unit prices9. Shipping method10.Date needed11.Other pertinent information

Vendor Invoice

1. Invoice Number2. Vendor Name3. Vendor Phone


4. Vendor Address5. Date Prepared6. PO Number7. Terms8. Quantity9. Description10.Unit price11.Due date12.Email

Bill

1. Vendor2. Address3. Term4. Date5. Ref. No.6. Amount Due7. Bill Due8. Memo

Credit

1. Vendor2. Address3. Date4. Ref. No.5. Memo6. Credit Amount Due

Statement of Account

1. Name Company2. Date prepared3. Date of invoice4. Invoice number5. Sales invoice number6. Amount Due

Collection

1. Name of company2. 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.0Enhanced 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 CONTENSII. GRAPHICAL NATATIONS USED

1.1Goals and Objectives1.2 System Statement of Scope

1.2.1 General Requirements1.2.2 Extended Enhancement

1.3System Content1.4Major Constraints

II.0USAGE OF SCENARIOII.1USER PROFILESII.2USER-CASES

Read/Write/Modify All UsersFull Control Users

3.0 DATA MODEL AND DESCRIPTION

3.1 Data Description3.1.1 Data Objects and Dictionary3.1.2 Relationships

4.0 FUNCTIONAL MODEL AND DESCRIPTION


4.1 Subsystem Flow Chart

4.2Human Interface

5.0 RESTRICTIONS, LIMITATIONS AND CONSTRAINTS

6.0VALIDATION CRITERIA1.1Goals 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.2System Statement of Scope1.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 ConstraintsTime

- 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.2Use-casesRead/Write/Modify All Users-this user level can manipulate records maintenance taskFull Control Users-in this level of user administrative can manipulate the system settings.

3.0Data Model 3.1Data Description

3.1.1 Data Objectives and Dictionary


http://www.blytheco.com/sage100/accounts-receivable.asp

http://www.blytheco.com/sage100/accounts_receivable.asp

http://www.blytheco.com/sage100/accounts_receivable.asp

Administrator information

1. Administrator I.DIt identifies the user I.D number for the identity.

2. F_NameThe name of the user.

3. L_NameThe last name of the user

4. M.IThe middle name of the user

5. PasswordThe security of the user

6. UsernameThe identity of user.

3.1.2 Relationships

4.0Functional Model and Description4.1Subsystem Flow Diagrams


4.2Human 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.0Restrictions, Limitations and ConstraintsTime

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

6.0 Validation Criteria


Software Design Specification

1. TABLE OF CONTENTS1.0 INTRODUCTION

1.1 GOALS AND OBJECTIVES1.2 SYSTEM STATEMENT OF SCOPE

1.2.3 General Requirements

1.3 SYSTEM CONTEXT1.4 MAJOR CONSTRAINTS

2.0DATA DESIGN2.1 DATABASE DESCRIPTION

3.0 ARCHITECTURE AND COMPONENT – LEVEL DESIGN3.1 PROGRAM STRUCTURE3.1.1 OVERALL3.1.5 APPROVAL

3.2DESCRIPTION FOR COMPONENTS3.2.1 SWITCH USER

4.0 USER INTERFACE DESIGN4.1 DESCRIPTION OF THE USER INTERFACE

4.1.1 SCREEN IMAGESLOGIN SCREENSEARCH PAGESAPPROVAL QUEUE4.1.2 OBJECTS AND ACTIONS

4.2 INTERFACE DESIGN RULES4.3 COMPONENTS AVAILABLE

4.3.1 INTRINSIC CONTROLS4.3.2 ACTIVEX CONTROLS

5.0RESTRICTION, LIMITATIONS, AND CONSTRAINTSTIMEEMPLOYEE SKILLSINSUFFICIENT RESOURCES

6.0 TESTING ISSUES6.1 CLASSES OF TEST6.2 PERFORMANCE BOUNDS6.3 IDENTIFICATION OF CRITICAL COMPONENTS


1.0IntroductionThis 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 EnvironmentQuality (DEQ) Waste Management Division (WMD) staff members perform throughout an inspectionThe 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

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 EnhancementsStaff members of WMD have requested a lot of interface enhancements that will increase the usability of the product for the staff.

Database Administrative interfaceThere 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 HelpTo develop an extensive help menu for the users and also to setup the online help for the need of the help in the future

TrainingThe 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

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.0Data design

2.1Database description

3.0 Architectural and Component

3.1 Program Structure

3.1.1 Overall


Login

File Accounts payable

Accounts receivable

Main Screen

Report HelpMaintenance Invoice

3.1.5 Approval

3.2.1 Switch User

3.0user interface design 3.1description 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

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.2Components 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.


http://en.wikipedia.org/wiki/Graphical_control_element

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.

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.


http://en.wikipedia.org/wiki/User_(computing)


http://en.wikipedia.org/wiki/Text_box

http://en.wikipedia.org/wiki/List_box

http://en.wikipedia.org/wiki/Drop-down_list

http://en.wikipedia.org/wiki/Widget_(computing)

http://en.wikipedia.org/wiki/Graphical_user_interface

http://en.wikipedia.org/wiki/Communications_system

http://en.wikipedia.org/wiki/Operator_(profession)

http://en.wikipedia.org/wiki/Command_(computing)



http://en.wikipedia.org/wiki/Computing

http://en.wikipedia.org/wiki/Event_(computing)

http://en.wikipedia.org/wiki/Button_(computing)

http://en.wikipedia.org/wiki/Text_box


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

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.



http://en.wikipedia.org/wiki/Window_(computing)


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.0Restriction, 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.

5.0testing issues


Test Specification

1.0INTRODUCTION0.1GOALS AND OBJECTIVES0.2STATEMENT OF SCOPE0.3MAJOR CONSTRAINTS

2.0 TESTING PLAN2.1 SOFTWARE (SCIs) TO BE TESTED

2.1.1 INTERFACE2.2 STRATEGY2.2.1 UNIT TESTING2.2.2 INTEGRATION TESTING2.2.3 VALIDATION TESTING2.2.4 HIGH-ORDER TESTING2.3 TESTING RESOURCES AND STAFFING2.4 TEST RECORD KEEPING2.5 TESTING TOOLS AND ENVIRONMENT2.6 TEST SCHEDULE

3.0 TEST PROCEDURE3.1 SOFTWARE (SCIs) TO BE TESTED3.2 TESTING PROCEDURES3.2.1 UNIT TESTING3.2.2 INTEGRATION TESTING3.2.3 VALIDATION TESTING3.2.4 HIGH-ORDER TESTING3.3 TESTING RESOURCES AND STAFFING3.4 TEST RECORD KEEPING AND LOG


TEST SPECIFICATION

1.0IntroductionThis 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

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

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.

Performance Testing

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


Documents

bsit-4110.weebly.combsit-4110.weebly.com/uploads/3/1/6/5/...chapter_3.docx · Web viewRISK MITIGATION, MONITORING, AND MANAGEMENT PLAN. INTRODUCTION. SCOPE AND INTENT OF RMMMA ACTIVITIES