CMP73010 Managing Software Development 计算机assignmen代写

100%原创包过,高质代写&免费提供Turnitin报告--24小时客服QQ&微信：120591129

CMP73010 Managing Software Development 计算机 assignment 代写

CMP73010 Managing Software Development

Assignment 1 (S2 2017)

This assignment is due 28 th August, 2017, any time before midnight. The assignment has a small

component that must be completed on-line but a majority is a written report. Suggestions for the

report structure are given in each section of the requirement. The report itself should be submitted

through the Turnitin link in your MySCU site.

Please note that the assignment is due some weeks after the required materials are covered in the

on-line sessions. Please do not leave the assignment to the last minute as you can start work on

much of the assignment well before the due date. If you do require an extension for submission you

must request this before the due date. Unless an extension is agreed, a late penalty will be applied

as per the Unit Information Guide.

This assignment covers the testing, configuration management and software tendering processes

with each of these a separate Part of the assignment. Hints and clarifications may be published by

your unit assessor in the unit forums.

Part 1 – Testing (7 marks)

There are two components to this part of the assignment. You are required to produce an

acceptance test description and a detailed black-box test description. These two test types are

related but you should consider them separately and refer to Workshop 3 for ideas on how to do

this part.

The Acceptance test (3 marks)

A university requires a system to allow on-line checking of student submissions to detect possible

plagiarism. The system must track student submission time and dates, and provide an analysis of the

matches found in other student’s work, in Internet documents and in paper based publications such

as books and magazines. The analysis will be available to the student who submitted the assignment

and the marker of the assignment.

The matching must be configurable providing:

1. Optional checking of bibliographies

2. Allow proper quotations to be excluded

3. Allow setting a minimum number of matching words

4. Allow resubmission of assignments by students up to a given date/time

Outline an acceptance test for the above system as described. In the study guide, this is steps 1, 2

and 3 of the acceptance test criteria. Most of step 1 is in the above system description but you can

refine and expand if you wish.

Remember that acceptance tests can be designed without access to the actual product, though in

this case you will know about a possible candidate from the black-box testing below. Other products

may be acceptable so do not restrict your plan to the product you have access to. Detailed testing of

the product is for the next part of this assignment. You can enhance the requirements above if you

wish, or clarify them based on your own knowledge. If you do adjust the requirements your plan will

be assessed against your additional specification. You should be able to describe your acceptance

test in 300-500 words (1-2 pages).

The detailed black-box test plan (4 marks)

A detailed black-box test plan does assume you a very familiar with the product you are testing. The

aim here is to use your knowledge of testing to black-box test an existing piece of software in detail.

The product to develop the detailed black-box test plan is

Microsoft Word 2106 Print dialog as shown on the left. This

version of word is available to all students so you can see its

operation if you need to.

The various drop-down lists will vary between users of the

software. When you specify tests, you can assume that the

setup for the test can be achieved. For example, you may say

“add five printers and select the last one” and assume that this

can be achieved.

CMP73010 Managing Software Development 计算机 assignment 代写

Produce a detailed black-box test plan for this dialog box as we

did in Workshop 3. You do not have to follow the format we

used in Workshop 3, but it is a place to start thinking about the

testing. You do not have to produce a detailed black-box test

for any dialog box or new screen that any of the controls

launch. However, you may have to refer to the selectable

options for testing each of the widgets on this dialog as you test

the interaction between widgets.

Note that you can, if you wish, apply your test plan to the product, e.g. you can test individual input

fields and interaction between fields. This is a commercial product, so you would expect the product

to pass the test (if you do find a bug then we will notify the software developers). For this

assignment we are looking at the test plan, not the actual test results.

For the detailed test plan you will be assessed based on how your test plan applies to the indicated

part of the total product. The total Word 2016 product is extensive system so do not attempt to do

a detailed test on more than the this dialog.

Note that testing is a creative process, especially when trying to break the software. You will come

up with test ideas that other people will not think of (including your marker). However, we have

discussed testing strategies in Workshop 3 which also appear in the study guide and textbook. In

addition, it will not be possible to exhaustively test the software. Marks will mainly be awarded on

the completeness of your strategy for testing for each widget. Creative testing ideas may also be

rewarded but there are basic testing strategies that you must describe as well.

Part 2 – Configuration management (7 marks)

Code/file version management (2 marks)

There is a GitHub public project named:

barrywilks/CMP73010-Ass1-2017

You are required to sign up to GitHub and then:

1. Fork this project into your public space

2. Modify the Word document called CMP73010.docx (it contains instructions)

3. Request a pull of the project

Note that at various times the project manager will pull changes into the mainline. This will be

reflected in your GitHub view of the project.

Important: In your assignment submission for the rest of the assignment you must state your

GitHub account name! (so the marker can confirm your project activity). Remember that your name

will be public so please do not disclose any personal information. Do not place your student-ID in

the GitHub document or elsewhere in the project.

Build Management (5 marks)

Briefly describe the Microsoft nightly build system for managing changes to Microsoft operating

systems and other software (2 marks).

Then, give your description of:

1. Advantages of this system for Microsoft and other systems (1 mark),

2. Disadvantages of this system for Microsoft and other systems (1 mark), and

3. How does Microsoft arrive at a release that is distributed to the public (1 mark).

Note that the Microsoft nightly build has evolved over time so carefully reference the facts that you

have gathered and indicate the dates to which your descriptions refer.

You should be able to answer this section in 300-500 words (1-2 pages).

Part C – Request for Proposal (RFP) (6 marks)

Provide a detailed RFP for the following system.

Kool Dudes Mobile is a business that provides new mobile devices, device repairs and mobile device

accessories. They want an integrated system to support their 5 branch shops as the opportunity

arises. They envisage the system will evolve over time and plan to expand to many more locations.

Their initial requirements are:

1. Provide a repair database with information about devices left with them for repair

(customer details, problem report, work details, etc.)

2. A marketing system that allows electronic marketing using e-mail, social media, and any

other modern marketing techniques. This will use details in the repair database but

allow other prospective customers details to be entered in the existing Kool Dudes

website (not part of this RFP).

3. A stock management system that includes products for sale, parts for use in repairs,

automatic ordering from wholesalers. The system must be able to be used for individual

locations to find products and parts at other Kool Dudes locations when necessary.

4. Provide reports for management, who may be at any location, of the status of all the

above so they can order stock, hire and fire and make other management decision.

Your RFP should use one or more guidelines that you will reference. You may be tempted to go

overboard here so try to restrict your RFP to a reasonable size (say 1000 words maximum), less if

possible. Remember that the less restrictions the better in an RFP so that the responders can come

up with new ideas that you have not imagined so far. This also means your RFP will not contain very

much technical information about the requested system, but will contain information about your

existing systems (the web site, unless you add to the specification).

Your RFP should allow for a bespoke software development but it should also clearly be able to

consider existing applications, solutions built from components, SaaS solution, other solutions and

any combination of these.

As you have learnt, Your RFP will contain:

1. The system description

2. Explanation of how you would evaluate proposals received

3. Explanation of how you would answer questions

4. Any other facts that would ensure proposals are useful to you and worth a supplier’s effort

to respond to the RFP.

Note there are many things missing from the above specification that you may wish to add to your

RFP. A lot of your RFP will be details that you will need to make up, e.g. who to contact and how.

You can use your own information or make up names and other data along the Kool Dudes theme.

CMP73010 Managing Software Development 计算机 assignment 代写