全社会議による臨時休業のお知らせ(2024年4月19日金曜日)
平素は格別のご愛顧を賜り厚く御礼申し上げます。
誠に勝手ながら、2024年4月19日(金)は全体会議のため、臨時休業とさせていただきます。
お手数ですが4月22日(月)以降に再度ご連絡いただきますよう、お願い申し上げます。
皆様には大変ご不便をおかけしますが、何卒ご理解ご了承を賜りますようお願い申し上げます。
平素は格別のご愛顧を賜り厚く御礼申し上げます。
誠に勝手ながら、2024年4月19日(金)は全体会議のため、臨時休業とさせていただきます。
お手数ですが4月22日(月)以降に再度ご連絡いただきますよう、お願い申し上げます。
皆様には大変ご不便をおかけしますが、何卒ご理解ご了承を賜りますようお願い申し上げます。
株式会社エス・キュー・シー(本社:東京都新宿区)の代表取締役である倉田克徳が、2023 年 6 月 10 日付けで一般社団法人 IT検証産業協会副会長(所在地:東京、以下 IVIA)に就任しましたのでお知らせいたします。
IT検証産業協会: https://www.ivia.or.jp
■一般社団法人 IT検証産業協会(IT Verification Industry Association 略称 IVIA(アイビア)とは
IT検証サービスに関する関連企業、団体、個人が集い、よりよいIT検証サービスを目指して研磨し、
業界の健全なる発展を促進するとともに産業として確立させ、わが国の社会。経済の発展に寄与する
ことを目的としております。
沖縄 NICE映画祭 2022が、2023年1月27日(金)~29日(日)に、桜坂劇場 (沖縄県那覇市牧志3-6-10)で開催されます。
映画好きによる、映画好きの為の、映画好きな クセが強すぎる映画祭 爆誕 !
沖縄 NICE 映画祭は沖縄で、映画好きなメンバーが集まって出来上がった映画祭です。
これまでは、クリエイター達で創った自主映画を上映する催しでしたが、今年から一般向けの作品も募集する事にし、学生、プロ、アマ問わず誰でも応募できることになりました。
当社は、本イベントを通じ、「演じてみたい人」「脚本書いてみたい人」「映像作品をイチから創ってみたい人 」「音楽や効果音制作に興味がある人 」「イベント運営にトライしたい人」…等々、
そんなナイスな人を応援したいと考え、「沖縄 NICE映画祭 2022」に協賛しています。
詳細はこちらをご覧ください。
沖縄 NICE映画祭 公式サイト
沖縄 NICE映画祭 Instagram
沖縄 NICE映画祭 Twitter
沖縄 NICE映画祭 クラウドファウンディング
2023年3月卒向け新卒採用として、「キャリタス就活2023」に掲載を開始しました。
オンラインでの会社説明会も設定しております
キャリタス就活2023はこちらから
当社(株式会社エス・キュー・シー 代表取締役社長 倉田 克徳 )は、テレワークへの取り組みが評価され、このたび、総務省が主催する「テレワーク先駆者百選」に選定されましたことをお知らせいたします。
総務省では、平成27年度から、テレワークの導入・活用を進めている企業・団体を「テレワーク先駆者」とし、その中から十分な実績を持つ団体等を「テレワーク先駆者百選」として公表しています。
本年度は、103団体が「テレワーク先駆者百選」に選定されました。
当社は、2019年度より「働き方改革」の一環として様々な勤務形態と環境を整備して参りました。
当社は従業員とその家族をはじめとする関係者皆さまの安全と健康を最優先に、社内外の感染防止のため、コロナ禍においても、テレワークを最大限活用し、創意工夫を重ねながら事業を継続しています。
今後も「テレワーク先駆者百選」の企業として、テレワークの普及、利用促進に、積極的に 取り組んでまいります。
[関連リンク]
ITmedia(2021年11月10日)に当社代表のインタビュー記事が掲載されました。
「ソフトウェア検証”の老舗が「みんなの電子署名」を採用 ユーザーから信頼を得る電子署名サービスを使う意義」というタイトルで当社の取り組みをご紹介いただきました。
当社が利用している電子署名システムは、「日本の働き方を変える みんなの電子署名」です。
平素は格別のご高配を賜り、厚く御礼申し上げます。
当社では、新型コロナウイルス感染症拡大防止策の一環として、全従業員を対象にワクチン接種時および副反応が出た場合、
特別有給休暇を付与いたします。
1.ワクチン接種日は特別休暇を付与する。
従業員本人がワクチン接種を行う日には、特別有給休暇を付与し
2.ワクチン接種会場までの交通費は会社が負担する。
自宅からワクチン接種会場までの交通費は、会社が全額負担します。
3.ワクチン副反応が出た場合の療養期間は特別休暇を付与する。
ワクチン接種により副反応が出た場合は、特別有給休暇を付与します。
お客様ならびに関係者各位には、何卒ご理解を賜りますようお願い申し上げます。
今後も政府および関係自治体からの要請に応じるとともに、感染動向に応じた対策を実施してまいります。
平素は格別のご高配を賜り、厚く御礼申し上げます。 当社では、新型コロナウイルスによる感染症への対策として、 お客様ならびに従業員の健康と安全を第一に考え、
以下の対策を行っております。 何卒ご理解ならびにご協力を賜りますようお願い申し上げます。
1、勤務体系
2、出張およびお客様との打ち合わせ
3、ニューノーマルに対応したDX化の推進
お客様ならびに関係者各位にはご不便をおかけいたしますが、何卒ご理解を賜りますようお願い申し上げます。
今後も政府および関係自治体からの要請に応じるとともに、感染動向に応じた対策を実施してまいります。
エス・キュー・シーは、東京都が普及推進する「テレワーク東京ルール」に取り組んでおり、宣言実践企業として登録されております。
テレワークを新型コロナウイルス感染症防止のための緊急避難的な一過性のものとすることなく、促進・定着に向けて取り組んでいます。
エス・キュー・シーは、東京都が進める新しいワークスタイルや企業活動の
東京モデル「スムーズビズ」に参加しています。
テレワーク、時差出勤などに積極的に取り組み、快適な通勤環境や企業の生産性の向上を図っています。
創業25周年にあたって
弊社は、2020年9月11日をもって創業25周年を無事迎えることができました。これもひとえに多くの方々の支えがあり、
ご協力の賜と思っております。この場をお借りしまして感謝と御礼申し上げます。
今年は年初より新型コロナウィルスの影響から2020年が始まり、現在に至ってもまだ収束傾向が見えていません。
人類史上では、「天災」「戦争」「疫病」がいろいろな物事の転換点と言われており、
まさに今年は世界的にコロナ禍による諸々の転換点を迎えていると言えることが出来るでしょう。
「ニューノーマル」という新たな生活スタイルになりつつある中で、我々の本業たるシステム品質(サービス品質)も
その転換点に来ているのではないかと考えます。
今までの25年の蓄積の中から積み上げてきたノウハウ、そして、今後50年後、100年後を見据えたサービスプロバイダーとして
あるべき姿を見いだしながら、さらなる躍進につなげていきたいと考えます。
今後ともご指導、ご鞭撻をよろしくお願いいたします。
株式会社エス・キュー・シー
代表取締役 倉田 克徳
誠に勝手ながら、弊社は8月13日(木)と8月14日(金)はテレワーク デーとさせていただきます。
この期間のお問い合わせ等は、8月17日(月)以降の回答となります。
リソースリーク (英: resource leak) とは、メモリリークをファイルやネットワーク接続、OS、ハードウェアなど一般のリソースに拡張した概念である。
例えば、一般的なOS環境でファイルへの読み書きをする場合、最初にファイルを開く処理が必要であり、これはメモリでいえば確保する処理にあたる。ファイルに対する処理が終了した時には、ファイルを閉じ、該当ファイルの使用権をOSに返却する処理が必要であり、これはメモリを解放する処理にあたる。通例、ファイルを閉じることで自動的にストリームがフラッシュされ、変更内容も反映(コミット)される。このとき、ファイルを閉じる処理を忘れて、不要なファイルがいつまでも開いた状態にあれば、リソースリークが発生したことになる。ユーザーが他のプログラムでそのファイルを開こうとしても失敗したり、ファイルを削除しようとしても失敗したり、などの原因不明のエラーに悩まされることになる。ほとんどの場合、リソースリークを起こしたプログラムが終了すれば、OSによって正常な状態に復帰されるが、ファイルを閉じるための正常な処理を経ていない場合、ファイルへの変更内容が反映されないこともある。
Windowsでは標準のタスク マネージャーやProcess Explorerといったツールを使って、各プロセスが使用しているハンドルの数を監視することで、リソースリークを診断することが可能である。
C++ではデストラクタによるRAIIを活用することでリソースリークを防止できる。JavaやC#のファイナライザはフェイルセーフとしての役目しか期待できないが、Javaのtry-with-resources文や、C#のusing文といった、C++のデストラクタによるRAIIに類似した機能を活用することで、リソースリークを防止できる。
[参考:Wikipedia]
キーワード関連:メモリリーク
リバースエンジニアリング(Reverse engineeringから。直訳すれば逆行工学という意味)とは、機械を分解したり、製品の動作を観察したり、ソフトウェアの動作を解析するなどして、製品の構造を分析し、そこから製造方法や動作原理、設計図などの仕様やソースコードなどを調査することを指す。
一般的に工業製品の多くは、設計図や仕様書の概略程度しか公表されておらず、詳細な動作の原理などは公表されていない。
また、コンピュータ・プログラムのソースコードも、近年優勢なオープンソース製品では公開されており、広く検証されているものも多いが、プロプライエタリ商品の場合は一部を除き非公開のため、情報セキュリティ上の危険が(仮に)存在していても秘密扱いの場合がほとんどである。そのため、様々な技術や創意工夫が用いられているこれら工業製品についての技術的情報に関しては、公開された文献から入手できない場合が大半であり、時には危険が存在しても「秘密として法的に保護」されていることすらある(各種製造物責任法などにより対抗手段もないでもないが)。
また仮に自社開発した製品であっても、それが古い製品の場合、当時の技術者がすでに退職・死亡してしまっていたり、設計図や仕様書の所在が不明になったり、あるいはそもそも最初から作成されていなかったなどの事情により、十分な情報を得ることが不可能な場合がある。
こういった事情とも絡んで、非公開情報を入手するために、ひいては、より優れた製品の開発のためにも従来の工業製品やソフトウェア製品をリバースエンジニアリングすることによって使用されている技術を分析、調査、確認することは、現場での製品開発において欠かせないプロセスの一つともなっている。
[参考:Wikipedia]
ソフトウェア測定法(ソフトウェアそくていほう)またはソフトウェアメトリック(英: Software metric )とは、ソフトウェアやその仕様の属性の尺度である。
定量的手法の威力は他の分野で証明されていたことから、計算機科学の分野でも同様の手法をソフトウェア開発に持ち込もうとする努力が続けられてきた。Tom DeMarco は DeMarco, T. (1982) Controlling Software Projects: Management, Measurement & Estimation, Yourdon Press, New York, USA, p3 の中で「測定できないものは制御できない」と記している。
[参考:Wikipedia]
動的プログラム解析 (Dynamic Program Analysis) とは、ソフトウェア解析手法の一種であり、実際のあるいは仮想のプロセッサでプログラムを実行して解析を行うこと。動的解析を効率よく行うために、標的プログラムに十分な量のテストケースを入力し、興味深い動作を起こす。コードカバレッジ等のソフトウェアテスト技法を用いて、起こりうる動作を記述したソースコードの箇所を十分な量見つけ出すことができる。ただし、実行中の一時的な命令の効果を過小評価してしまうことに気をつける必要がある。
静的解析と動的解析は相互に補完する技術である。例えば、マルチスレッド処理にまつわるバグは静的解析では見落とすおそれがあるが、動的解析では特定することができるため、Javaアプリケーションの解析には両方の解析手法が必要である。
静的解析と動的解析を組み合わせることで、バグ検出の精度と速度が高まり、競合状態やデッドロック、リソースリークなど、実行してみないと表面化しない処理を徹底的に解析することができる。 静的解析、動的解析で発見できることは、モデル検査、証明系でより効率的に発見できることもある。これらの機能を動的解析の中に組み込んでいる場合もある。
[参考:Wikipedia]
静的コード解析 (static code analysis) または静的プログラム解析 (static program analysis)とは、コンピュータのソフトウェアの解析手法の一種であり、実行ファイルを実行することなく解析を行うこと。逆にソフトウェアを実行して行う解析を動的プログラム解析と呼ぶ。静的コード解析はソースコードに対して行われることが多く、少数ながらオブジェクトコードに対して行う場合もある。
ツールが行う静的コード解析の洗練度は、個々の文や宣言だけを検証するものから、プログラム全体を解析するものまで様々である。解析結果の利用も様々で、Lintのように単に指摘するだけのものから、形式手法を使ってそのプログラムの特性を数学的に証明する(仕様記述と振る舞いが一致しているかどうかを検証する)ものまである。
ソフトウェア測定法やリバースエンジニアリングも静的解析の一部とみなすこともある。特に組み込みシステムの開発において、ソフトウェア測定法と静的コード解析が品質向上の一助として活用されることが多くなっている。
静的解析の商業利用が増えているのは、重要なコンピュータシステムで使用されるソフトウェアの検証や潜在的なセキュリティホールを検出する必要性が増大したことを意味する。以下のような分野で、複雑さを増していくソフトウェアの品質向上に静的コード解析が使われている。
VDC Research が行った調査(2012年)によれば、組み込みシステムのソフトウェア技術者の28.7%が静的コード解析ツールを既に使っており、39.7%が2年以内に使いたいと答えた。
アプリケーションのセキュリティの分野では Static Application Security Testing (SAST) という用語が使われている。
[参考:Wikipedia]
キーワード関連:動的プログラム解析、ソフトウェア測定法、リバースエンジニアリング
ブラックボックステスト (black box test) は、プログラムの入出力だけに注目し仕様通りにプログラムが動作するか(もしくは仕様通りに動作しないか)をテストする。プログラムの入力が単一の値である場合は同値分割や限界値分析を、プログラムの入力が複数あり相互に影響を与えるような場合はディシジョンテーブルや原因結果グラフなどを用いて入力を決定する。大域変数の読み書き、通信、割り込みなどが処理中にある場合には、それらも入出力の一つとして扱う。
[参考:Wikipedia]
単体テストおよび結合テストにおける手法の一つ。トップダウンテストとは逆に、単体テストが完了した下位モジュールから順に結合させてテストを行なう。この手法の利点は、数が多く独立性の高い下位モジュールから順に検証することで、開発とテストを平行して実施できることにある。一方で、システムの根幹となる上位モジュールで不具合が発見された場合、テストが完了したはずの下位モジュールも影響を受けるという欠点も持っている。単体試験を行う場合に、他の関数等を呼び出している関数を試験する場合に、呼出のない関数を試験してから、呼出をしている試験を行う場合にボトムアップテストになっている。
[参考:Wikipedia]
キーワード関連:下降試験
OS、プログラミング言語、ネットワーク通信プロトコル、データベースなどソフトウェアを動かすための基本的なプラットフォームが、仕様に適合しているかどうかを確認する検証試験 (verification test)。OSの国際規格の一つであるPOSIXでは、 が適合試験のソースコードを公開している。 自動車用OSの国際規格OSEKでは、MODISTARC (Methods and tools for the validation of OSEK/VDX based distributed architectures) がある。 TOPPERS OSでは、TTSP (TOPPERS Test Suite Package) というテスト環境を提供し適合テスト等を実施しやすくしている。 プラットフォームの適合試験を実施せずに、アプリケーションソフトウェアの試験を実施すると、プラットフォーム仕様の変化に対応できていないことがある。
[参考:Wikipedia]
プログラムを単独ではなく、他のプログラムやハードウェア、通信ネットワーク、データベースなどと組み合わせて実施するテスト。開発環境と実行環境が異なる場合には、実際の実行環境を使って行うこともある。顧客にしか実際の実行環境がない場合には、顧客環境で行う場合がある。実際の環境を利用することが高価であったり時間がかかる場合には、模擬試験環境 (simulator) を作成して実施することがある。この場合には、模擬環境のシステム試験、実環境でのシステム試験と区分する。模擬環境では、複数の事象を同時に発生させることが難しかったり、逆に実環境ではありえない事象を発生させることができなかったり、それぞれの短所・長所を見極めて試験を実施する。エンタープライズ系と組込みソフトウェアで本質的な違いがあるわけではなく、OS、言語、ネットワーク、データベース、接続機器数の違いが大きい。
[参考:Wikipedia]
統合試験 (integration testing) は、単体試験が完了したプログラムを組み合わせて行う試験である。プログラムのどの部分から組み合わせていくかで、トップダウンテスト (top down test) とボトムアップテスト (bottom up test) に分けることができる。「Integration Testing」の略である「IT」と呼ぶことがある。また、結合テストと呼ぶ場合もある。 統合試験とシステム試験を分ける場合もある。統合試験とシステム試験を分ける場合に、模擬試験 (simulation) を統合試験に分類する場合と、システム試験に分類する場合がある。
[参考:Wikipedia]
単体試験 (unit test) は、関数、メソッドなどの小さな単位で行うテストのことである。単体テストは、関数の場合には基本はブラックボックステストである。ブラックボックステストが済んだものの品質を確保するためにホワイトボックステストを行う。「Unit Testing」の略である「UT」と呼ぶことがある。また、開発現場によっては「CT(和製: Coding Test)」や「PT(和製: Program Test)」と略すこともある。
単体試験の道具としてJavaではテスティングフレームワークJUnitが有名である。これはJava専用である。他の言語にも同様のものがあり、それらを総称してxUnitと呼んでいる。
[参考:Wikipedia]
性能試験は、ソフトウェアシステムの性能を測り、必要な性能が出ることを確かめる試験である。入力をどれだけ受付けるか、どれだけの出力が可能か。通信経路数・通信速度、処理件数などプログラム単体では問題が発生しなくても、通信、データベース、入出力 (I/O)、同時に起動するソフトウェアなどの高負荷、長時間使用などの条件下では性能が低下することがある。性能を確認する試験は、システムの性能に影響を与えないように測定する必要があるため、OSやミドルウェアなどでは性能を測定する効率的な計測方法を提供していることもある。 性能試験は、単体試験から実施する場合と統合試験から実施する場合とがある。 過負荷に対する性能試験をストレステストという。
[参考:Wikipedia]
ソフトウェアプロジェクトの各工程において作成される成果物について、権限者や専門家が管理面ないし技術面から審査・評価・決裁・見直し・問題指摘などを行うこと。
ソフトウェアに関する主なレビューには、承認レビューと成果物レビューの2つがある。前者は契約やマネジメントで規定された正式な認証行為としてのレビューであり、後者はソフトウェア成果物に潜む問題の早期発見を図る品質活動としてのレビューである。このほかに作業状況を評価するレビュー、プロセス品質を評価するレビュー、採用技術の評価を行うレビュー、未経験者の教育を目的としたレビューなどがある。
[参考:ITmedia]
最も公式なソフトウェアレビュー。ソフトウェア中の問題を検出するために、事前に定められた観点で第三者が厳密にレビュー対象を点検して欠陥の指摘と認定を行い、その結果に基づいて対象の修正と開発プロセスの評価・改善を行う。
インスペクションは、事前に定められた手順とチェックリストに従って第三者がレビューを行う、最も形式的なレビュー手法である。レビュー対象にはソースコードのほかにプロジェクト計画・要求定義・基本設計・詳細設計の各フェイズにおける各種成果物が含まれ、上流工程から実施可能な欠陥未然防止技法になっている。
[参考:ITmedia]
キーワード関連:ソフトウェアレビュー
「キーワード駆動スクリプト」では、スクリプトの部品化、スクリプトとデータの分離を行った上で、さらにそれらの部品を、自然言語に近い「キーワード」として抽象化します。ドメインエキスパートやテストエンジニアは、それらのキーワードを使うことで、スクリプトの内部構造を意識せずに自動テストケースを記述できるようになります。
[参考:システムテスト自動化 標準ガイド]
共有スクリプトでは一連の操作を分割することでスクリプトを部品化したのに対し、「データ駆動スクリプト」ではスクリプトとデータを分離します。これによって、「手順は同じだが、入力する値は異なる」テストケースを、1つのスクリプトと複数のデータのセットで実現することができます。
[参考:システムテスト自動化 標準ガイド]
「共有スクリプト」のアプローチでは、テストケース間で重複して現れるスクリプトを部品として切り出し、それらを複数のテストケースから呼び出すことで、テストスクリプトの保守性や可読性をさらに向上させることができます。また、部品同士を組み合わせた新しいテストケースを組み立てることもできるので、リニアスクリプトが抱えていた「線形」の問題から逃れられることになります。
[参考:システムテスト自動化 標準ガイド]
「構造化スクリプティング」では、分岐・反復といった、プログラミングの基本的な構造を使ってスクリプトを表現することで、スクリプトの保守性・可読性を向上させることができます。
ニアスクリプトや構造化スクリプティングのアプローチでは、複数のテストケースに共通の操作(たとえばログイン/ログアウト、特定の画面への遷移など)に対応するスクリプトがテストケースごとに現れるため、操作に変更が発生した場合、そのすべてを修正する必要があります。
[参考:システムテスト自動化 標準ガイド]
キーワード関連:ニアスクリプト
「リニアスクリプト」は、キャプチャーリプレイツールで操作を記録することで自動生成されたスクリプトを、ほとんどそのまま使うものです。1つのテストケースが1つのテストスクリプトに対応するため、テストケースの数が10倍になればスクリプトの数も10倍と、「線形に(リニアに)」増加してしまいます。
[参考:システムテスト自動化 標準ガイド]
テストを自動実行するためのスクリプティングの「技法」として、5つのアプローチがあります。
①リニアスクリプト
②構造化スクリプティング
③共有スクリプト
④ データ駆動スクリプト
⑤キーワード駆動スクリプト
[参考:システムテスト自動化 標準ガイド]
キーワード関連:リニアスクリプト、構造化スクリプティング、共有スクリプト、データ駆動スクリプト、キーワード駆動スクリプト
キーワド駆動テストは、テストの自動化を行うときや、自動化のフレームワークの開発のときに用いられることの多い方法論です。
しかし、キーワード駆動テスト自体は自動化ためにだけ意味のあることではなく、自動化されていない、または自動化の予定がない場合でも有効な手段となります。
キーワード駆動テストはテスト用フレームワークで、ファンクションテスト用スクリプトの開発と、テストケースまたはワークフローの作成とを別々に行う事ができます。テストする特別なファンクションを表すキーワードやアクションワードを使用します。それらは各キーワード(データ)用の引数と一緒に外部データ表内にあります。
このプロセスはデータ駆動テストと似ていますが、純粋にデータだけを入力するのではなく、キーワードと関連するデータを一緒にテスト実行ドライバに入力します。
ISO/IEC/IEEE 29119は、「ソフトウェアテストの国際規格」です。
・本規格で提示されているテストの考え方(プロセス、文書、テスト技法)は、国際的に通用するものである
・あらゆるソフトウェア組織に適用可能である
・あらゆるソフトウェア開発に適用可能である
テスト駆動開発で記述されるテストケースは、作成したプログラムの動作が正しいかどうかを検証するために行う「テスト」である。テストであるという点は同一であるが、加えて、これから作成しようとするプログラムに期待される「振る舞い」や「制約条件」、つまり「要求仕様」に近い形で、自然言語を併記しながらテストコードを記述する。テストフレームワークのメソッド名も自然言語(英語など)に近い形をとっている。
テストコードの可読性があがる上、テストコードが要求仕様となりうる。要求仕様からテストコードを起こす際も、スムーズにコードに移行しやすい。
BDDではスペック(仕様)とテストは限りなく近い物である。従って、テスト駆動開発における「テストファースト」は、BDDにおいては「スペックファースト」となり、スペックを作ってから実装するという、より自然な形でのプログラム製作を実現している。
いくつかのテストフレームワークは、
の2種類を含む。
[参考:Wikipedia]
エクストリーム・プログラミング、XP(英: extreme programming)は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。1999年に書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』によって発表された。
XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。この変更コストが増大しないという前提が破綻すると、この手法も破綻する。
XPは比較的少人数の開発にもっとも適用しやすく、5つの価値と19の具体的なプラクティス(実践)が定義されている。XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。
[参考:Wikipedia]
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している
[参考:Wikipedia]
B-Methodとは、AMN(Abstract Machine Notation)という仕様記述言語(兼プログラミング言語)を中心とした形式手法に基づいたソフトウェア開発手法である。B-Method で使用する形式手法やそのツール群は単に B と呼ぶ。
Jean-Raymond Abrial を中心としてフランスおよびイギリスで開発された。Abrial の開発したZ言語とも関連しており、仕様からのプログラミング言語コード作成をサポートしている。ヨーロッパでは、大規模なインフラシステムで利用されており(パリのメトロ14号線など)、産業界の注目を集めつつある。堅牢で商業利用可能なツールが提供されており、仕様記述、設計、検証、ソースコード生成が可能である。
Z言語に比較して抽象化レベルが低く、単なる形式仕様記述というよりもコードへの詳細化に重きを置いている。そのため、B で書かれた仕様はZ言語の場合よりも実装が容易である。特にそのために様々なツール群が用意されている。
[参考:Wikipedia]
テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き(これをテストファーストと言う)、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。
[参考:Wikipedia]
キーワード関連:アジャイルソフトウェア開発、エクストリーム・プログラミング、ビヘイビア駆動開発
ISO/IEC 15504 は,世の中に存在するプロセス診断のモデルや方法についての枠組み(フレームワーク)であって特定のモデルだけに適用できる標準規格ではない。その主題は組織の運営能力と作業(プロセス)定義構造に基づいた診断(アセスメント)である。ISO/IEC 15504は 、完結した方法論を網羅せず,いろいろな方法論の共通部分だけを規定している。例示としてのモデルの一つ第5部(Part5)は、ソフトウェア事業(プロジェクト)で発生しうる活動の枠組みであるソフトウェアライフサイクルプロセス(ISO/IEC 12207: JIS X 0160)に対して、やっていてよかった指標(プラクティス)を示している。第6部(Part6)は、システムライフサイクルプロセス(ISO/IEC 15288: JIS X 0170)に対するモデルである。モデルに記載していることはやっていてよかったという過去の知見である。実施すべきものとしているわけではない。作業生産物(work product)も例である。紙であることを明示しているものは少ない。ISO/IEC 15504 は診断員(assessor)が対象の入力と出力に関して診断の前から分かっていること、面談の結果や証拠を分類し、作業の能力を判定する。診断のやり方は調達を目的として外部から観察する方法と、改善を目的として内部で作業をしている人が判断する方法がある。
[参考:Wikipedia]
ISO/IEC 12207 (Systems and software engineering — Software life cycle processes) とは、ソフトウェアのライフサイクル全般についての標準である。国際標準化機構 (ISO) と国際電気標準会議 (IEC) の合同技術委員会 (JTC 1) が1995年に策定した。ソフトウェアの開発や保守に関わる活動全般の標準を定義することを目的としている。翻訳が、日本工業規格 JIS X 0160(ソフトウェアライフサイクルプロセス)になっている。
ISO/IEC 12207 ではソフトウェアのライフサイクルを定義しており、システム上のサービスの入手や構成に関わる活動やプロセスも含まれる。各プロセスには必ずその出力となるものが定義されている。実際には 23種類のプロセス、95種類の活動、325種類のタスク、224種類の出力(成果物)が定義されている。
この標準の主な目的は、ソフトウェアの開発や保守に関わる様々なステークホルダー(購入者、提供者、開発者、保守者、操作者、管理者、技術者)に共通の構造を提供し、相互のコミュニケーションを円滑にすることである。そのような共通の言語はうまく定義されたプロセスで確立される。標準自体の構造は柔軟でモジュール性があり、必要な人が必要な部分だけを採用することができるようになっている。この標準の2つの基本原則は、モジュール性と信頼性である。モジュール性とは、定義されたプロセス間の結合度が最小で凝集度が最大となっていることを意味する。信頼性とは、各プロセスの信頼性を確立し、標準を応用したプロジェクトに多くの人々が法的に参加できるものにすることである。
プロセス、活動、タスクはソフトウェアプロジェクトに適用可能である。プロセスは3種類に分類されている。
基本プロセス
購入プロセス(発注プロセス)、提供プロセス、開発プロセス、運用プロセス、保守プロセス
サポートプロセス
文書化プロセス、構成プロセス、品質保証プロセス、検証プロセス、評価プロセス、ジョイントレビュープロセス、報告プロセス、問題解決プロセス
組織プロセス
管理プロセス、基盤プロセス、改善プロセス、訓練プロセス
[参考:Wikipedia]