紛らわしい・似たような用語

removeとdelete

  • remove: 取り除く

  • delete: 削除する

設定

  • Properties（プロパティ）は一つのコンポーネントまたはオブジェクトの特性を表すもの

  • Options（オプション）はグローバルな振る舞いを変えるもの。 無効にできるというニュアンス

  • Settings（設定）とPreferences（ユーザー設定）は複数の選択肢があり、無効化するものではないというニュアンス

  • Configuration（構成）はユーザー向けにカスタマイズするもの（ユーザーでなくアプリケーション提供者が予め設定しておくということか？）

アプリケーション提供者が決めるものはconfiguration（構成）、ユーザーが決めるものはsettings（設定）という感じかな。

https://qiita.com/aosho235/items/ef7a99396f69442d2cf2

作成と生成

作成はcreate

生成はgenerate

印象としては勝手にできる系は生成、すごくコアなところから作り出すのは生成な気がする

http://d.hatena.ne.jp/UoraTomort/20090829/1251557178

rpmのdevelとsrcの違い

  • devel

    developmentの略

主に開発に関連したものが入っているパッケージ

開発用のツールだったり、コンポーネントだったり。

動的な仕組み（機能がモジュール化されているもの）を使うソフトウェアの場合は、通常の使用でも必要になることもある

ライブラリオブジェクトやヘッダファイル（lib.soや.h）が含まれている

  • src

    すべてのソースコードが入っている

イメージとしては、開発できるもののみを切り出したのがdevelでsrcは全ソースコード

完成の定義

ストーリー、スプリント、リリースなど、さまざまなレベルでの「完成」の定義について

「完成」という言葉は「完了したこと（complete）」を意味するのによく使われます。開発チームが「このストーリーは完成した」と言うときはこの意味です。また「受け入れたこと（acceptance）」を示すのにも使われます。プロダクトオーナーが「このストーリーは完成だ」と言うときはこの意味です。私が人に教えたり、コーチするときには、こう言っています。「完成（done）」と言ってはいけません。代わりにもっと状態を具体的に表すよう「完了した（complete）」「受け入れた（accepted）」という言葉を使いましょう。

mntとmedia

mnt:一時的なマウントポイント。mediaとの違いは、一時的なファイルシステム（fstabなど）のマウントに使う点。

media:リムーバブルメディアのマウントポイント。（floppy、CD、DVDなど）

コミッターとコントリビューター

本来は、

コミッター：開発やメンテナンスにおいて，プログラムを書き換える権限を持つ人

コントリビューター：バグ報告やパッチ配布を実施する人

だが、

GitHubではあまり違いがなくなってきている。

元来コミッターのほうが上位。

使うときはどっちでもいいんじゃね？

財務・会計・経理

「経理」は「仕訳を切るための知識体系」という感じで、

「財務会計」を行うためのテクニックの一つ、というニュアンスです。

「会計」は、「財務会計」と「管理会計」を合わせた、範囲の広い、割と漠然とした言葉です。

「財務」は、「会計」とはちょっと毛色が違います。

基本的には、「資金調達をする仕事」です。

で、ちょっと乱暴ですが、会社内の部門に当てはめると。

「経理」と「財務会計」をやるのは経理部です。

仕訳を切ります。

「管理会計」をやるのは経営企画部です。

どの製品が儲かっていてどの製品が儲かっていないのか、を明らかにする帳票を作り、経営者に示します。

「財務」をやるのは財務部です。

経理部や経営者と連携を取りながら、資金計画を練り、銀行の人と交渉してお金を借りたり返したりします。

ConfigurationとSettings

構成 >>> 設定

構成の中の小さい範囲に設定があります。

Configurationは、大きな設定のときに使う。

Settingsは、個別要素の設定のときに使う

http://profile.ne.jp/ask/q-44002/

保存と保管の違い

保管(中期〜長期、使用頻度低い、より整理・管理された状態)

保存(短期〜中期、使用頻度高い)

プロセスとプログラム

プログラミングとコーディング

製造は、小規模PJやアジャイルではプログラミングであるべきで、大規模PJや仕様が確定しているPJではコーディングであるべき。

