下位バージョン (かいばーじょん, low order version) ソフトウェアやハードウェアに 
 おいて、一連のシリーズになっている製品の、低価格なバージョン。多くの場合 
 は上位バージョンの一部の機能だけを持っていたり、量的な制限をされていたり 
 またハードウェアの場合は処理速度が遅かったりする。 
  
 しかし中にはまるで別製品であるものや、かえって下位バージョンのほうが 
 上位バージョンより使いやすかったり高機能だったり高速だったりするケースも 
 ある。こういう事は各々のバージョンを制作しているのが社内の別のチームで 
 あるためである。また、物事は低予算でやったほうが良いものができることもある。 

開発 (かいはつ, development) コンピュータの世界では新しいハードウェアや  ソフトウェアを企画・制作することをいう。一般社会では山林などを切り開いて  住宅地などとして整備したりすることや、商品を今まで販売していなかった地域  で販促活動を行い顧客を増やすことなどを言ったりするが、コンピュータの世界  でも、今までになかったハードやソフトを作ることを開発というわけである。    こういう用法が世間にまだ良く知られていなかった頃は、会社の営業内容に  「開発」ということばが入っていると、飛び込みの営業や電話のアポイントなど  の仕事をさせられるのでは?などと求職活動をしている人に思われたりした  ものである。
開発言語 (かいはつげんご, language for development) ソフトウェアの開発  を行うのに使用する言語。
開発工程 (かいはつこうてい, development process) ソフトウェアやハードウェア  の開発を工業的な製品の製造になぞらえてその各段階を表現したもの。    基本的には設計・製造・試験・導入の段階に分けられ、設計は概要設計と  詳細設計、または外部設計と内部設計、製造はプログラミング・  コーディング・パンチ・デバッグなどに、試験は単独試験と結合試験、  更には運用試験に、導入はインストール・教育・調整などに分けられ  るが、開発モデルによっては幾つかの工程が無かったり統合されたり、  あるいは前に戻って何度も繰り返されたりする場合もある。
開発コードネーム (かいはつこーどねーむ, codename) 正式に製品化あるいはリリース  する前に、ソフトやハードの開発段階で、内輪にその製品やサービスのことを  言うために付けた名称。しかし最近ではメーカーが完成後に買ってくれる、  あるいは利用してくれる人たちに期待をもたせるために、敢えてその名前を  公表して、それが持つはずの機能の説明をしたりする場合も多い。    開発コードネームは途中で変更される場合もあるし、また幾つかの社内の  プロジェクトが独立して進められていて各々に開発コードネームが付けられて  いたのが、諸般の事情でいくつかが没にされてしまう場合もあり、そういう時  は概して発売予定が延びることが多い。  特にMacintosh用のOSでSystem7の後継OSを巡る混乱は有名である。当初は  Coplandという開発コードネームのOSがSystem8となる筈で、その先には  Gershwinという開発コードネームのOSも予定されていたが挫折。  System7.7 として予定されていたTempo という開発コードネームの従来型OS  がSystem8の名前で発売され、System7.8の予定だったAllegroという開発  コードネームのOS がMacOS 8.5となった。    そして結局Copland計画は挫折し、独自開発を断念してNeXT社を買収し、  NeXT系のOSであるRhapsodyという開発コードネームのOSが計画されたが、  これもそのままでは進行できず、かなりの再編・修正を経て、やっと  新世代OS Mac OS Xの発売にこぎつけることができた。    Windowsの方では、従来型Windowsの流れを汲むWindows95Chicago,  DEC系の新型OSの流れを汲むWindowsNT 3.51がDaytonaで、その次のOSとして  Cairoという開発コードネームのOSが予定されていたがこれは挫折。その  思想はWindows2000などに部分的に取り入れられた。Windows2000では本来は  従来型OSと新型OSの統合をしたかったのだがそれは実現せず、Microsoftは  つなぎ的に、Memphis開発コードネームWindows98, Millenniumの開発  コードネームのWindowsMEをリリースする。そして両者の統合はWhistler  の開発コードネームのWindows XPでやっと実現した。そしてその次の世代  のOSはLonghornという開発コードネームで呼ばれていたがWindows Vistaと  いう製品名で2006年11月から販売が開始された。
開発コード名 (かいはつこうどめい, codename) →開発コードネーム
開発モデル (かいはつもでる,development model) 主としてソフトやシステムの  開発の進め方に関する思想。以前はウォーターフォール・モデルといって  打合せ→設計→プログラミング→導入といった、がっちり固めた手法が  取られることが多かったが、色々と問題が出てきて現在ではあまり使用  されなくなっている。主な問題点は    ・開発に時間がかかるため、当初の打合せ通りに作ると時代遅れになる。  ・打合せ段階では予測できなかった事態への対応が難しい。  ・近年のソフトウェアは複雑になりすぎて、打合せ段階で発注者側がソフトの   イメージを把握できない。    そのため次のいづれかの手法が取られることが多くなってきた。    ■プロトタイプモデル  まず「ひながた」となるソフトを制作して提示し、気に入ってもらったら  本格的に制作する。    ■スパイラルモデル  まず基本的な機能だけをリリースして、実際に使ってもらいながら機能の  拡充をしていく。    ただ、このような開発モデルを取る場合、開発側は打合せを進めていく  最中にも従来型モデルに比べて多大な開発費用を投入しなければならない。  そのためかなり進行させてから「キャンセルします」と言われると、そこ  までの開発費用が回収できなくなる。また発注側も最終的にどれだけの  費用がシステムの開発に必要なのか、明確に把握することができないため  発注側と開発側との相互不信が発生しやすい問題もある。
開封確認 (かいふうかくにん,message disposition notification)  メールを受信して開いたことを発送者に知らせる仕組み。  メールを受信した時に送信される不在通知とは送信される  タイミングが異なる。    古き良き時代には、メールを送るとわざわざ手作業で「受信しました」という  メールをとりあえず送ってくる人もいたが、開封確認はそういう作業を規格化  したものともいえる。RFC2298で規定されている。    メールを送信する時に開封確認要求ヘッダー(Disposition-Notification-To)  を入れておくと、  手動送信の場合は、開封確認メッセージを送って良いか聞いてくる。  自動送信の場合は、自動的に開封確認メッセージが送信ボックスに入る。  (即時送信が設定されている場合はそのまま送られる)    今日では開封確認を送ることは、spamの発送者に自分のアドレスが  生きていることを知らせることになり良くない。また一般の送信者に  とっても今日のようにメールの数が多い状況の中で、そういう余分な  メールのやりとりをすることは煩わしいし、またトラフィックを食う  元ともなる。    OutlookExpressではデフォルトで開封確認を要求し、また開封確認要求  が送られてきたら返事をする設定になっているが、セキュリティ上好ましく  ないので、少なくとも開封確認要求は無視する設定にしておくべきだし、  またマナー的な問題から、開封確認を要求するのもあまりお勧めできない。  (社内のメールのような場合を除く)