バグ取り，機能の拡張，使い勝手の改良，移植，文書の整備，などソフトウェアを本当に使えるようにするための様々な保守作業のことです．大学や研究機関が開発したソフトウェアは，アイデアとしては新しくて新規性があっても，ソフトウェア工学的な品質(性能，機能，使い勝手，保守性，移植性，読解性，信頼性など)が悪いことが往々にしてあります．ソフトウェア進化の実践・経験はソフトウェア論文でのセールスポイントになります．

はい．ただし，研究論文として発表した主な成果以外の部分をセールスポイントとして記述下さい．従来の研究論文の成果として記述しにくい成果の記述を検討して下さい．研究論文発表後に，ソフトウェアの改良等があれば，その部分はソフトウェア論文の記述対象の候補になります．

まずはまとめる工夫・努力をして下さい．正確さや網羅性を多少犠牲にして，短く分かりやすい説明を心がけてください．一番難しいところに説明をフォーカスしてください．分かりやすい例を使うことを心がけてください．どうしても論文に入りきらない成果，あるいは正確で網羅的な説明は，ソースコードの公開場所やテクニカルペーパーで別途公開して，それを論文中で参照することも可能です．「小さな工夫が数多くあるため，短く説明するのは難しい」という旨を論文中に記述して頂いても構いません．

例えば，以下はセールスポイントの候補になります．

• バグの少なさ，作りこみ．
• 使い勝手の良さ．(ユーザ数，ダウンロード数．)
• デザインや実装の妥当性．
• 実装で得られた経験．

ケースバイケースです．ソフトウェア論文には新規性は必須ではないので，新規性を主張するための関連研究は必ずしも必要ではありません．しかし，類似の機能をもつソフトウェア(の開発)がある場合は，それらとの比較・分析があることが望ましいでしょう．

なります．なぜユーザ数が増えたのか，使い勝手やユーザサポートの工夫などの説明や分析もして下さい．

なります．経験論文もソフトウェア論文となります．ただし，単なるエッセイではなく，読者の役に立つように，事実の記述と分析もして下さい．

はい．評価基準が大きく異なりますので，執筆前に十分にご検討下さい． 

研究論文，ソフトウェア論文，のどちらへも投稿可能です．

網羅的な評価が難しい場合は，予備評価でもかまいません．評価が困難な理由，予備評価の妥当性の主張も記述してください．

いいえ．単なるマニュアルや機能の説明だけではソフトウェア論文になりません．ただし，ソフトウェア論文としての価値を含む場合でも，「作りました 論文」という悪いレッテル貼りをされることがあります．微妙なケースについては，editor ＠ jssst.or.jp まで，お問い合わせ下さい．

例えば，単に地道な努力をしただけでも，何をどのように行ったかを簡潔に具体的に説明してください．(例えば，メーリングリストによる プロジェクト管理と言っても，様々な運営形態がありえます．) なるべく頑張って書いて頂きたいのですが， 秘訣を無理に書く弊害もありますので， 分からない場合は「分からない」と書くことも OK です．

可能です．全てを外注した場合でも，自作したプロトタイプや要求仕様書・設計書などと併せてセールスポイントとすることで，ソフトウェア論文として投稿可能です．

なるべく記述してください． 客観的に示せればベストですが， 一般的に難しいため，主観的な主張でも構いません．

はい．重要な仮定や制限は(簡潔に)明示することが望ましいです．

はい，ソフトウェア論文になりえます．システムのソフトウェア部分に焦点を絞り，何が難しいのか，何がセールスポイントなのか，何をどこまで達成したのか，他のシステム管理・保守業務と何が異なる(と考える)のか，などを要領よく明確にするようにして下さい．インパクトのある，コンパクトにまとめた実データも明示してください．システム導入時の仕様書，運用時の議事録・日誌・バグ記録などはこの実データの候補になります．(単なる管理・保守エッセイにならないように十分留意ください．)

ソフトウェア論文は「ソフトウェア論文賞」の対象となります．「ソフトウェア論文賞」は２００８年１１月２７日に制定されました．詳しくは以下をご覧下さい．

• ソフトウェア論文賞表彰規定