正常、異常

システム構成とネットワーク構成の違い

システム構成とネットワーク構成は大体同じような図になるが、システム構成の方は人や外部装置まで含んで書くことがある。その代わりシステム構成は、ネットワーク情報を詳細に書くことはない。

ファイル名でのconf,config,iniの違い

テレメトリ・コマンド関係の紛らわしい言葉たち

要求と要件

「要求」は単に求めていることであり、「要件」は形式化した要求条件である

仕様書と設計書と要件定義書と要求仕様書と設計仕様書の違い

  • 仕様書とは「WHAT？何がしたいのか？」について書かれたもの。設計の前に書くもので、そのシステムが実現すべき機能や動作上の制約などを定義する。仕様書は確実にユーザに公開されるべき。

  • 設計書とは「HOW？どのように作るのか？」について書かれたもの。仕様書をもとに、具体的にどうやってシステムを開発・構築していくかを記す。設計書はユーザに公開されなくてもよい。

  • 要件定義書の目的は、まずシステム開発のゴールを定めること。利用者がそのシステムなどで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていき、まとめた文書。RFPの業務要求とほぼ同じ。

  • 要求仕様書は要件定義書と同様のようなもの。アジャイル開発やプロトタイプ開発などは、これらの各工程の境目が曖昧で、「目に見えるモノを作りながら仕様を固めていく」というスタイルの場合に使われることが多い模様。要件定義書の前段階として、今回の依頼に何を期待しているのか目的を整理し、付随する要求も含め関係者が矛盾なく認識できるよう『仕様化』したものとして使われる場合もある。が、結果的に要件定義書のようなものになるはず。

  • 設計仕様書は、よくわからない。使わないほうが無難。まず設計書なのか？仕様書なのか？両方なのか？個人的には、設計の仕様書のことだと思っている。

シンプルに時系列で整理すると、

要求分析を行い->要件定義書作成->仕様書作成->設計書作成となるはず。

要件定義がしっかりしている場合、仕様書は必要なくなるはず。

何らかの設計作業の入力となる「作るべきものの指定」が「仕様」、それを記述した文書が「仕様書」であり、設計作業の結果を記述した文書が「設計書」であるという考え方が多くの方に違和感なく受け入れられそう。

誤解しやすい用語の解説集

検証と妥当性確認

・ 検証（verification） 『正しく構築した』ことを確実なものにすること

・ 妥当性確認(validation) 『正しいものを構築した』ことを確実なものにすること

テスト、評価、検査

テスト：対象が、正しく動作するかどうか確認する作業のこと。

評価：対象が、要件に対してどのレベルにあるかを測る作業。測るためには、テスト結果や、他の測定結果、バグの発生状況、収束状況など、多くの情報を使用する。

検査：対象に欠陥がないかどうかを確認する作業。（工業製品の場合、個々に検査を行うまたは、抜き取り検査を行う。）

会議と打ち合わせの違い

会議は、全員参加で、議題があり、終了後に決定がある場

打ち合わせは、調整したり、ブレストしたり、問題解決したりする場

前提条件と制約条件（事項）

  • 前提 ドキュメント土台。ドキュメントを読む上で共有しておかなくてはいけない認識等を書く。始める前に合意していた条件。とりあえず、システムが正常に動く状態までが前提となる。設計書では、設計するにあたり合意した条件となる。取扱説明書では、設計書の前提条件+製造過程で合意した条件となる。

  • 制約 ソフトウェアの説明書などに使われている言葉。「できない事」の意。前提をおいた上で取り除けなかった禁止事項。システムが正常に動いた上で例外が発生したりする状態を記述する。設計書では、前提で絞りきれなかった（前提だけで普通はうまく動くが、特定の状態を禁止しておく必要がある条件）条件となる。取扱説明書では、製造時にどうしても取り除けなくなった禁止事項と前提だけで普通はうまく動くが、特定の状態を禁止しておく必要がある条件となる。

最終的には、禁止事項=前提+制約となる。個人的には前提はあってよいが、制約はない方がいいソフトウェアだと思う。

