Project: Mobile App

Project: Mobile App

Related outcomes from the unit outline:

1. Apply advanced knowledge to analyse and design mobile software;Interpret metrics produced by a relevant framework to build an effective mobile software product;

Program a simple mobile application.

Team size: Individual

Suggested length: None specified

Marks: 40%

Submission instructions: To be submitted electronically via Canvas, starting at week#8

Referencing: As per ECUs APA guidelines

Academic Integrity: Ensure that you have read ECUs policy on academic integrity

Task list:

Implement an app using Solar2D and Lua based on the problem statement (supplied separately). Submit your app code so that it can be verified in the simulator.

Create a five-minute video, demonstrating relevant aspects of your app

Create a Word document containing:

A record of the black box and unit tests you have completed to verify that your app works as expected. Also submit your unit tests (should be parallel to your code directory).

A predictive model, based on your code and time log data (include data from at least eight PSP snapshots). Also submit your raw predictive model (Excel spreadsheet, R code etc.)

Background:

Testing:

Black box tests are based on the requirements (so you should list the requirements) and test end-to-end functionality. In that sense, if you can define the input and output of some aspect of functionality, then you can design a black-box test to confirm that the function works.

In contrast, unit testing involves testing an individual software component/function and may also require developing test driver modules or test harnesses. A suitable unit testing framework is Lunatest. Test-driven development (TDD) means writing unit tests before functional code as part of the build process. The unit test is based on one or more requirements. You then write code that passes the test (therefore meeting the requirement). It is not required that you use TDD, but it may be useful.

Video:

The video should a) demonstrate the app functionality; b) confirm the tests; and c) highlight challenging problems that you solved or reveal elegant aspects of your solution. Show the code or other artefacts as needed.

PSP:

The Personal Software Process (PSP), as espoused by Watts Humphrey, attempts to focus on improving individual performance in the upper levels of the CMM (the Capability Maturity Model). The PSP recommends establishing metrics to measure aspects of the software process and to test personal competency by writing programs measured with these metrics. Humphrey (1996) contains some background on the PSP.

Keep accurate records of two things: 1) the size of the code (in lines); and 2) how long it takes to write the module/function (include testing time).

Submit your code and time logs each week, starting from week#8.

Metrics/Measurement:

Software Engineering is about managing process. By managing process, we obtain a product that has consistent quality attributes. Quality thus transfers to the next project. Therefore, software engineers spend time and effort measuring and recording details about the production of software, especially trying to predict future behaviour from past data. Many predictive models for software estimation are of the general form:

Person-Months = a*KLOC^bwhere a and b are defined constants, * and ^ are the usual multiplication/exponentiation operators and KLOC means thousands of lines of code

(In your model, you would replace person-months with person- hours or minutes and KLOC with LOC as your programs are small).

When using this type of model, two questions arise. First, where do these constants come from and second, could this model be used as-is or would it need to be calibrated for each organisation or application domain?

The constants come from fitting a curve (the above equation) to known data about projects (their KLOC and PM results). Calibration is essential as every software development firm is different and capabilities differ across project teams.

A common method used to fit curves to data is least-squares regression. For a linear model, the equation is often expressed as: y = m*x + b, where m is the slope of the line and b is the point where the line crosses the y-axis (called the y-intercept).

