Learning objectives

1. Design and develop software adhering to basic modularity  concepts, verify whether code is following basic modularity concepts, and refactor if not.

2. Design test cases using black-box and white-box testing approaches.

3. Implementing test codes based on test cases, execute them, and test a production code.

4. Use version controlling to keep track of a small software engineering project.

1. Introduction

Basic concepts of version controlling, modularity, and software testing are the key topics you have learned in the second half of this unit. This assessment evaluates your competency in those areas of software engineering. It expects the knowledge you have gained via lectures, practical classes , and continuous assessments to design and implement a simple piece of software following  modularity principles, verifying your code against a review checklist and refactor it, if needed, and design test cases and test the code you have developed.  You will document your work in each stage so that another person can understand the work you   have done and reflect on your own work  for improvements. You will use a version control system to keep track of all the activities of the whole  assessment task.

Your work will be assessed based on the code, documentation you produced, and a demonstration of your work. Mark of the assignment is given out of 100 and the assessment is worth 50% of your final mark (overall mark of the unit) as specified in the unit outline.

2. Scenario

A software company develops tools useful in colour analysis in various domains. Two of the simple scenarios the project wishes to consider are as follows:

A.    Electromagnetic(EM) spectrum and visible colours.

-      When a name of a colour is given, find the upper and lower bound of the frequency of the colour.

-      When a frequency is given, find the wavelength of it.

-      When a wavelength is given, find the frequency of it.

-      When a frequency is given,

o find if the frequency is within the visible light range or not.

o find if the frequency is within the IR range or not.

o find if the frequency is within the UV range or not.

-      When a frequency is given,

o find the colour that is produced by it.

o If the frequency is not within the visible light range, a suitable message must be provided. The message must indicate that the frequency is higher than that of   violet or lower than that of red.

-      When two frequencies are given, find if both represent a single colour or two different colours. If one or both frequencies represent non-visible colours, a suitable message/s must be provided.