Bean,DTO,DAOとか実体を表す系の違い

  • Bean

    ・Sun Microsystems社のJavaBeans仕様に準拠した再使用可能なソフトウェア・コンポーネント。

・最低限、クラスにはプロパティが必要。

・プロパティはメソッドを使用する他のJavaクラスに公開される。

・ただし、アクセス修飾子はprivateとし、次のメソッドをコールする必要がある。

set PropertyName

get PropertyName

※PropertyNameは、プロパティの名前。

プロパティはBeanクラスに格納され、メソッドを介してこれらの属性を取り出し、設定する。

  • DAO

    DB(永続ストア)にアクセスするためのクラス。

たいてい、VOを引数に受け取って、INSERT、UPDATEを行ったり、SELECTしてVOやVOのリストを返したりする。

  • DTO

    総称はData Transfer Object。データを転送するオブジェクト。

データは最終的にはDB処理に利用されることが前提とされている。

MVC間でやりとりされるオブジェクトは、DTOといったほうがいいらしい

  • Entity（エンティティ）

    総称はそのままEntity。訳すなら実体。永続化可能なJavaオブジェクト。

データストレージの単位の実体。

つまり、DBのテーブル単位として扱われることが多い。

DBのテーブル単位でEntityを利用する場合、必ず主キーを所有している必要がある。

Entityの１インスタンスがDBのレコードの1行に相当する、というイメージで良いと思う。

  • VO

    総称はValueObject。

アジャイル開発宣言とかXP（エクストリームプログラミング）で有名なマーティン・ファウラー

によると「お金」や「幅」といった小さなオブジェクトを指すらしい。

オブジェクトとしての塊というより、プロパティを基準にしたクラスとのこと。

・値の設定はコンストラクタ（インスタンスの生成時）のみ

・セッターメソッドは実装しない

・値は不変とする

  • Form

    総称はそのままForm。StrutsやSpringなどで多くのクラス存在する。

起源はやっぱりStrutsだろうな。

画面の入力フォームという意味合いが強い。

Beanの中にDTO,Entity,Formが含まれ、それにアクセスするのがDAOなイメージ。

http://yyyank.blogspot.jp/2013/07/javabeansbeandtoentityvoformwhat-is.html

基準、規程、規約

基準：指針（あくまで、判断基準、目安、行動基準などのようなもの）

規定：基準をもとに手順、処理が書かれている。規約が進化したもの（規定の中で、基準を引用する）

規程：規定を具体化してより集めたもの

規約：みんなでこうしようと決めたもの

参考

社内では

規則 ⇒ 基本的規則（従業員が守らなければならないこと）

規定 ⇒ 個別規則の一般的なルール

規程 ⇒ 計算等の基準を含む具体的なルール

みたい

大辞林では以下の定義

基準

  1. 物事を比較・判断するよりどころとなる一定の標準

>

規定

  1. 物事のありさまややり方を決まった形に定めること。また，その定め。 「 －に従う」 「概念を－する」

  2. 法令の条文として定めること。また，その条文。 → 規程1

>

規程

  1. 特定の目的のために定められた一連の条項の全体をひとまとまりとして呼ぶ語。

>

規約

  1. 人々の協議によって決めた規則。 「 －に違反する」

  2. 団体の内部組織に関する規定。

括弧の使い分け

括弧には（「[『〈【の種類がある

  • ｢｣

    短い引用

論文などのタイトル

強調

ウェブ ページ内の見出し、話題、情報

ウェブ ページを一部抜粋

  • 『』

    かぎ括弧の中のかぎ括弧を使う場合

強調

書籍、映画、絵画など作品の表題、題名

ウェブ ページ タイトル

  • （）

    補足

著作物の刊行年

注記

読み仮名

文章を読みやすくしたいとき

  • ［］

    手順を説明する時

メールなどの件名

  • 【】

    見出し文囲い

すごく目立たせたいときのメールの件名

  • <>

    注意文

強調

(タグとかぶるのであまり使わない方がよいかも)

  • ""

    引用や強調をする

  • ''

    ""の中で入れ子になるセリフなどで使う。他は使わない。

Previous知識データベースNext経営

Last updated