Reference no: EM132582795

CMP73010 Managing Software Development - Southern Cross University

Assignment 1

Part 1 - Testing

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 unrelated so you should consider them separately. Note: testing tables are not counted as part of the word count.

The Acceptance test
The consulting firm you work for has been contracted to develop a new ‘rideshare' app (e.g. Uber, Ola). In particular, the client has asked your team to specifically develop an acceptance test that focuses on user privacy. The system user requirements for privacy in this test must address:
1. The system provides a secure login and verification system
2. The system must provide a secure payment system
3. The system must verify the user enters the correct vehicle
4. The app does not collect user ‘location' related information ‘by default'
5. Third party services do not automatically obtain user information and that the user should have the option to authorize third-party services if they wish

Outline an acceptance test for the above system as described by generating scenarios of each requirement. 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. These scenarios will not count to the total word count. It is strongly suggested you do research on ride-sharing apps. Analysing comparative ride- share will prompt your approach to generating the ‘scenarios' for this test and place yourself in the perspective of the user. You may even download an example of one (they are free to download and install), but it is not necessary.

Remember that acceptance tests can be designed without access to the actual product. Detailed testing of the product is for the next part of this assignment (detailed black-box testing). 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 new specification.

The detailed black-box test plan
As part of a client presentation to explain the benefit of black-box testing to both a technical and non- technical audience, you are asked to design a detailed black-box test for a popular software product.

The product to develop the detailed black-box test plan is the PowerPoint 2016 Print dialog, as shown below. This version of Powerpoint 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.
Produce a detailed black-box test plan for this dialog box. 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 this part of the total product. The total PowerPoint 2016 product is an extensive system so do not attempt to do a detailed test on more than this dialog. Remember that testing is a creative process, especially when trying to break the software. You should come up with test ideas that other people will not think of (including your marker). 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 will be sufficiently rewarded but there are basic testing strategies that you must describe.

Part 2 - Configuration management

Code/file version management
Version management systems are a daily reality for the software development professional. On GitHub is a public project named: TeachBen/CMP73010-assignment1-2020
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) and request a pull of the project

Note: 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 that 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. As this only requires your GitHub account name it will not be counted among the word count.

Build Management
A client of yours has confidential plans to develop an open-source web browser and has asked you to provide advice on build management by looking at a competitor (Mozilla ‘Firefox').
Give your advice as follows:

1. A brief description of the nightly build system of Mozilla Firefox for managing changes to software and systems
2. How Mozilla arrives at a release of Firefox that is distributed to the public
3. Advantages and Disadvantages of this system for the client.

Note that the nightly builds evolve 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 about 400 words.

Part 3 - Request for Proposal (RFP)

Provide a detailed RFP for the following system of your client, Spearhead Technology Services.

Spearhead Technology Services is a business that sells a variety of Internet of Things (IoT) products (e.g. IoT sensors, smart city devices such as; traffic lights and waste solutions, smart home devices and appliances such as; smart entertainment systems, smart lighting systems, smart refrigerators, smart toasters and more). They also provide IoT device repairs and accessories. They want an integrated system to support their six 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 customer relations database with information about products and services purchased, devices left with them for repair (customer details, customer purchase history, problem report, work details, etc.)

2. A marketing system that allows for digital marketing using e-mail, social media, and any other modern marketing techniques. This will use details in the customer relations database but allow other prospective customers details to be entered in an existing Spearhead Technology Services 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 Spearhead Technology Services locations when necessary. As the company specialises in IoT products the SMS will need to be able to have real-time monitoring and diagnostics of some IoT products (e.g. smart cities products).

4. Provide reports for management, who may be at any location, of the status of all the above so they can order stock, recruit staff and make other management decisions.

Your RFP should use one or more recognised guidelines that you will reference. You may be tempted to go overboard here so try to restrict your RFP to a reasonable size (up to 1000 words maximum). You must seek to strike a balance here. You must be clear enough as to not waste your firm nor the client's time with an unnecessary volume of applications but also 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.

While it will be important to do some research on IoT products, the above point also means your RFP should not contain excessively technical information about the requested system.

Your RFP should allow for some 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. Your RFP must be clear in its request for the differing categories of software procurement that can exist in an RFP.
As you will learn, your RFP must 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 should 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 Spearhead Technology Services theme. The key to a quality RFP is being both concise and clear in asking for what your client wants!

Attachment:- Managing Software Development.rar