EM spectrum is the range of all types of EM radiation and visible light is a type of  radiation.( (https://imagine.gsfc.nasa.gov/science/toolbox/emspectrum1.html ). The frequency ranges for visible colours with common names can be seen in Figure 1. A single colour ( say “Red”) has many variations; therefore, each colour falls under a frequency range. Required formulae and other information are shown in Figure 1. Figure 1 is available on the Assignment page of Blackboard.

B.   Colour fun facts:

Colours  are associated with  interesting things  such  as personality, stones and even  musical notes. Figure 2 shows the association of  colours with stones and musical notes.  Figure 2  is available on the Assignment page of Blackboard.

-      When a name of a colour is given, find the stone associated with it.

-      When a name of a colour is given, find the musical note associated with it.

-      When a name of a colour is given, find the matching emotion associated with it.

NOTE: Assume only the frequencies between 1 THz and 40000 THz are tobe considered valid. You may assume input frequencies and wavelengths are in integers only. For simplicity, assume colour names shown in Figure 1 and Figure 2 are the only valid colour names. Assume a suitable  valid range for wavelengths.

3. Detailed description: what you are going to do

Considering the scenarios given above ( including Figure 1 and Figure 2), you will (a) design and implement suitable production code following modularity guidelines, and (b) design test cases and test your production code using proper testing processes. You will use basic version control methods to keep track of your work. You are expected to cover all functionalities expected in the scenarios, with any supporting functionality needs to fulfill the given tasks, such as checking the validity of inputs (as per the scenarios).  When designing your production code, you must think about testing also.

Choosing how to take input, and make available output:

You are free to decide how to handle imports/exports of your software modules. Imports can be parameters, keyboard inputs, or text files. Exports can be available via return values, displaying on screen, or writing to a text file.  Look at the sections 2 -4 of the detailed description to know why these considerations are important.

You are expected to think about how easily the overall software you design can accommodate more functionalities later and reusability (such as providing more information when a Life Path Number is known).

Your work will be organized in seven parts as described below.

1.    Version Control: Apply version control process to keep track of a simple software project [16 marks]

First, read all assessment tasks and get a clear idea of what you are supposed to do in this assignment. You are supposed to use version controlling and keep track of all your work (documents and code both) related to this assignment in a single Git repository. All your code must be in a directory called “code” and documents should be in a directory called “documents” .

Derive a short plan, identifying what branches you will need, and why you need them, and when the branches will be merged.

Now, create a Git local repository (do not use GitHub) for this assessment using your surname and ID as part of the repository name following the format __ISErepo). Commit all code and documents you create in the rest of the assessment as you create and modify them. Make sure changes as and when you are doing them, but not all at once at the end .

Note: There is no hard rule about what each commit should contain, and you are expected to show your ability to use version control meaningfully.

2.    Modularity: Design modules following good design principles  [ 9 marks]

Looking at the given scenario, identify most suitable modules you will need for a software to achieve the required functionality, considering the good modularity principles discussed in lectures/ worksheets.

a.   Write down module  description/s for  modules  you  decided to implement. You must apply good modularity principles you have learned in lectures/ worksheets when identifying and planning modules. Each module description should include short, meaningful name, clear and detailed explanation on what the intended task of the module,  how it gets inputs to do the intended task and how the outputs make available, as shown in the module description examples of Lecture 8, slides 24-39, Lecture 9 slides20-33.

How imports, if any, of the modules are to be handled:

You are free to decide which input method/s are to be used in which of your  modules (parameter passing, keyboard entry, or reading from text files. ).

How exports(results), if any, of the modules are to be handled:

You are free to decide which input method/s are to be used in which of your  modules.

(Return values, display on the screen, or write to files).

However, in the Testing section, you must demonstrate your ability to test different input methods/output methods. Therefore, design different modules to use different import/export methods so that you can demonstrate testing skills.

You should decide on suitable, meaningful names for all modules and variables. You may make assumptions, if you think they are required, and state them clearly.

b.    Explain your design decisions, and how good modularity principles are considered in your modules.

Note 1

In this unit, “modules” refers to any sub-part of a program. The terms “module” and “sub-  module” are used interchangeably. The module/s you design in this stage affect the rest of your assessment. Therefore, read the whole assignment properly before finalizing the answer for this section. You are strongly advised to use an iterative approach especially for tasks 2 and 4.

3.    Modularity: Implementing the production code, reviewing, and refactoring [20 Marks]

a.    Implement the modules designed in part 2 above considering the good modularity principles discussed in lectures/ worksheets.

b.   You can use either Python (Python3) or Java for your  implementation.  Execute and verify that you have got your code running without syntax errors.

Note: This step will create a production code, not a test code.

c.    Create a short review checklist to check whether you have followed  good modularity principles. You are expected to cover all basic guidelines covered in lecture 7.

d.    Review your code using the prepared checklist, identifying any issues. You must use the format suggested in worksheet 7 to record your results. Each module must be reviewed for modularity issues.

Produce a table which shows the following information to help you and the marker to check the  work you have done (E BB : black-box, WB: white-box P: equivalence partitioning, BVA: boundary value analysis).

You may note the total marks as per the above detailed description is 90. The rest ofthe marks (10 marks) will be allocated to marks of documentation (for the Cover page, Introduction, Discussion, formatting etc.) as explained in section 7.

4. Documentation: How you document your work

You need to document what you have done in each stage of the assessment so that another person can get a clear idea about what you have done. You must produce a short report, collating all your work as part of your submission.

Your report name must be of the following format:

“ < YourFirstName><YourLastName>_<your student ID>_ISEReport”

Your report must be written in markdown. Refer https://www.markdownguide.org/ if you are not familiar with the markdown (.md ) format. This file format is helpful when tracking your documentation using a version control system.

Your report should include following sections and content:

a.    Cover page [1 mark]

Include the assessment name, your name as in Blackboard, Curtin student ID, practical class (date/ time).  This may not be in a separate page, but as the first thing in your document in a  clear format.

b.    Introduction [1 mark]

A brief overview of work you have done.

c.    Module descriptions [7 marks, part 2 of the assessment task]

Original module descriptions you have created for part 2 of this assessment.

An explanation on your design decision, and why you have chosen modules as the way you have done and any assumptions you have made, if any.

d.    Modularity [10 marks out of 20 marks of the part 3 of the assessment task]

A description on how to run your  production code with correct commands.

Sample output of running your  production code. You must use screenshots to support your answer in this section.

A brief explanation on how different modularity concepts is applied in your code.

Your review checklist, results of reviewing your production code using the review checklist, with explanation on your results, and refactoring decisions.

Revised module descriptions resulted after refactoring, if any (after doing the part 3 of the detailed description)

e.    Black-box test cases [16 marks of the part 4 (a) of the assessment task]

All test cases you have designed for part 4 of this assessment, produced in the tubular test design format shown in lecture 8, assumptions you made if any, and brief explanation on your test design decisions.

f.     White-box test cases [9 marks of the part 4 (b) of the assessment task]

All test cases you have designed as the answer for part 5 of this assessment, produced in the tubular format shown in lecture 10, brief explanation on your test design, and any assumptions you made.

g.    Test implementation and test execution [3 marks out of 20 marks of the part 5 of the assessment task]

A brief description of how to run your test code with correct commands.

Results oftest execution with outputs of test successes and failures, with short discussion of results/improvements from part 5 of this assessment.

You must use screen shots to support your answer in this section.

h.    Summary of your work (traceability matrix)[ 5 marks]

Table you have produced in the part 6 of this assessment.

i.     Version control [3 marks out of 16 marks of the part 1 of the assessment task]

Log of the use of your version control system (image of the log is sufficient), any explanation /discussion on version control. (refer part 1 of the detailed description)

j.     Discussion [5 marks]

Reflect on your own work including summary of what you have achieved, challenges you have faced, limitations and ways to improve your work with other features you have not considered, and any other information you wish to present.

Your report would be around 12-20 pages.

5. What you will be submitting and how you will do the submission

Your submission will be done in three steps.

Submission step 1:

You must submit a signed and dated assignment cover sheet in PDF format to the “Assignment submission: cover sheet” link provided in the assignment folder. Blank assessment coversheet is available under Assessments page of Blackboard. You can sign a hard copy and scan it, or you can fill in a soft copy and digitally sign it.

Submission step 2:

Your documentation,  i.e., your report (refer section 4), should  be submitted to the Turnitin  link  (“Assignment submission: step 2 documentsonly”) provided in the assignment folder. Your report submitted to this link should be in PDFformat. (You must convert yourreport in markdown format toa PDFfile  before submitting tothis link). Your report name must follow the following  format:

“ __ISEReport”

Submission step 3:

You must submit single zip file of all the work produced in this assessment to the “Assignment submission: step 3” link provided in the assignment folder. First, create a folder with name

< YourFirstName><YourLastName>_<your student ID>_ISEAssignment. Then place all your work inside this folder. Example : JohnWhite_12134567_ISEAssignment

Avoid using file formats other than .zip file to reduce delays in marking.

The folder should contain:

a. All you code files:  You must submit all your code files (production and test codes), any sample data files (if created) and any other files used/ resulted in part 3 and 6 of this assessment. Name your files in appropriate manner.

b. A single Readme file:   a short text file indicating the purpose of each file you have submitted.

c. .git sub directory of the Git repository you have used in the assessment.

d. Your report (refer section 4) in markdown format ( .md file)

e. Your report (refer section 4) in PDF format which was already submitted to the Turnitin link.

f.    Your signed and dated assignment cover sheet in PDF format which was already submitted to the “Assignment submission cover sheet” link.

Zip this folder and submit to the “Assignment submission: step 3” provided in the assignment page.

Make sure that your zip file contains what is required. Anything  not included in your submission may not be marked, even if you attempt to provide it later. It is your responsibility to make sure that your submission is complete and correct.