First, motivations for an engineer solution, which might be the initial reason of such a question:
The compression ratio of a JPEG encoded image result from a sort of average from different image blocks "compressibility". The JPEG principles rely on two combined aspects:
- the average luminosity from block to block varies slowly, hence it can be nicely predicted from preceding blocks. This is the differential prediction used on DC coefficients (here your 240);
- local stationarized parts of images can be faithfully approximated by a few quantized 2D cosines.
The scheme you provide is a simplified version, here are a few. First, the DCT is applied on $8\times8$ blocks, not $4\times4$. Hence, it is more difficult to generate long runs of zeros after quantization. Second, the quantization scheme is linear (dividing by 2). Third, with only one block, you cannot gain from inter-block prediction on DC. Fourth, with only 15 AC coefficients, the (value,run) Huffman coding might be a little inefficient. To add a few, non-adaptive tables, lack of header, may highly impact the estimated compression ratio on such a small file.
Last, the "DCT coefficient uses 10 bits" is a bit awkward. So, I interpret it as "The DC coefficient uses 10 bits". With that, you are left with 4 values and their occurrences:
- $2$ (2 times)
- $1$ (3 times)
- $-1$ (5 times)
- $0$ (5 times)
from with you can build a Huffman tree, and a non-prefix code-word for each of them. Adding their overall length to the above 10 bits can give you a rough estimate of the total number of bytes actually needed. You can use for instance an Online Huffman coding tool.
Second, you can work out your own JPEG format, on $4\times4$ blocks, and input an sufficiency large image with those repeated $4\times4$ blocks, to compute actual compression ratios.