システム設計の流れ・設計書の構成メモ - Qiita
システム開発に関わる機会が多くなってきたので、仕様書作成に関して色々とメモ。 ウォーターフォールモデルでの上流工程について記述していく。 上流工程は 「要件定義」→「外部設計」→「内部設計」の流れに従って進められていく。 要件定義 開発するシステムに求められている機能などの要件をまとめる事。 例えば 「パスワード認証」「データベース内検索」などの機能要件 「入力データ」「出力データ」の仕様 「保守性」「操作性」などの非機能要件 業務フロー などが挙げられる。 RFP(提案依頼書)作成や事前調査などを行って、本当に必要な要件をじっくりと精査していく。 ココでまとめた内容を元に開発が進められる為、洗礼された要件定義を行うことで見落としによる仕様変更の回数を減らす事が出来る。 要件定義時に扱うのは必ず保証しなければならない項目が中心であり、UIデザインなどのデベロッパー側が決めても構わない部分は
Storybook First な開発のススメ
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話 - Qiita
また、この図の説明においては理想的なケースにおいても1つ前の工程に戻る事が述べられています。 " Hopefully, the iterative interaction between the various phases is confined to successive steps. " (投稿者訳) 理想的には、各段階において工程が前後する範囲は直近の工程に限られる。 理想的でない場合はどうかというと、テストから設計まで工程が戻りうると示唆しています。 "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as dist
GitHub Issuesを個人用のTodo管理アプリとして使っている
個人的なタスク管理ツールとしてGitHub Issueを使うようにしてその仕組みを色々と作っているので、そのアーキテクチャについてのメモ書きです。 後述しますが、GitHubをベースとすることでプログラムでの拡張性が高いというのが特徴です。 セットアップが色々と必要になるためぱっと再現しやすい感じではなかったり一部未公開になってます。 需要があったらオープンソースとして公開できるように整えます。 GitHub Issuesとタスク管理ツールでの課題 自分の中で、タスク管理ツールとGitHub Issuesを両方使う場合に次の課題がありました。 自分のタスクの半分以上はGitHubに何かしら紐づく情報(オープンソース、ブログ、仕事)であったため、GitHub Issueとの二重管理感がある GitHub上で複数のリポジトリのタスクを管理するのが難しい 1つ目は、タスク管理ツールを使っても結局
クックパッド サマーインターンシップ2017 「17day 技術インターンシップ」を開催しました - クックパッド開発者ブログ
いつもお世話になっております。エンジニア統括マネージャーの高井です。 クックパッドでは毎年恒例となりつつある、クックパッドのサマーインターンシップのうち「17day 技術インターンシップ」を開催しました。インターンに来てくれた学生のみなさんは本当に優秀で、毎日真剣に取り組んでくれました。本当に感謝しています！ インターンは、前半の「サービス開発講義・課題」パートと後半の「サービス開発実践」から構成されています。前半パートでの講義について資料を公開いたしますので、みなさまぜひご覧ください。 【1日目】サービス開発 初日は、クックパッドで実践されているサービス開発の手法について学ぶワークショップです。グループでのユーザーインタビューを通じてサービスの設計をしました。 【2日目】Rails・TDD・Git 昨年に引き続き、講義初日はGit、TDD、Railsを1日で一巡りするという、忙しい構成で
エクストリーム・プログラミング - Wikipedia
エクストリーム・プログラミング、XP（英: extreme programming）は、 ソフトウェア品質 を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。アジャイルソフトウェア開発の一つとして[1][2][3]、短い開発サイクルで頻繁に「リリース」することを推奨することで、生産性を向上させ、新しい顧客の要求を採用するためのチェックポイントを導入することを意図している。 エクストリーム・プログラミングの他の要素には、ペアでのプログラミングや広範なコードレビューの実施、すべてのコードのユニットテスト、機能は実際に必要となるまでは追加しない、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある[2][3][4]。この方
実践！カンバン方式で週1リリースを可能にする超高速アプリ開発フロー | Wantedly Engineer Blog
はじめまして、WantedlyのユーザグロースチームでAndroid開発をしている 吉岡といいます。 今年の4月に新卒入社しまして、インターンだった頃は� ビジネスメッセンジャーのSync を、そして今は Wantedlyの会社訪問アプリ および 就活インターンアプリ を開発しております。 まれに勉強会などにも出没しますので、どうぞよろしくお願いします。 さて、Wantedlyのプロダクトづくりを象徴する「ディレクターの居ないチーム」。 トップダウン的に愚直にコードを書くのではなく、プロダクトに関わるエンジニア一人ひとりが 課題を見つけ、アプローチを考え、実装し、検証までを行うことが求められます。 グロースハックを成功させるため、Android版は 毎週1回リリース というとんでもなく早いサイクルを設定しています。そしてこのサイクルを実現するため、4月から 継続的に開発方式を見なおしていま
GitHubを使った今時のWebアプリ/システム開発の流れ - Rails Webook
GitHubを使った今時(2014年頃)のWebアプリ/システム開発の流れを説明します。 Webアプリケーション、スマホアプリ/スマホゲームを開発している会社では、「アジャイル開発」が主流となっています。ユーザーの反応を見て、機能追加やバグ改修を行い、商用環境に数日、１週間でリリースするといったスピード感で開発するために「GitHubを使った開発フロー」が行われています。 ※必ずしもGitHubを使わなくても良いですが、多くの会社はGitHubやその類いのツールやサービスを使っています。 目次 開発フローの背景 会社内で開発する開発フロー(on GitHub) オマケ：OSSに貢献する開発フローメモ(on GitHub） 1. 開発フローの背景従来からある開発方法論である「ウォーターフォールモデル」では、 1,2年開発している間にビジネス環境が変わってしまったため、システム要件がビジネス要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
react-problems.md