12. 役割分担 Product Manager Product Manager Project Manager Project Manager Design Quality Budget/Cost Architecture Deadline/Progress Scope Sprint Planning マンガプロダクションと担当編集の関係に着想
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔のメモを整理してると出てきました。今となっては心底どうでもいい。 上流工程に関するあれこれ 大まかな流れ 基本的な流れとしては要件定義→外部設計→内部設計→開発の流れが採用される。 ここで外部設計は基本設計、内部設計は詳細設計とも呼ばれる。 一般にウォーターフォールモデルでの考え方では外部設計までが上流工程と考えられるようだ。 ##要件定義 ###要求開発(超上流工程) [ 業務フロー ] 業務とその流れを表現するもの。素人にもわかるように → アクティビティ図 業務機能関連図 [ 業務モデル ] 業務を静的に表現する。 → ERD
本ページでは2018.12.08に開催されました掲題のコミュニティ旗艦イベントについて、 主にアンケート結果をまとめます。 多くのみなさまのお申込みとご来場、誠にありがとうございました。 2018/12/08 (土)にテスト自動化研究会(以下、STAR)は、6回目となるシステムテストの自動化に特化したカンファレンスを開催しました。今回はコンテンツを公募し、多くの方からの応募いただき、皆さんのテスト自動化の工夫や試行錯誤の様子、将来の展望をお話頂きました。
27. DroidKaigi 2015/04/25 @cattaka_net SharedPreferencesの差し替え プロダクションコード public class SharedPreferencesFactory { static SharedPreferencesFactory INSTANCE = new SharedPreferencesFactory(); public static SharedPreferencesFactory getInstance() { return INSTANCE; } public SharedPreferences newInstance(Context context, String name) { return context.getSharedPreferences(name, Context.MODE_PRIVATE); } }
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
よく使うものメモです。 全般情報 Dashboards | Android Developers 公式のバージョンシェア。毎月5日くらいに更新される。 デザイン Design | Android Developers 公式のデザインガイドライン。各項目ごとにかなり細かく解説してある。 Downloads | Android Developers ↑内にあるデザインパーツ集。 便利なんだけど地味すぎて知らない人いそう。 特にActionBar用の画像とかandroid.R使うよりこっち使った方が捗る。 NavigationDrawer用の三本線とかもここにある。 Android Asset Studio Android用の色々な画像やStyleなどが簡単に生成出来る。めちゃくちゃ便利。 Android Niceties ナイスなデザインのAndroidアプリを紹介してるっぽいサイト。参考にな
本当はこういうのをエンジニアの未来サミットでお話できればよかったんだろうと思って、電車の中でふと思ったことをガンガン書く。 IT業界に携わってシステム開発を行っている方々で最も多い層は、受託開発という形でシステムを作ったりメンテナンスをされている方々のはずです。江島さんのニッポンIT業界絶望論というエントリが出てから「受託開発なんてうんこ」みたいな空気がすごく醸成された感があると思うのですが、無自覚にふわふわとイノベーションにかぶれるのもいい加減にして欲しいと思います。 確かに受託開発には負の側面があります。誰でも始めることが出来る参入障壁の比較的ゆるい世界ですが、どこでも出来るような仕事しかやっていないような会社はすぐに行き詰ります。そういうお話は結構耳にします。受託開発という形態をとって実際には技術者を派遣しているだけの創造性のかけらもないような会社もたくさんあると思われます。こういう
はじめに 今回と次回の2回にかけて、イマイチよくわかってないAndroid Studioのプロジェクト管理ファイルについて解説します。途中で飽きちゃう人のために、最低限共有する必要のある（バージョン管理する必要のある）管理ファイルを紹介します。 ここでの対象は.ideaディレクトリだけなので、説明のしやすさも兼ねて <PROJECT_HOME>/.idea/.gitignoreを作成し「.ideaディレクトリに対するホワイトリスト」を提示していきます。 図1 新しく<PROJECT_HOME>/.idea/.gitignoreを作成する リスト1 最低限必要な<PROJECT_HOME>/.idea/.gitignoreの例 *.xml !/gradle.xml リスト2 最低限必要な<PROJECT_HOME>/.idea/.gitignoreの例.gitignoreの内容 /.grad
ウォーターフォール開発とアジャイルの本質 - プロマネブログ 以下、３部作の２本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 前回と今回のシリーズはカテゴリ プロジェクトマネジメント論にまとめてます。 単一の開発手法の限界からハイブリッド方式へ 前回、各開発手法は失敗プロジェクトの反省から、それぞれ本質となる改善要素を持つことを示しました。 ウォーターフォール開発（以下WF）であれば、形式知化。 アジャイル開発であれば、フォーカス分割。 これらは排反する概念ではなく、それぞれの利点を活かしてプロジェクト運営を行うことが、より効率的なプロジェクト運営につながると考えられます。 とはいえ、ハイブリ
「かんばん！～もし女子高生がRedmineでスクラム開発をしたら」関連の最新 ニュース・レビュー・解説 記事 まとめ かんばん！～もし女子高生がRedmineでスクラム開発をしたら（終）： Hud美さんと学ぶRedmine×Jenkinsの神アジャイル 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法である「スクラム」とプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。今回は、継続的インテグレーションとJenkinsとは何か紹介し、RedmineやGitとの連携方法を解説します。（2013/5/17） かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）： Redmine×Gitのハーモニーは涙のチケット駆動開発!? 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェク
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
モデル駆動開発とは モデル駆動開発とは, (自然言語の) ドキュメントとソース･コードではなく, モデルを用いてソフトウェアを開発する方法論です. ドキュメントとモデルの違いは次のような点にあります. ドキュメントは曖昧さが大きいが, モデルは曖昧さが小さい ドキュメントは検証が難しいが, モデルは検証が可能である ドキュメントは実行できないが, モデルは実行できる 一方, プログラミング言語とモデリング言語との違いは次のような点にあります. プログラミング言語よりも高い抽象度で記述することができる (実際には複数の異なる抽象度で記述できる) 複数の異なる視点から記述することができる モデルそのものよりもモデル間の関係が重要になり, ノウハウやプロセスを資産化できる ドキュメントとモデルは本質的に異なるものですが, プログラミング言語とモデリング言語の違いは相対的なものです. つまりモ
6. ドメインモデル • 業務のデータと業務の機能をコードで表現 – ビジネス層に集約する – 関係するデータと機能をクラスにまとめる • ハイブリットなアプローチ – データの視点と機能の視点 • 両方からアプローチする • 二つの視点をいったりきたりする – データと機能の結びつき強める • クラスにカプセル化 • データ保持クラスと機能クラス（データ操作クラス） に分けるのはアンチパターン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
