Plagiarism Checker System Requirements, GitHub Configuration Management, And Microsoft Build Management

System Requirements

The Acceptance test 

Introduction

The goal of this acceptance test shall be to check whether the plagiarism checker has met all the business requirements as mentioned in the systems requirements specification and shall be vital in the final sign off of the system and eventually going live (Tsen et al., 2012). This document seeks to provide the procedure that shall be followed in the acceptance test. The following requirements shall be planned in the acceptance test

Functional Requirements

1. Track student submissions
2. Detect plagiarism
3. Report plagiarism to student
4. Report plagiarism to the tutor

Nonfunctional requirements

1. Secure login
2. Optimized performance
3. Increased reliability
4. Effective and efficient
5. User-friendly

Acceptance test plan

The following aspects of the plagiarism checker shall be tested under the acceptance plan and their failure will mean the system will not go live unless all the tests are passed (Haugset and Hanssen, 2008). They include;

F1: Ability to detect plagiarism from a copy paste text

F2: Ability to detect translated texts from online sources

F3: Ability to detect clause quilts and or mosaics

F4: Ability to track when the student made assignment submission

F5: Ability to report the plagiarism report to the student

F6: Ability to report to the tutor the plagiarism report

F7- Ability to do batch processing of the student assignment

To fully do the tests as per the plan, the following test cases are outlined

System Part	Risk analysis	Test procedure	Expected results	Actual Result
Functionality
F1	High Risk	Copy a text from Wikipedia and paste into a word document. Submit the document to the plagiarism checker	Plagiarism detected from  copy paste
F2	High risk	Translate a text from Wikipedia, add the translated texts into a word document. Submit the document online to the plagiarism checker	The translated texts flagged as plagiarism
F3	High risk	Combine texts and phrases from Wikipedia and google books to form a single phrase, submit the document to the plagiarism checker online	The mosaic words are flagged as plagiarism
F4	Medium Risk	Check the date and time the assignment is submitted. Check the date recorded by the plagiarism checker.	The system should report the timestamp the document is uploaded
F5	Medium Risk	Upload a copy-pasted text from the Wikipedia used above in F1, upload it to the plagiarism checker.	The portal should provide a separate pdf file detailing the sources of plagiarism and the plagiarism score to the student
F6	Medium	The teacher logs into the portal and views the uploaded work by the student, the teacher chooses any files and checks it plagiarism report	The system should report the same report as in F5 to the tutor
F7	High	The student checks the uploaded files to do batch plagiarism and click check for me	The system should generate a batch report for the selected files and report on each separately for the tutor

Black Box Testing

Introduction

The black box testing for the Microsoft word 2016 print screen is subjected to a behavioral test to check how the interface responds to various user events and behaviors (Vos et al., 2013). The test plan focuses majorly on the functional part of the print module but other non-functional components are also subject to the test plan (Zeil, 2013). The various parts to be tested are enumerated below

1. Putting a negative value in the number of copies field
2. Clicking on the printer property window
3. Changing my default printer setting in the system
4. Putting a negative value in the page to be printed
5. Setting back to back printing setting
6. Changing the orientation to landscape

The various items to be tested is then matrixed in the table below and shall be used in the final execution of the plan i.e. it will act as the blueprint of the black box test to be conducted (Mariani et al., 2012).

System Part	Test Description	Test data	Procedure	Expected Result	Actual Result
Test Number
1	Checking the input bounds on the number of copies text box	Integer -1	Click ctrl+p to get to the print form, enter -1 in the number of copies field, click print	The system should warn of no negative numbers accepted
2	Clicking the printer property link should open up another window with the printer properties of the current form	Not applicable	Once the document opens in a word, click ctrl+p to go to the print dialog, click on the printer property link	A new dialog box with the printer property listed for the current file
3	Test whether the module changes behavior based on the printer selected as default in my system	Not applicable	Change the printer default in the devices and printer of the system, click on another printer, set as default, click save. Open the word print section by ctrl+p,	The default printer changes according to the one set
4	Test to check if the module validates the values input for the page ranges	-3 and -4	Goto to the print page of the word by ctrl+p, under the pages input box, put -4 – -3 as the page ranges, click print	The system should display an error dialog informing the user of domain integrity violation for the pages values
5	Test to check if the printer set a back  to back printing mode	Not applicable	Click the ctrl+p on the word document to get into the print option and choose print on both side option for, click print	The print out should be both sided
6	Test if the module changes the orientation of the paper	Not applicable	Click the ctrl+p on the word document, choose the landscape option under the paper orientation, click print	The print out should be in the landscape orientation layout

