機能要件は、ソフトウェアやシステム開発において必要となる大切な工程です。制作するシステムに盛り込みたい機能をクライアントから適切に聞き出し、どのような機能が必要なのかを明確に定義します。また、機能要件と反する言葉に、「非機能要件」があります。 非機能要件は、クライアントから提示された機能ではなく、レスポンススピードやセキュリティといった機能要件以外の要件を指します。今回は、システム開発・制作工程において重要な機能要件と非機能要件についてご紹介します。 目次 機能要件と非機能要件の違い 機能要件は、「ソフトウェアやシステム開発において、クライアントから求められる『機能』のこと」です。一方、非機能要件とは『機能以外』のユーザービリティ、性能、拡張性、セキュリティなどの品質的に関連するもの全般を指します。 ソフトウェアやシステムなどにおいて、クライアントからの要望としてある『機能』を満たすことは

アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報

これから書く項目がテスト計画時に定義されていなかった(検討されていなかった)ために、炎上してしまったプロジェクトをよく見かけました。 「何で定義しなかったの？」と担当PLに聞きましたが、「定義が必要だと思っていなかった。。」といった答えが返ってきたので、意外と重要だと気付かれていない項目もあるかもしれない。と思い、まとめてみることにしました。 ※以下結合テスト、システムテストの機能テストフェーズのテスト計画書に記載することを前提にしています。 1.テストの種類と目的 大体のテスト計画書には「どのようなテストをするか」は記載されているのですが、「何を目的としたテストなのか」を明記していないテスト計画書をたまに見かけます。 大切なのは、目的を明確化し、ステークホルダー間で「今回のテストは大体このような内容のテストをするのだな」という認識をあわせる事です。 2.参考資料 今回のテスト計画を立てる

運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

ソフトウェアの欠陥は、リリース後に大きな損失として返ってくる場合があります。 そのため、ソフトウェア開発において、テストはとても重要な役割を担っています。 そこで今回は、ソフトウェア開発でのテストがどのようにおこなわれているのかを解説します。 ■テスト計画の立て方 ソフトウェアの開発者の中には、テストは開発者が同時並行でおこなえば良いと考えている人がいます。 しかし、テストは製品の最後の砦、いわばゴールキーパーのような存在です。 テストには以下のようなプロセスがあります。 ①テスト計画を立てる ②テストの分析と設計 ③テストの実装と実行 ④テストの終了基準と評価 ⑤テストの報告 まずは「テスト計画を立てる」について解説していきます。テスト計画を立てるためには、まずテストの目的を定める必要があります。 この場合の目的は、ソフトウェア自体の目的や、プロジェクトのスケジュール、テストにかけられる

実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす

こんにちは KOBA789 です。前回に引き続き Capy のパズルタイプを突破するお話です。 Capy がより堅牢な CAPTCHA ソリューションにためには突破するためのアルゴリズムを公開することが重要だと考え、解説をするに至りました。 ちなみに今回紹介するアルゴリズムは前回の記事とはまったく別物です。今日の夕方頃、Capy に仕様変更があり、背景画像のバリエーションが増えたようです。前回紹介したアルゴリズムはそのような仕様変更でほぼ無効化されると思われます。しかし、今回紹介するアルゴリズムはそのような変更の影響を原理的に受けません。影響を受けない理由も考えて解説をお読みいただければと思います。 Capy とは 前回の記事では執筆時間の関係で端折ったのですが、今回は少しまともに解説をしておきましょう。 公式サイトより引用します。 Capyが提供する国際特許出願済のソリューションは、“セ

例えば同じリンゴの絵を描いても、幼児のそれと高名な画家の絵はまったく違う。システム開発も、最初に具体的なイメージを固めておくことが重要だ。できればこうした話題は、コーヒータイムや酒の肴の話題とした方が良い結果が生み出せる。 最初にイメージを描くことの重要性 5歳の幼児が描いたリンゴの絵も、印象派のセザンヌが描いたリンゴの絵も、ともにリンゴの絵には違いない。着手のハードルは低いが、人による結果の出来映えに大きな違いがあることはソフトウェアの特徴である。 情報システムというソフトウェアについてもこの特性が当てはまる。ある程度の規模のシステムまでなら、頼む方は丸投げ、受ける方はプログラムの細かい部分からダラダラ書き始めるようなやり方でも作業を進めることができてしまう。 客観的に見れば、使い物にならず、いつどんなものに出来上がるのか分からないような代物でも、やっている当人たちにとっては“リンゴ”以

