プロジェクトの構築段階、プログラミングの前にまずはスケジューリング、そして以外と一人だと難しいデバッグ作業

フリープログラマへの道

構築作業時の大切なことは、スケジューリングとデバッグ作業

Sponsored Link

構築段階

スケジューリング

っさ、プログラミング開始っと! その前にやるべきことがあります

スケジューリングです。

納期から逆算していきなるべく細かいスケジュールを立てましょう。 作成するプログラムを細分化しできるかぎり日毎の予定を作成したほうがよいです。

この時注意しなくてはいけないのは、現場確認がいつできるのか、マイコンプログラムであれば ハードはいつ完成し、いつからデバッグが可能なのか、不明な点があれば確認しましょう。

そして、もうひとつ重要な点は土日はスケジュールから外してください。 休日が必要ということもあるのですが、その週の予定が終了しなかった場合の予備日です。

人間なので、風邪もひきます、調子悪い時もあります、だから予備日は絶対にとっておいてください。 ひとつの目安ですが、スケジュールの前半をきつくし、後半にいくに従って緩くしてください。

作業するのは機械ではなく人間なのですから、最初はやる気満々で始めた気力もだんだん萎えていくものです。 致命的な問題点が判明する場合もあるので、とにかく前半勝負です^^

そして最後に、いくらスケジュールをちゃんと立てて地道に努力していっても、どうしても納期に間に合わない 場合が出てきます。

そんな時、いかに早く、納期に間に合わないということ察知するかが重要なのです。

納期直前に「実は・・・・」ってことにならないように、

スケジュール表さえあればと現在の進行状況から早い段階で察知することができるでしょう、 早い段階で気がつけば、対処方法いくらでもあります。

プログラム作成

さて、見積もり、仕様書、スケジュール表も完成し、プログラム作成の開始です。

でもいざプログラム作成を初めてみると新たな問題点、疑問点などが見えてきたりします。 システム全体に大きく影響がないのであれば、メモしてそのままプログラミング続行しましょう。 なぜなら、この段階では、問題点、疑問点が発生するたびに担当者の方に電話やメールしてたのでは 効率も悪いですし、担当者の方もいちいち回答するは大変です。

とりあえず、問題点、疑問点のある箇所は置いておいてどんどんプログラミングを続けるべきです、 初期の段階ではやることは山のようにあるはずです。

そしてプログラミングを進めれば進めるほど、問題点、疑問点は湯水のように湧き出してくるものなのです。 ある程度問題点、疑問点のリストが溜まってくるか、解決しなければ先に進めないとなれば、 担当者の方に質問しましょう。 この時、問題点、疑問点のリストをまずメールし、電話で連絡をとりましょう、 そして、打ち合わせなり、メールでの返答を待ちます。

ここから大切なところなのですが、このリストの回答も大切な仕様ですから、リストを保管するか、仕様書に 手書きでもいいですから修正、追加を行なっておきましょう。

プロジェクトの大きさにもよりますが、この作業を何回か繰り返すことになるでしょう。 また、パソコンソフトであれば、ある時点で担当者の方に画面、ユーザーインターフェイスを確認してもらいましょう 初期段階で作成した仕様書には当然のことながら全てのユーザーインターフェイスを明記することはできないので、 途中で何回か確認してもらった方が、後々の変更作業が減ることでしょう。

デバッグ

プログラミング作業も終了し、いよいよデバッグです。

パソコンソフトの場合、プログラミングしながらデバッグも行なえるので、半分は終わってるようなものです。

マイコンプログラムの場合、ここで初めて動作確認できるわけですね、もちろんハード部分がある程度完成していればということですが。

詳しいデバッグの方法は別ページにて説明したいと思うのでここでは要点だけにしておきます。

まず、この時点で全てのバグを発見し修正するのは不可能であるということを覚えておいてください、だからといって いい加減にデバッグしていいと言ってるわけではありません。

時間に制限があるということです、その限られた時間内になるべく多くのバグ修正を行なわなくてはいけません。 バグのなかには、致命的なバグ、後でも修正可能なバグ、どうでもいいバグなど、様々です。  致命的なバグとは、通常の作業においてハングアップしてしまう、データベースインターフェイスのバグなどなどです。 とにかく、いち早く致命的なバグを探し、修正しましょう。

そして、できることならバグリストを作成し修正記事を残しておきましょう。後々役に立ちます。

さて、自分でできる可能な限りのデバッグを行い、バグ修正が終わったとします。 ここで会社であれば誰か他の人に一通りアプリケーションを使ってもらってみてください。 たぶん、貴方が気づかなかったバグが次か次へと発見されてしまうでしょう。 自分で作成したプログラムを自分でデバッグする場合、恐ろしいというか自己防衛本能というか 無意識のうちに危険な操作を避けているものなのです。

フリーランスの場合、一人でプログラミングもデバッグも行なう分けですから、このことをよく覚えておいてください。 デバッグ時には別人になりましょう^^

デバッグも終了といいたいところですが、もうひとつこの段階で作成したほうがいいものがあります。 「チェックリスト」です。 

チェックリストとは、このアプリケーションに対して何をチェックするべきかという一覧表です。 この先、仕様変更による修正、新たなバグのための修正が行なわれるはずです、いや、必ずあります。 その修正が他の箇所の機能に影響を与えないとも限りません。

この段階であれば、デバッグ時の新鮮な情報が貴方の頭の中やバグリストに残っています。 何処が危ないのか、何処が正常に動作すればこのプログラムは正常といえるのか、勘がつかめているはずです。 後々のために「チェックリスト」を作成してください!

Sponsored Link


Copyright (C) Breath.All right reserved