IBM Lotus User Interface Developer Documentation - Home
This documentation was created as part of a Lotus® initiative to remove arbitrary differences in our product user interfaces. It describes the CSS and HTML markup structure used in many Lotus® products. Use the information in this documentation to help you customize Lotus® products for deployment in your enterprise or to help you build componentry that seamlessly integrates with Lotus® products. Q
第35回 画面設計書はどう作られるべきか
Webサイトを構築する場合，通常は「設計書」を作成します。サイト全体の設計書であったり，ページ単体の設計書であったりするわけですが，今回は後者である「画面設計書」について考えてみましょう。 画面設計書を読むのは誰か Webサイトの構築では，対象ユーザーをできる限り具体的に決めてから開発を進めていきます。同様に，画面設計書にも「対象読者」を見定める必要があります。結論から言えば，かなり属性の異なる二種類の読者が存在します。 まず，発注者である「クライアント」です。クライアントは，技術的な難易度ではなく，自分たちのビジネス要件を満たすものが作られるかどうかを確認するために画面設計書を読みます。開発（プロジェクト）のゴールや，プロジェクトのメリット/デメリット，リリース後の顧客満足の予想などを，その設計書から読み取ろうとします。したがって，できる限り具体的なイメージが伝わるものが要求されます。
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - お役立ちグッズ
「出来上がった作品（モデル）」を見れば、 「作り方（設計手法）」や「道具（モデリングツール）」の有効性がわかります モデリング支援ツール ＸＥＡＤ 企業システム向け設計方法論「三要素分析法」が提唱する上流工程成果物は、データベース設計の元ネタとなるデータモデル、業務マニュアルの元ネタとなる業務モデル、プログラム設計書の元ネタとなる機能モデルの３点です。 しかし、これらのモデルを、表計算ソフトやワープロソフトで管理するのはやっかいです。情報が複雑で膨大であるだけでなく、相互に関連しあっているために整合性や妥当性を検証しにくいためです。 この目的のために特別にデザインされたモデリングツール、それがＸＥＡＤ[zi:d]です。これを使えば、各定義要素の全体的な位置づけや要素間の関係をビジュアルに確認しながら、効率的に設計情報をまとめてゆけます。 ＣＯＮＣＥＰＴＷＡＲＥ（コンセプトウエア
Software Process
ソフトウェア・プロセスの世界 ソフトウェア・プロセス=ブック・ガイド PSP(パーソナル・ソフトウェア・プロセス)の概要 TSP(チーム・ソフトウェア・プロセス)の概要 dX(XPの皮をかぶったUnified ProcessあるいはUPの皮をかぶったXP)の概要 eXtreme Programmingの概要 リファクタリングの概要 ソフトウェア・プロセス=スタンダード Software Process Engineering Metamodel(OMG)のあらまし SPEMとはOMGで定義された、ソフトウェア･プロセスそのものを表現するための枠組みです。MOF(Meta-Object Facility)あるいはUML Profileの形で定義されています。今後のCASEツールで使われていくようになると思われます。 OMGによるSPEMの定義自体はこちら ソフトウェア・プロジェクト管理計画書
要求仕様書の規約IEEE830で、困る点（その１） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日のブログで書いた、要求仕様書の規約IEEE830だが、実際の仕様書に起こそうとすると、こまることがある。ざっと考えて以下の３点 １．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない ２．機能の定義の仕方が、オブジェクト指向などと合わない可能性がある →オブジェクト指向では、このフォーマットだと書きにくい ちょっと、かえればいいだけなんだけどね。 ３．外部設計の規約IEEE 1016と、あわせてつかうと、へなちょこになる →つーか、IEEE1016が、へなちょこ！ で、今回は、「１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない」について。 で、この話をする前提として、IEEE830の内容は、このページを参考にしています。 １．
要求仕様（要求工学：第3回）
概 要 今回はIEEE830[１]に基づいてソフトウェアに関する要求仕様の標準的な構成例を紹介しよう。立命館大学の大西教授と山梨大学の郷助教授による「要求工学」[２]の第４章でもIEEE830が解説されている。 IEEE830では表1に示すように要求仕様を、目次、はじめに、要求仕様の一般的な説明、要求仕様の具体的な説明、付録、索引から、構成することを推奨している。 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求仕様をSyRSと略記する[３]。本稿ではSRSについて解説する。 表1 IEEE 830 による要求仕様の構成 SRS 第1章「はじめに」 「はじめに」ではSRS
IEEE830-1998 — MetaMetaWeb
Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Definitions, acronyms, and abbreviations (定義、略語、短縮形) この小節では、このSRSを解釈するのに必要となるすべての用語、略語、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
【楽天市場】エラー
http://www.xart.co.jp/07netbusiness/chishiki_b019.htm