Calculate constants for a predictive model, based on your collected data. There should be at least eight data points. Use the last seven LOC/ time data points for this purpose. Keep the first point aside for validation. The above equation will need to be transformed into a linear form to use the linear model above. Use: Log Person-hours (or minutes) = Log a + b * Log LOC (in this case Log a represents the b parameter in y = m*x + b.

There are several tools/packages/languages you could use to perform this task (e.g., Excel, R, SPSS, Python).

Having created a model that predicts time from LOC, use the actual values for LOC from the first Lua module/function written to predict the time to complete the first Lua task. Is the estimate similar to the actual time taken? Discuss the difference or similarity.

Note: As the purpose of this component is to measure aspects of your PSP, the marks for this component of the assessment are given based solely on your supplied PSP data.

References

Humphrey, W.S. (1996). Using a defined and measured personal software process.

IEEE Software. (13)3. May, 77-88. DOI=http://dx.doi.org/10.1109/52.493023Checkpoints

Important: Independent of your final app submission, you should submit small working versions of your app at checkpoints in each of weeks 8, 9, and 10. Each checkpoint is worth up to 5 marks (so the final app is marked out of 30, including the video, to make 40 marks in total). Include the code and a screenshot showing the result(s). Dont forget to submit one or more PSP time logs at each checkpoint to get marks for the PSP component.

A). Week#8: App should output correct values of area to the console for the data supplied in table 1 of the Problem Statement. Use a fixed number of points (10,000). (2 marks)

B). Week#9: App should print relative error for a range of points between 10 and 1,000,000 (increasing by powers of 10) for the curves from week#8. (3 marks)

C). Week#10: App should allow input of the number of points and display correct plots of the curves for the data supplied in table 1 of the Problem Statement. Some unit tests implemented. (5 marks)

Note: The checkpoint deliverables are not eligible for the standard assignment extension conditions. If they are not submitted by the due date/time for that week, they will not be assessed and will not count towards your final mark.

Appendix A - PSP Time Recording Log

Student: Module/Function Name: File name:

Start Date and Time Stop Date and Time Time Taken LOC Paste actual code here

Mobile App: Problem Statement

Monte Carlo methods emerged during the Manhattan Project, where models were needed to show what would happen in a chain reaction-clearly, actual results differing too much from the projections of the model would be an undesirable outcome for anyone near the reactor. The required neutron diffusion model was too complex to solve analytically (with an equation), so the project used numerical methods to calculate the result. In this case, Monte Carlo means simulating by means of putting random numbers into an equation and calculating the results. This turns out to be a good approximation if the number of guesses is large. Today, Monte Carlo methods are used in Mathematics, Physics, Chemistry, Economics, Computer Science, Cyber Security and many other fields.

One simple application of Monte Carlo methods is calculating the area under a curve. What you will develop is an app that calculates and displays the area under a range of curves.

Figure 1: Area under the curve of y = x over the range 0 to 5, with 10,000 points.

We start by (logically) drawing a rectangle that encompasses our curve between the given limits and the x-axis, so for equation 1 of table 1 (see figure 1), we could use a rectangle bounded by the bottom left (0,0) and top right (5,5). We then generate a random point within the rectangle and compare it with the test function (curve). If we keep count of the points below the function (y = x, in this case) and the total points generated, with enough points we can get a good approximation to the area under the curve because:

#points under the curve =Area under the curve

Total# pointsArea of the rectangle

Therefore:

Area under the curve = (#points under the curve / Total# of points) * Area of the rectangle

Plot graphs of the equations in table 1 for varying (input) total numbers of points. Compute and display the area under each curve, between the curve and the x-axis.

Table 1: Sample curves and associated areas.

Equation Min Max Actual Area

y = x 0 5 12.5000

y = x2 -2 2 5.3333

y = -x3 + 6x2 x +17 -2 5 222.2500

y = 415x3+21x2+41x+3 . e-0.5x0 4 5.7674

An example of the plot for equation 2 is shown in figure 2.

Extend your app by allowing the input of varying min and max limits.

Figure 2: Area under the curve of y = x2 over the range -2 to 2, with 50, 000 points.

The more points, the better the approximation approaches the actual area. It is useful to know the error in the calculation.

The relative error can be calculated by:

RE = | calculated area actual area |

actual area

%RE = | calculated area actual area | . 100%

actual area

The RE varies with the number of points by a factor of 1N, where N is the number of points.

Extend your app further by plotting %RE in area values (and the theoretical %RE line) for a range of points (10-1,000,000 in powers of 10 on the x-axis, 0.1-100 in powers of 10 on the y-axis) for each curve.