日本のDDD（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。 本書をおすすめしたい人 本書は、システム開発で以下のような問題を抱えている人におすすめです。 既存システムのソースコードの可読性が低く、理解に時間がかかる 機能追加・改修時の影響範囲調査に時間がかかる 機能追加・改修時の工数が予想以上にかかる テストコードが書きにくいソースコードになりがち 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる デグレの確認に気を使い、多くの時間をかけている 不具合が発生したときに、調査・解決に時間がかかってしまう 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる これらの問題のために、生み出す価値以上に、仕事時間が増えている このような問題を解消し、変更に強い

konashi 開発者の松村礼央さんと iOS エンジニアの堤（私）の共著で、「iOS × BLE　Core Bluetooth プログラミング」という書籍を執筆させていただきました。 iOS×BLE Core Bluetoothプログラミング タイトルの通り、BLEを利用したiOSアプリ開発の解説書です。 480ページと、技術書としてもかなりのボリュームとなっております。 書籍の概要と著者の紹介 大きく分けて２つのパートにわかれています。 Part1. BLE編 最初のパート、第1章から第3章は、konashiの開発者である松村礼央さんによる執筆で、BLEという通信規格そのものについての解説 となっています。 松村礼央 博士（工学）。karakuri products代表。東京大学先端研特任研究員。在学中は人型ロボットの開発・製造に従事、代表作は「robovie-mR2」。2012年にB

AWSでサーバーを立てる サーバー関連の知識ゼロの人(僕)が、AWSによるサーバー構築までそれぞれの過程を理解しながら一通りやってみましたので、備忘録的にまとめ。ツールとしてとても便利なだけでなく、ネットワークの仕組みを学ぶ上で非常に勉強になりました。AWS様様m()m。清書・肉付けしてないけど、WIPで公開します。追記予定。 こんな人にオススメ 普段アプリ開発してるけど、自分でサーバーたて方よく知らない。ので、知りたい。 サーバーなんとなくたてたことがあるけど、ネットワークの仕組みとか工程の意味がわかってない。ので、理解したい。 内容 A. ネットワーク構築 B. サーバー構築 C. Webサーバーソフトインストール D. DBインストール E. Railsインストール F. 知っておくと良い周辺知識たち という構成でサーバー構築まで説明します。僕が普段Railsでアプリ書いてるので、R

意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

プロビジョニングとは、必要に応じてネットワークやコンピュータの設備などのリソースを提供できるよう予測し、準備しておくことです。供給や設備等の意味を表すプロビジョン（provision）という単語がもととなって派生した言葉です。 分散システムや記憶装置等のリソースを仮想化技術によって一つのリソースとみなし、必要な時に必要な分だけオンデマンドでリソースを割り当てます。 プロビジョニングの種類としては、サーバープロビジョニング、サービスプロビジョニング、ユーザープロビジョニングがあります。 従来、プロビジョニングという言葉は通信の分野で用いられており、ネットワークを迅速に提供するため、顧客の需要を予測して設備を事前に準備することを意味していましたが、最近ではネットワークの分野だけでなく、様々なIT分野でも使われるようになりました。 例えば、プロビジョングプロファイル、プロビジョニングファイル、プ

最近，環境ごとのデータベーススキーマの差分をチェックする機会があった．プロダクション環境とステージング環境ならまだしも，開発環境だと検証のために追加したインデックスがそのままになっていたり，開発が途中で止まってしまって日の目を見ることがなかったテーブルが残っていたり，そういうことって比較的あるのではないかなと思う．特に今の環境だと，マイグレーションの仕組みが整っていないという課題もあり，より一層，データベーススキーマに差分が出やすくなってしまっている． 今回は MySQL から公式に提供されている mysqldiff というツールを使ってデータベーススキーマの差分をチェックした． mysqldiff をインストールする mysqldiff は MySQL Utilities という MySQL の管理ツールパッケージの中に同梱されている．現在だと v1.6 が最新になっている． MySQL