JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference 20142014年2月28日に開催された「Enterprise ☓ HTML5 Web Application Conference 2014」での講演「JavaエンタープライズアーキテクチャにおけるHTML5」の資料ですRead less
JBehave+Maven+Eclipseを使った結合試験の自動化 - Qiita
JBehave+Maven+Eclipseを使った結合試験の自動化 What is JBehave? JBehave is a framework for Behaviour-Driven Development(BDD). http://jbehave.org/より BDDをするためのフレームワークです。 試験シナリオをプレインテキストで記述し、それを処理するテストを記述することで試験をしていきます。試験シナリオをテキストで記述できるため、いわゆるお客様にシナリオを確認してもらいやすくなります。（お客様に書いてもらうこともできそうですが、ちょっと厳しいかと思います） 具体例 先日作ったjalo(https://github.com/tamurashingo/jalo)に結合試験を追加してみます。 ソースコードはhttps://github.com/tamurashingo/jalo/tr
富士通、30年の経験に基づく要件定義手法を「Tri-shaping」に体系化 | エンタープライズ | マイコミジャーナル
富士通は、業務プロセスの分析・改善提案とICTシステムの構築における要件定義手法を「Tri-shaping」として体系化し、発表した。4月からは、同社が手掛ける売上3億円以上のプロジェクトには原則適用するほか、2011年度上期より、富士通グループ向けに研修を実施する。また、2011年度下期からは、顧客向けに有償の研修サービスとして提供する予定。 今後の展開 富士通 システム生産技術本部 本部長 柴田徹氏 富士通 システム生産技術本部 本部長 柴田徹氏は、「お客様には、経営視点で業務プロセスを変えられる人がいない、業務視点でICTシステムを変えられる人がいないという問題がある。そこで弊社は、人に頼らないシステムによって改革力を上げるため、本製品をリリースした」と、今回、要件定義を体系化した背景を語った。 同社では2007年から上流工程の品質向上や形式品質の向上に、2009年からは内容品質の向
「AS-ISシステム分析は入出力から始めよ」講演メモ - mkoszk’s blog
テープ起こしをしていませんので、間違っているところもあると思いますし、補った言葉が間違っているかもしれません。また、編集の過程で順序が変わってしまったところもあると思います。 この講演は聴いて良かったと思っています。神崎さんのやり方と僕のやり方は非常に似ているのですが、徹底度合いが違うといいますか、僕が今まで気づかなかったことをたくさん教わりました。 ─────────────────────────────────────── 要求開発アライアンス2月定例会 テーマ：AS-ISシステム分析攻略法。トップダウンとボトムアップで挟み撃ち！ 日時：2011年02月22日(19:00~21:00) 場所：日本総合システム株式会社様 大会議室 ─────────────────────────────────────── ■19:00-20:00 AS-ISシステム分析は入出力から始めよ 講師：株
S-Okada Business-modeling Office 1 ○○○○システム 要件定義書 （仕様書の抜粋版サンプル） ２００Ｘ年Ｘ月 ＫＫＫＫ株式会社 S-Okada Business-modeling Office 2 ＜目次＞ はじめに（本書の位置づけ）.....
S-Okada Business-modeling Office 1 ○○○○システム 要件定義書 （仕様書の抜粋版サンプル） ２００Ｘ年Ｘ月 ＫＫＫＫ株式会社 S-Okada Business-modeling Office 2 ＜目次＞ はじめに（本書の位置づけ）...................................................... 3 １．システム化の方針............................................................ 4 １．１ 当社の経営戦略について ....................................................4 １．２ 今回のシステム化のねらい ................................................
スマホサイト案件の見積もりについて
スマホサイト案件の見積もりについて 「Android案件の見積り」や「スマホ案件の見積もりについて」を受けて、アプリではなくHTML+CSSでつくるスマホサイト制作の見積もりではまりやすいポイントをまとめています。 HTML+CSS構築ではPCの0.７倍くらいの単価 スマホサイトはPCより小さいのでHTML+CSSの構築コストも安くみます。ただ、CSS3で作ったほうが良いところで画象の切り出しより手間がかかることもあります。ならすとページ単価はPCの0.７倍くらいの感じじゃないでしょうか？ 検証コストは増大 対応端末が多く検証コストはPCと比較して増大します。iPhone3G、iPhone3GS、iPhone4、iPhone4Sの中から2端末ぐらい(iOS4.x系とiOS5系)。Android2.2、Android2.3から売れてる端末で2端末ぐらい検証するのがよいでしょう。(場合によって
仕様の導出を目的としたUSDMの要求の導き方 - mkoszk’s blog
清水吉男さんの「要求を仕様化する技術 表現する技術」（以下、USDM本）には、次のように書かれています。 要求の扱う範囲が広すぎると仕様の抽出が拡散して漏れてしまいます。（p.196） 言いたいことは何となく分かるのですが、僕はこの「範囲が広い」という感覚がどうにもなくて、ずっともやもやしていました。でも、あるとき、内包と外延の話と似ていることに気づきました。内包を規定する条件を少なくすると、外延としての対象が増えます。内包を規定する条件を多くすると、外延としての対象が減ります。この説明が清水さんが解説している要求と仕様の関係に似ていると感じたのです。あまりにも要求がシンプルだと、自由度が高くなりすぎて仕様が爆発してしまう。要求に条件や制約を付け加えることにより、仕様の抽出に適切な範囲にしているということに、やっと気づいたのです。 でも、どうやって条件や制約を考えればよいのか分かっていませ
要件定義ツールを使った既存システムの分析
前回はUMLを使ってシステムの地図をかく方法を説明しました。今回はUMLを使わずにより簡単に分析する方法を説明します。システムの入出力とデータをつなぐ分析手法は、要件定義でも使われる手法なので同じ要領で既存システムを分析することができます。今回ご紹介するのは要件定義ツールを使う方法です。柔軟性には欠けますが、要件定義が初めての方でも簡単に短時間でまとめることができます。 短期間に分析する 今回ご紹介する方法は画面数が100程度の中小規模なシステムを対象としています。システム関係者へのヒアリングが行える環境があり、材料（入出力情報とデータ）が揃っている場合は、手法とツールを使うことで、短時間でシステムの地図を作成できます。 今回は要件定義ツール「要件のツボ」を使った方式を説明します。今回もプログラムそのものを調査するのではなく、システムの入出力を調べ、その使われ方を調べる方法です。「要件のツ
要件定義書サンプルPDF
159 別紙 7 次期 PARTNER システム要件定義書 平成２３年１０月 独立行政法人 国際協力機構 160 目 次 1. 本書の位置付け..................................................................................................................................................................................163 2. システムの要件........................................................................................................................................
システム開発 - 要件定義 -
要件定義の目的 要件定義とは、以下の点を整理し、矛盾がない事を確認し、利用者とシステム開発者が同じ認識を持つ事です。 ①．システム化の目的 ②．対象業務 ③．人、物、時間、場所を明記した業務の流れ ④．機能毎の要件 ⑤．業務が分岐する場合の条件 ⑥．利用制限 ⑦．外部設計のインプットとなるだけの項目の定義 ⑧．シナリオテスト作成のインプット (2011.07.16追記) (2011.03.06) 要件定義書の有効期間 要件定義書の有効期間について、様々な考え方があると思いますが、私はシステムが存在している期間は有効であるべきと考えます。 それは、要件定義書のコンテンツが要件定義書にしかないからです。外部設計書、内部設計書を作成してしまえば、システムが完成してしまえば 必要ないものではありません。外部設計書を作成中に機能数が変更になる場合でも、システムが稼働してからでも、要件定義書のコンテン
「Web制作のリアルな工数と見積もりの話」の話をしようじゃないか！
raf00がWEB制作の見積もりについて書きたいなぁとか言いながら1年半が経ちました。 で、いずれ書かなきゃなーと思いながら過ごしていたら、WP-Dさんが非常に興味深いエントリを上げられていましたので、これに便乗する形であれこれ書きちらしてみたいと思います。 WordPressのリアルな工数と見積もりの話をしようじゃないか！ | WP-D ウェブ制作の見積もりを金額付きで晒してやろうじゃないか！ | WP-D ■あの見積もりは妥当か否か なかなかブコメなどの反応が興味深い見積もりサンプルですが、現在の（上場企業の制作業務に対応できるくらいには）真っ当なWEB制作会社が企業向けに出す見積もりとしては項目・工数・価格的には概ね妥当かつ適切だなと感じられます。サンプルであるがためにこまごまとボヤけた点はあるものの、WEB制作会社のプロデューサー・ディレクターやクライアント企業のWEB担当者ならば
モデルベース要件定義 at BPStudy
・システムの全体像をつかむためにモデルを使ってシステムの地図を作ろう ・ビジネスモデルキャンバスからシステム化するRead less
ソフトウェア開発と設計書の関係 - 勘と経験と読経
Info-Qの記事「アジャイルにおけるドキュメント：いつどれくらい書くべきか」を読みながら考えたこと。ソフトウェア開発と設計書の関係については、本ブログでも何回か取り上げている。 開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経 保守開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経 アジャイルソフトウェア開発マニフェストは「包括的なドキュメントよりも動くソフトウェア」に価値を置いている。そうだとすると、どんな種類のドキュメントが、いつどれだけ必要なのだろうか？ アジャイルにおけるドキュメント：いつどれくらい書くべきか 発掘的な設計と、創発的な設計 ドキュメントを作るべきかどうかは、ソフトウェア開発プロセスがアジャイルかどうかとは無関係だと考えている。開発対象となるソフトウェアの設計が「発掘的」に行われるのか、「創発的」に行われるのかでドキュメント化の戦略が変わってく
継続的システムテスト - Test Automation
JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。 【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 from Kotaro Ogino ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。 背景：開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
Backbone.jsに入門してみる【Router編】 - yutaponのブログ
久しぶりのBackbone.js入門。 Backbone.jsガイドブックを見ながらまとめてますが、 後半は試行錯誤のたまもの。 Backbone.Routerとは Backbone.RouterはサーバーサイドMVCフレームワークでいうところのCにあたる部分、でもありますし、VCでもあります。 Backbone.ViewがDOMを監視するのに対して、Backbone.Routerはブラウザのハッシュ（URL欄）を監視します（厳密に言うとhashChangeイベントとpopStateイベントを監視）。 Backbone.Routerにハッシュとそれに対応する操作を設定しておくことで、 アプリケーション全体のコントローラみたいなふるまいをします。 Backbone.Routerの使い方 何はともあれサンプルコードを。 // @file router_sample.js var Router
xddp.jp - このウェブサイトは販売用です！ - 派生開発 プロセス改善 ソフトウェア ソフトウェア開発 セミナー リソースおよび情報
このウェブサイトは販売用です！ xddp.jp は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、xddp.jpが全てとなります。あなたがお探しの内容が見つかることを願っています！
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
業務アプリケーションにおけるモダンWeb開発の現状ーHTML5開発って簡単なの？