[ThinkIT] 第4回：各データベースの運用機能の比較 (1/4)
これまでの連載でGUIツールを使用したデータベース構築を比較してきました。今回は、運用まわりに主眼をおきそれぞれの機能比較を紹介していく。 まずロックとトランザクションの分離についてだが、これはアプリケーションから見たデータの整合性を維持する機能であり、データベースにとって重要な機能である。なぜならば、複数のユーザが同時にデータを参照・更新を行った時に、変更中のデータ参照や同じデータへの同時更新を防止するからだ。 トランザクションの分離に関してはANSI/ISO SQL規格（SQL92）で規定されており、4つの分離レベルが定義されている。トランザクションは「開始宣言→データの操作→コミット命令」の流れで行うことが基本であり、コミットを行うまでデータ操作が確定しない仕組みである。トランザクションの分離レベルは、あるユーザがトランザクションを行っている途中で同じデータを別のユーザが読み出す時に
結合テストと総合テスト
ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社
[Think IT] 第1回：エンジニアだって色にこだわりたい (1/3)
Webデザイナは知っていた 第1回：エンジニアだって色にこだわりたい 著者：シンクイット制作部 公開日：2008/02/14（木） 2008年3月の連載ランキング4位（一覧を見る） Webデザイナがよくやる色の決め方 ある日、社内のプログラマの1人から突然こんな質問をされました。 「社内用のWebアプリケーションツールのフォーマットの色を見栄えよく変更したいんだけど、何色がよいか教えてくれない？16進数で」 16進数で！？ 色名ではなく具体的な数値で聞いてくるところはさすがエンジニア気質。色という同じ話題なのに職種の違いだけで面白い要求が来るものだと関心してしまいました。 今まで筆者がいた会社にはWebデザイナと営業、プログラムが少し分かる人がいるという程度でした。しかし弊社インプレスITには編集者・ライター・Webデザイナ・エンジニアが社内に揃っていて、それぞれ自分の業務に関してプロなわ
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1/4)
ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と
[ThinkIT] 第6回：単体テスト仕様書＆報告書 (3/3)
単体テスト仕様書を作成する際に、どの程度まで細かく記述するかの方針を立てる必要があります。 下記Aは、やらなければならないテストの種類と方法だけを記載し、どの項目をどのような値でテストするかという具体的な内容はテスト者に任せる方法です。一方Bは、項目ごとにどんな値を入れて、どうなればよいかを細かく記述する方法です。 例えば、「受注入力」の単体テストで必須チェック（画面の項目に値を入れない状態で更新ボタンを押した場合のエラーチェック）を行う場合を考えます。 Aの方法は"必須チェック"というテスト種類を記載するにとどめ、どの項目が必須チェック対象かまではテスト仕様書に書き出しません。 それらは詳細設計書に記載されているので、そちらを参考にしながらテストすればよいという考え方なのです。テスト仕様書の作成工数は削減できますが、テスト実施者のスキルに依存する部分が大きくなります。 一方Bの方法は、必
単体テスト仕様書＆報告書
客先からの注文書を受け、その内容を受注入力する 受注入力した内容は伝票に出力される。印刷される伝票は、注文請書と注文伝票の2枚で、注文請書は客先に提出され、注文伝票は営業事務でファイリングする 受注の際、在庫があれば在庫に、在庫がなければ発注残に引き当てる。在庫も発注残もない場合は、営業担当者に判断を仰ぎ、発注依頼にまわすことができる DUNGEONでは、このような業務要件を本連載の第1回で説明した「業務フロー」というドキュメントに記載します。全体を通した業務の流れ、部署ごとの業務の役割、業務に使う画面や帳票などの種類を業務フローに図示し、上記のような業務要件を説明欄に記載するのです。 総合テストでは、実運用に近い状態でシステムが有効に機能することを確認します。本番同様のデータを使い、要求分析で定めた業務の手順にそってシステムを使って業務をまわします。うまく運用がまわるか、不都合はないかと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第22回：メーリングリストでコミュニティに参加しよう（中-後編） (1/4)