開発プロセス

ウィキペディア小見出し辞書

開発プロセス

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/06/17 10:00 UTC 版)

「近鉄21020系電車」の記事における「開発プロセス」の解説

本系列の開発においては、メーカーである近畿車輛内部において3つの開発チームによるコンペ形式が導入された。各チームが近鉄にプレゼンテーションを行ない、その中から評価の高い提案を近鉄が採用した。それが、弧を描く多目的型トイレ、リクライニング時に座面が沈み込む座席、特徴的な先頭形状として具現化された。

開発プロセス

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/01/31 07:48 UTC 版)

「韓国ファイバー・プリムス」の記事における「開発プロセス」の解説

2005年に大韓民国建設交通部（現在の国土交通部）主導の下、韓国型低床バスの開発事業に着手した。車両製造元の韓国ファイバーに105億ウォンの研究事業費が投資され、2008年までの3年間の開発期間で超低床軸の国産化と車体の軽量化による燃料費の削減、環境に優しいバス運行システムの構築、拡大普及によるバスの標準化を開発目標とした。 2008年11月には、国家研究開発事業の成果をもとに作った韓国型低床バスの基準となる主な仕様と適用時期を明示した低床バス標準モデルの基準を発表し、その後1年間の車両製作準備期間を経た。 翌年の2009年に低床バス標準モデルの量産体制を構築し、同年11月にデビューした。

開発プロセス

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/04/02 02:19 UTC 版)

「Windows Management Instrumentation」の記事における「開発プロセス」の解説

WMIはCIMとプロバイダ群によって管理対象を抽象化しているため、プロバイダの開発にはいくつかのステップが含まれる。主な4つのステップを以下に挙げる。 ステップ1 - 管理対象モデルを作成モデル定義 モデル実装 ステップ2 - WMIプロバイダを作成実装すべきプロバイダの種類を決定 プロバイダのホスティングモデルを決定 ATLウィザードでプロバイダのテンプレートを作成 プロバイダのコードを実装 プロバイダを WMIとシステムに登録 ステップ3 - プロバイダのテスト ステップ4 - 利用者サンプルコードを作成

開発プロセス

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/08/15 00:56 UTC 版)

「Lazarus (統合開発環境)」の記事における「開発プロセス」の解説

Lazarusプロジェクトには多くのプログラマとテスタが集まり、良いコミュニティと高度な開発プロセスをもたらしている。問題点があればディスカッションボードで解決され、プログラマがそれを修正するパッチを投稿する。毎晩テスト前のビルドが作られ、ベータテスタに渡される。Lazarusの開発は大変ダイナミックである。

開発プロセス

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/08/29 14:09 UTC 版)

「Xerox Star」の記事における「開発プロセス」の解説

パロアルトのあるグループは、ハードウェアとプログラムツールを結ぶOSの基礎研究を行なっていた。エルセグンドのチームは彼らと協力してユーザインタフェースとユーザアプリケーションの開発を進めていった。 彼らの作業は、彼ら自身が研究開発していたファイル共有システム、プリントサーバ、電子メールといった技術に強く依存する形で進められた。ARPANET（インターネットの原形）への接続も持っており、これを通してエルセグンドとパロアルト間の打合わせが行なわれていた。 Starはプログラミング言語Mesaを用いて作られた。この言語はModula-2及びModula-3に大きな影響をあたえたものである。Mesa自身はオブジェクト指向言語ではないが、各種プログラミングツールとプログラミング技法は擬似的なオブジェクト指向設計とオブジェクト指向プログラミング環境を提供していた。 Mesaでのプログラミングにはモジュール毎に2つのファイルを用意する必要があった。一つは各オブジェクトのデータ構造定義と手続き宣言をする定義部で、もう一つは各手続きの処理コードが記述される部分である。 Starの開発チームは洗練された統合開発環境Tajo（外部からは "Xerox Development Environment（英語版）; XDE" と呼ばれていた）を使っていた。TajoはSmalltalk-80の環境に似た点を多く持つが、それ以上のツールを持っていた。例えば、"DF" というバージョン管理システムがあり、プログラマはモジュールに変更を加える前にチェックアウト作業を行なわなければいけないようになっていた。依存関係にあるモジュールの変更を要するような変更点はきっちりと追跡管理され、文書化された。そして低レベルのモジュールの変更は、多くのレベルの認証を受けなければならなかった。 開発チームは精力的に作業を進めていった。そして数多くのプロトタイプ作成とテスト作業をこなさなければいけなかった。PARCの研究環境にあったネットワークプロトコルやデータエンコード方式が能力不足だと感じれば、彼らはそれを新たに作り直していった。 当初、Altoだけが開発に使える機器であった。それはこのソフトウェアの過酷な負荷に耐えるだけの十分な能力を持っていなかった。最後の段階までハードウェア構成の見直しが行なわれ、プロセッサですら能力不足であると判断されれば見直された。多くのソフトウェアは再設計され、書き直され、ユーザのテストの結果や市場の条件、システムの都合に基づいて改良がなされた。 最終的には、Starの機能仕様書には記述されたものの未実装になっている機能がたくさんあったが、市場に送り出されることになった。出荷直前の数ヶ月は信頼性とパフォーマンスのテストに費やされた。

開発プロセス

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/03/16 16:52 UTC 版)

「OpenSSH」の記事における「開発プロセス」の解説

OpenSSHの開発は、まずOpenBSD上で安全・堅牢なプログラムを開発し、他のシステムでの実装はOpenBSD版を基にオペレーティングシステム依存部分のみを移植するという方針で行われている。移植版には、区別のためバージョン番号に、Portable release を意味する "p(数字)" が付けられる。

開発プロセス

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/02/14 00:46 UTC 版)

「Nios II」の記事における「開発プロセス」の解説

Nios IIの開発は、2つの別々の段階からなっている。ハードウェアの生成とソフトウェアの作成である。 アルテラのEmbedded Developer Suite (EDS)と呼ばれるアプリケーション内にホストされる。EDSは完全な統合開発環境で、ハードウェアとソフトウェアの両方を、2つの段階のいずれでも管理することができる。