Code/file version management 

The configuration management part was done by signing up to the GitHub account under the alias of franklinokech as the username to enable the forking of the repository hosted on GitHub under the alias of ammarscu (Mergel, 2015). The forking enabled me to have a copy of the repository in my GitHub account, where It was clone to my local machine for offline editing. The edited copy was committed and pushed to my repository where a pull request was launched to request the project manager to merge the changes with the mainstream project(Rastogi and Nagappan, 2016)

GitHub Configuration Management

Build management

Overview

The Microsoft build management alias MS Build, which is an open source tool that helps the developer to automate the process of building software by automating mundane tasks such as compiling, testing, packaging, and deployment of software based on the .net framework targeted for the application(Imeshev, 2008). Every build creates a clean version of the system incorporating all the changes that have been made (Pinnix, 2015).

Advantages

The tool speed software development by automating most tasks such as compiling, testing, packaging, and deployment compared to when the process requires another set of tools to do the builds.(Chen and Qumei, 2010)

Enhance the accuracy of the system by ensuring clean builds since the MS Build maintains the versions and history of previous builds and produce a clean built on every build done (Brunswig and Kaiser, 2010).

Disadvantages

It is not an open source with little community support

It is majorly used for Microsoft based architectures hence can’t run software build with MSBuild in Linux or OSX

Microsoft Release Management

Microsoft uses the MS Build to manage their release cycles by following the process of build to deploy to testing then continuous improvements

Build

In the build stage, the product undergoes rigorous development t and fixing of issues that may arise during the development. The developer conducts the unit test and integration tests to ascertain compliance with the set user requirements. The IDE can be used to automate some of the build stages (Bassil, 2012).

Deploy

After the build, the software goes to the deployment stage where the product is integrated to make it usable by the users. At this stage, the internal users can use the systems and identify bugs (Lindgren et al., 2008).

Testing

The product is undertaken to a user acceptance test and beta tests to check if it meets the user requirements and business needs. Once it is accepted by the users, it goes live

Maintenance

Software products undergo continuous improvements to fix bugs and patch some security issues that may be associated with the new product. This is an ongoing process.

Kool Dudes Mobile

Management Information Systems

Request for Proposal

Background Information

Kool Dudes Mobile is a business that deals with the mobile devices ranging from sales of new devices, repair of broken ones and sales of mobile accessories to clients with headquarter in Kitoo market with five other branches in Kimusi, Tatu, Bulu, Taita and Teveta locations.

Microsoft Build Management

System Description

Kool Dudes mobile is seeking for an integrated management information system that can integrate the information in the branches and synchronize them for easier management and decision making. The proposed system should be agile and be able to adapt to meet the following goals

Ability to store information about the devices to be repaired by storing data such as the customer details, nature of the problem, and the details of the work to be done.

Integration of a marketing module that can talk about the form of email marketing, social media marketing, and other electronic media for marketing. The targeted client’s information should be easily got from the repair database with an extension of linking with the kool dude’s website to increase target audience hence the success of marketing campaigns.

Incorporation of a module to manage the stock for Kool Dude business ranging from the various devices up for sales, the various tools and parts that are used to do the repairs, ability to link to wholesaler sites to automate the ordering process. The module should be for each individual branch but linked together and a user shall be able to query other stocks in other branches.

Provision of a report module that can be accessed by managers to give the report on stock performance, employee performance, repair report, sales, and purchases report and the marketing campaigns report among other reports of the functionality mentioned above.

Budget

Kool Dudes budget for the above system is proposed to be at $9,750.00.

