※１：実際には利息制限法によりpの上限がある。利息制限法がどうなっているかを調べる(調査する)のもプログラムを作るうえでは重要です。
※２：[x]はxを超えない最大の整数とする。とにかく、利息を計算するときは小数点以下を切り捨てるということを数式で表現したかったのでこの記号を使用しました。詳細は「床関数と天井関数 - Wikipedia 」を参照してください。
※３：この漸化式 を解くのは（M_i = f(i)  の形にするのは）無理です。小数点以下を切り捨てるのを考えなければ、解けると思いますが。
※４：この後、この数式をもとに、フローチャートを作成することになると思います。
何が言いたいのかと言うと、メソッド内の設計と言うのはオブジェクト指向設計というよりは構造化プログラミング（順次、反復、分岐や処理の分割（サブルーチンの定義））に対する設計です。
オブジェクト指向を勉強すれば、構造化プログラミングは勉強しなくて良いと思っている人はいないでしょうか？それは間違いです。

※1：設計書が汚い…。図１については設計書というより検討資料といった方がわかりやすいかもしれない。
会社では、最終的にはお客さんに納品する場合があったり、設計者と実装者が異なる場合があるので、もっとわかりやすくする（画面設計書の画面イメージはかなり完成後のものに近いものでないと駄目かもしれない）必要があると思う。

※１：インデックスを作成すると、検索スピードは上がるが、データの更新や追加、削除に時間がかかるようになる。
※２：フルバックアップ、差分バックアップなど。それぞれ、バックアップにかかる時間、バックアップデータの量、リストアにかかる時間が異なる。

※１：「待ち行列」って聞いたこと無い？

※１：わざわざ、これを書いたのは、書籍やHPに書いてあることをやれば十分だと思っている人が多いためです。そういう人が作成した設計書は中身が薄い…。
　どうしたらリスクを回避できるかを考えて、本当に必要な設計は何かを考えないとダメです。
　もう少し具体的に言うと、ある設計をやることによって、プログラミング工数やテスト工数、運用担当者への引継ぎ時の工数が減らせたり、仕様バグなどの発生による手戻りが少なくなると考えられるのであれば、その設計は行った方がいいです。逆に設計をしてもメリットで何も無いと考えられるような設計は、本当に必要かもう一度考えた方がいいかもしれません。
　例えば、「自分が疑問に思ったところ、わからかったところを設計書に書け。そういう箇所は他の人も疑問に思うし、わからないと思うから。」と言う人がいますよね。これは正しいと思います。疑問に思うような箇所は仕様バグにつながりやすいですから。
※２：しかし、実際にはリスク以外にも考慮する必要があります。例えば、納品物かどうか。納品物に指定されている設計書は、もちろん、作成する必要があります。