ソフトウェア開発プロセス
第2回ではソフトウェア開発プロセスとSLCPについて詳しくみていきます。 ソフトウェア開発プロセス概要 ソフトウェア開発プロセスは、要件定義、設計、コーディング、テストといったプロセスについて、計画通りの期間・品質で実行することを目的としています。ソフトウェア開発プロセスは、1960年代後半頃からその概念が生まれ、1980年代に「ウォーターフォール」「スパイラル」といった代表的なものが考案されました。近年ではさらに新しい「アジャイル型」なども使われ始めています。 代表的なソフトウェア開発プロセス ここで、代表的なソフトウェア開発プロセスをいくつかみていきましょう。最初はウォーターフォールモデルです。図が示しているように、水が上から下に流れるようにプロセスが移っていきます。SLCP もこのウォーターフォールモデルに基づいています。 ウォーターフォールモデルを説明する際に、V字モデルとして図示
開発プロセスと開発標準化 | ITエンジニアが作るメディア Tech Fun Magazine
通常、受注をする前に営業やITコンサルタントが、エンドユーザのシステムに関する要望や、現状システムの問題点などをヒアリングします。要望や問題点を踏まえて企画を立て、エンドユーザにプレゼンをして内容のすり合わせを行います。 要件定義では、エンドユーザの現状業務をシステム分析し、業務要件とシステム化するために必要なことを定義します。また、要件定義を、システム方式設計と呼ぶ場合もあります。 エンドユーザは、システムについて詳しくない場合もあります。要求が曖昧だったり、矛盾することもあります。実現可能なものとして、エンドユーザの要求をITコンサルタントやSE（システムエンジニア）がとりまとめていきます。 エンドユーザとシステム開発者で認識のズレが生じると、致命的な設計上の欠陥や実装漏れにつながる可能性があります。
githubを使っての開発(1) －実践github-flow－ | PPl@ce
今は開発でgithubを利用しています。 開発をおこなう上で、githubをどのように扱えば良いのか。 思いの外、github-flowが良かったのでメモ書き程度に色々と書いておきます。 github-flowについて GitHub Flowとは何か？ masterブランチのものは何であれデプロイ可能である 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する（例: new-oauth2-scopes） 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト を作成する 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる マージをしてmasterへpushしたら、直ちにデプロ
git の運用指針 - Cube Lilac
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GDC 2012のUnchartedの水表現のスライド – Shader.jp
産総研(AIST): 格子ボルツマン法とフェーズフィールドモデルによる複雑流体流れ数値実験 (LBM-& PFM-CFD Simulation of Complex Fluid Flows)
Stable free surface flows with the lattice Boltzmann method on adaptively coarsened grids