Proposals Elements

Each proposal to be submitted shall follow the following template to enhance uniformity to the Koo Dudes standards

1. Company official name and physical address.
2. The Company Organization chart.
3. The narration of the company’s past experiences
4. Identification of key project personnel including the project manager and other technical staff in the project. Indicate their roles and responsibility
5. Provision of at least three referees for the past projects done in the similar domain.

Evaluation Criteria

All the proposals received shall be subject to rigorous evaluation and the successful proposal shall be based on the following criteria;

1. A software development firm which has been in operation for the last two years and possesses the ability to develop systems and applications in House, or ability to customize off-the-shelf or ability to solicit for a good software as a service platform.
2. The technical director of the company should have at least a Bachelor of Science degree in Computer science of its equivalents. Having a project management course is an added advantage. Professional qualifications other than the degree is an added advantage for the company.
3. The price quoted by the bidders shall be evaluated and the most reasonable shall be picked

Principal Contact Person

All the questions regarding the request for proposal should be channeled to the Kool Dudes project manager via email at  [email protected]  . The project manager shall answer all the question the bidders may have concerning the process. Please maintain courtesy while using our official emails.

Miscellaneous

It is vital for the bidders to read the following miscellaneous information to avoid being rejected automatically

Bid Dates

The official date to start bringing the proposals shall be on 3^rd September 2018 at 0000hrs and closes on 15^th September 2018 at 0000hrs. No more proposals shall be received passed deadline

Bids Locations

The proposals from the firms should be uploaded on the Kool Dudes website on www.koolduded.com under the work with us section. The systems shall automatically close when the deadline has reached.

Contract Award

All bidders shall be replied whether successful or not. The unsuccessful bidders shall be given a reason for their failure in meeting the criteria and shall be considered in a future request for proposals. The successful bidders shall be emailed via the company official email on [email protected] where the tender award letter shall be emailed

References

Bassil, Y., 2012. A simulation model for the waterfall software development life cycle. arXiv preprint arXiv:1205.6904.

Brunswig, F. and Kaiser, J., 2010. Analytical regression testing on a software build.

Chen, S.-C. and Qumei, I., 2010. Build optimizer tool for efficient management of software builds for mobile devices.

Haugset, B. and Hanssen, G.K., 2008. Automated acceptance testing: A literature review and an industrial case study. In: Agile, 2008. AGILE’08. Conference. IEEE, pp.27–38.

Imeshev, V., 2008. Method and apparatus of a build management system.

Lindgren, M., Land, R., Norström, C. and Wall, A., 2008. Key aspects of software release planning in industry. In: Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on. IEEE, pp.320–329.

Mariani, L., Pezze, M., Riganelli, O. and Santoro, M., 2012. Autoblacktest: Automatic black-box testing of interactive applications. In: Software Testing, Verification and Validation (ICST), 2012 IEEE Fifth International Conference on. IEEE, pp.81–90.

Mergel, I., 2015. Open collaboration in the public sector: The case of social coding on GitHub. Government Information Quarterly, 32(4), pp.464–472.

Pinnix, J.E., 2015. System for hosted, shared, source control build.

Rastogi, A. and Nagappan, N., 2016. Forking and the Sustainability of the Developer Community Participation–An Empirical Investigation on Outcomes and Reasons. In: Software Analysis, Evolution, and Reengineering (SANER), 2016 IEEE 23rd International Conference on. IEEE, pp.102–111.

Tsen, A., Wang, J.F., Tsai, P.-F., Fan, M.-Y., Wang, J., Mou, J.-I. and Wu, S., 2012. System and method for implementing a wafer acceptance test (“WAT”) advanced process control (“APC”) with novel sampling policy and architecture.

Vos, T.E., Lindlar, F.F., Wilmes, B., Windisch, A., Baars, A.I., Kruse, P.M., Gross, H. and Wegener, J., 2013. Evolutionary functional black-box testing in an industrial setting. Software Quality Journal, 21(2), pp.259–288.

Zeil, S., 2013. Black-Box Testing.