タグ

開発に関するjo-taroのブックマーク (23)

  • タスク2-2 実態把握

  • 如流, 新一代智能工作平台

  • 基本設計-1:日本IBMの「IBM-DOA」に基づく外部設計フェーズの手順

  • MinGW - Wikipedia

    MinGW(ミン・ジー・ダブリュー、Minimalist GNU for Windows)はGNUツールチェーン、GCCをWindowsで利用できるようにする開発環境である。Windows APIのためのヘッダファイルを含んでおり、GCCでネイティブWindowsアプリを開発できる。MinGW自体はほぼ開発終了だが、後継のMingw-w64が積極的に開発されている。 MinGWプロジェクトは32ビット環境向けに主に2つのパッケージを配布している。ひとつはWindowsに移植したGCCで、コマンドラインやIDEから利用できる。もう1つは軽量のUNIX風シェル環境であるMSYS (minimal system) である。端末エミュレータのrxvtと開発ツールのautoconfを実行するためのコマンド群も含まれている。これらはCygwinをフォークして誕生した。 Win32 APIを利用するため

  • Trac - Wikipedia

    Trac(トラック)は、ソフトウェアのプロジェクト管理とバグ追跡のためのツールである。ウェブベース、オープンソースであり、CVSTracに影響を受けた。Edgewall Softwareにより開発され、保守されている。 TracはPythonにより実装されている。2005年の中ごろまではGPLで配布されていたが、バージョン0.9以降は修正BSDライセンスで配布されている[2]。 修正BSDライセンスとGPLは、どちらもフリーソフトウェアライセンスである。 Windows環境向けにはWindows上にSVN/Trac含めた環境を簡単に構築できるTrac Lightningがある。 機能[編集] Tracはバグのデータベース、バージョン管理、ウィキ間のハイパーリンク情報を提供する。 また、Subversion、Git、Mercurial、Bazaarといったバージョン管理システムへのウェブイン

  • 『パリの女』 - HONZ

    岩波書店やみすず書房など8社で行っている「書物復権」企画の1冊だ。奥付によると、翻訳版の第1刷は1959年4月15日、第2刷は2010年5月27日である。あくまでも第2刷であって、第2版ではない。したがって、今回付け加えられた文章などはない。あとがきも訳者の朝吹登水子による1959年3月24日付けのものである。そして文はもちろん活字だ。 文字だけの文は68ページ、その後ろに文に対応した114枚の写真が追うという構成だ。いまではパリに憧れることは、じつにノスタルジックな心象だ。しかし、書には憧れるべきパリがある。登場するのはジュリエット・グレコ、ジジ・ジャンメール、バルバラ・ラージェやムーランルージュの踊り子たち。それに市井の働く女たち、娼婦、尼さんなどパリに住む女たちである。 この翻訳のタイトルは『パリの女たち』ではなく『パリの女』である。原題は『Femmes de Paris』

    『パリの女』 - HONZ
  • 今週の本棚:松原隆一郎・評 『新しい市場のつくりかた』=三宅秀道・著- 毎日jp(毎日新聞)

  • フォーク (ソフトウェア開発) - Wikipedia

    この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "フォーク" ソフトウェア開発 – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL(2023年5月) ソフトウェア開発におけるフォーク(英語: fork)即ち派生とは、あるソフトウェアパッケージのソースコードから分岐して、別の独立したソフトウェアを開発することである。 フリーソフトウェアやオープンソースソフトウェアでは、ライセンス上、原作者の許可なしにフォークが可能である。 ブランチング[編集] 多くのプロジェクトでは、バグ修正のみが行われる安定版(英: stable version)あるいはリリース版(英: release version)と、

    フォーク (ソフトウェア開発) - Wikipedia
  • マイクロソフト製品を購入前にテストする「最安」の方法

    企業ユーザーがWindowsを使ううえで,知っているとちょっと役に立つ「Windowsの豆知識」を紹介するWindows談話室。第4回では,マイクロソフト製品を採用するかどうか検討する際に,製品版の機能や使い勝手をテストする便利な手法を紹介する。 Windows担当デスク(以下デスク):いよいよ,「Windows Server 2008」の製品候補版がリリースされたね(関連記事)。Windows Server 2008の導入を考えているユーザーは,きっとテストを始めているころだろう。でも,実際にWindows Server 2008を導入するなら,製品版でもテストをしたいところだね。マイクロソフト製品を,購入前にテストする方法はあるのかな? Windows担当記者(以下記者):マイクロソフトは主な製品について「180日限定評価版」という,インストール後180日間だけ利用できる評価版を公開し

    マイクロソフト製品を購入前にテストする「最安」の方法
  • ピアレビュー(ぴあれびゅー)

    ソフトウェアプロセス(注1)の各段階で生成される成果物(注2)を同僚やチームメンバーがレビューすること。あるいはそのための手法の総称をいう。 ピアレビューは、組織がソフトウェア開発の品質保証を行う際の第一歩である。ソフトウェア開発の上流工程(注3)から実施可能なレビューは、ソフトウェア品質を向上させるのに有効性の高いやり方だとされる。一方、ソフトウェア成果物の検証作業は、作成した人以外の人間が行った方が効果が高いとされる。ピアレビューは身近な他人である同僚の力を借りて、成果物の品質向上を図る手法といえる。 ピアレビュー手法の代表的なものとして、インスペクション、チームレビュー、ウォークスルー、パスアラウンド、ピアデスクチェック、アドホックレビューなどが知られる。 一般にpeer reviewとは、学術論文を学会誌などに掲載する際に行われる査読をいう。同じ分野の研究者(peer)が原稿を読

    ピアレビュー(ぴあれびゅー)
  • PD思考法の基礎と情報収集(その1)

    PDとは PDとはProblem Determinationの略である。直訳すれば、「問題を確定する」などになるだろう。われわれは問題の切り分けをし、問題部分を特定する、つまり問題判別することをPDと呼んでおり、「PDをする」「PDはどこまで進んでいる」といった使い方をする。 PDを行う目的は、問題要素を特定することにある。それに対し、要素内のプログラムの問題個所を特定しステップ修正するという作業、debug&fixは開発の役割であり、PDではない。場合によってはPDでデバッグまで踏み込む必要性も生じるが、それは基的にはPDの役割ではない。コードのバグを発見し修正するには、バグを持つコードを含む要素を特定する必要がある。その要素に到達するまでの道のりを明確にし、問題の発生源を特定するのがPDである。 PDの例 それでは、ある問題を例に、PDの流れを説明してみよう。 さて、このような連絡が

    PD思考法の基礎と情報収集(その1)
  • "エンジニアとしての生き方"の感想:少しでもパラノイアになってみる:オルタナティブ・ブログ

    "エンジニアとしての生き方"を読んで感想です。著者の中島 聡氏は有名な方で、改めて説明する必要もないと思いますが、ブログなどを参考になるかと思われます。 書を一言で評価するならば、"すごくおもしろい"です(あほっぽい評価ですが、シンプルな表現で)。文字数がそれほど多くないため、数時間程度で読み終わります。また、若ければ、若いほど書に向くいいと思います。出来れば、大学生もしくは就職したばかり方のほうが書で伝えたいことがダイレクトに通じると思います。 ソースの書き方に関するアドバイスがありますが、至極全うで驚きました。一度とりあえず、作ってそれからはリファクタリングを勧めていますが、私も今作っているものに関して、一度作ってから、作り直してしています(3回ぐらい直した)。すこしずつ機能追加も行いますが、やはりまずは全体像やネックになるところを見つけるためにも、一度ある程度動作するものがない

    "エンジニアとしての生き方"の感想:少しでもパラノイアになってみる:オルタナティブ・ブログ
  • ユーザ受入れテスト(UAT) - ユーザ受入れテスト(UAT)のテストケースを書くことになりました。書いたことがないのですがどのレベ... - Yahoo!知恵袋

    ユーザ受入れテストとは、ユーザ側が納品された製品を受け入れる(=対価を払う)かどうか を判定する為の重要なフェーズです。 開発側からすれば、受入れ検収なしでメクラ判をついてもらったほうがありがたいのですが、 それでは番稼動してから不具合が起こった時に困るのはユーザです。 主目的は「要求仕様」を満たしているかのチェックです。 「要求仕様書」「要件定義書」などと照らし合わせ、チェックすることになります。 なので、システムテストとは異なり、システムの中身をチェックするのではなく、 システムをブラックボックスとして、業務が想定通りに行えるかという観点でテスト を実施します。 定型業務、非定型業務、日次業務、月次業務、決算業務などの 各業務単位で、業務フローに基づいた手順でシステムのI/Oを検証することになります。 また、運用テストとしては、高負荷テスト(想定最大データ量での処理能力テスト)や、

    ユーザ受入れテスト(UAT) - ユーザ受入れテスト(UAT)のテストケースを書くことになりました。書いたことがないのですがどのレベ... - Yahoo!知恵袋
  • 無償版「Visual Studio 2008」でアプリ開発からウェブ開発までを楽しむ - builder by ZDNet Japan

    マイクロソフトの統合開発環境「Microsoft Visual Studio」。このIDEの最新版が今夏、「Visual Studio 2008 SP1」として公開された。 Visual Studioシリーズには一部の機能を無償で提供する「Express Editions」が用意されていることをご存知の方も多いだろう。Visual Studio 2008 Express Editionは下記4種類のラインナップだ。 Visual C# 2008 Express Edition Visual Basic 2008 Express Edition Visual C++ 2008 Express Edition Visual Web Developer 2008 Express Edition 今夏までは各ツールを個別にダウンロードしてインストールする必要があったが、Service Pack 1

    無償版「Visual Studio 2008」でアプリ開発からウェブ開発までを楽しむ - builder by ZDNet Japan
  • 急がば回れ──質の良い仕様書の作り方

    前回は、自社の業務に必要なシステムの要件の定め方について触れた。今回はその次のフェイズ──仕様決定について考えていこう システムの要件が決まったら、これを具体的なシステム仕様書に落とし込んでいく必要がある。システム仕様書とは、要件を満たすための具体的なシステムの機能・性能に対する要求事項を文書化したものだ。 ソフトウェアの場合、要件定義や仕様書の段階で発見された不備を是正するコストと、運用段階に入ってからのそれとでは、実に200倍の差があるという説がある。また、NASAの記録では、最初の20%の工程に、全体の作業時間の15%を投入することで、プロジェクトの成功確率が80%にまで高まるという。 「早く、安く、最小の投資で最大の効果を生むシステム構築をする」には、システム仕様書の作成に手を抜いたり、他人任せにすべきでない。「急がば、回れ!」である。 質の高い仕様書とは 要件を満足するための、必

    急がば回れ──質の良い仕様書の作り方
  • 7つのアジャイル開発手法の実践ガイド(第2回)

    アジャイル開発手法を採用すべきだということはわかっていても、いろいろある開発手法をすべて検討しようとすれば、調査だけでかなりの時間がかかってしまいます。組織にとってどの方法論が適しているかを知るにはどうしたらよいでしょうか。この2回シリーズでは、7つの人気の高い開発手法の表と裏をすべて紹介し、組織に最適な開発手法を選ぶためのヒントを示します。第2回では、AUP、クリスタル、DSDMについて説明します。 はじめに 稿は、さまざまなアジャイル開発手法を紹介する2回シリーズの記事の第2回です。シリーズでは、7つの人気の高い開発手法の表と裏をすべて学習し、組織に最適な開発手法の組み合わせを選べるようになることを目的としています。第1回では、アジャイルの概要を説明し、エクストリームプログラミング(Extreme Programming:XP)、スクラム、リーン、機能駆動型開発(Feature D

    7つのアジャイル開発手法の実践ガイド(第2回)
  • 「アジャイル」の全貌

    アジャイル・ソフトウエア開発」は、いま最も話題を呼んでいるソフトウエア開発手法だ。ドッグイヤーと叫ばれ出してから久しい今日、「完全な要件定義」、「完全な設計」、「完全な実装」を求める従来のソフトウエア開発手法は、もはや無力である。経営スピードにマッチした新たな手法が求められている。アジャイル開発は、ソフトに対する要求の変化を受け入れ、同時に“人間”を重視することで、ユーザーに価値をもたらすソフトを“超高速”で実現することを狙う。ここでは代表的な6種類のアジャイル開発手法の概要を紹介する。 稿を含む特集「企業情報システムの再生に挑む【システム構築編】: 経営スピードに負けないシステム作り」 のページはこちら アジャイル・ソフトウエア開発(以下、アジャイル開発)とは、「ユーザー(顧客)に価値をもたらし、かつ動作が保証されたソフトを超高速で実現する」という目標を持つ複数のソフトウエア開発手法

    「アジャイル」の全貌
  • 勝手にソフトウェア保守開発: 保守開発者が一番欲しいドキュメントとは

  • ソフトウェア構成管理 - Wikipedia

    ソフトウェア構成管理(ソフトウェアこうせいかんり、英: software configuration management、SCM)は、ソフトウェア開発プロジェクトをその成果物を通して制御・管理する方法論である。ソースコードや文書などの成果物の変更履歴を管理し、製品のバージョンやリビジョンに個々の成果物のどのバージョンが対応しているかを識別し、任意のバージョンの製品を再現可能とする。 バージョン管理システムは SCM のためのツールであるが、バージョン管理システムそのものを SCM と呼ぶこともある。しかし、一般にソフトウェア構成管理はバージョン管理とは等価ではなく、バージョン管理を制御するマネジメント的要素が含まれる。 当初、ソフトウェア構成管理(SCM)は単に CM(構成管理)と呼ばれており、来はハードウェア開発と製造制御のためのものだった。以下では主にSCMツールの登場を時系列に並

  • インスペクションとは何か?

    なぜインスペクション/レビューが必要か? 「テストは品質を確認する場である。さらなる品質向上を望むならば、設計品質をはじめとした作りこみの段階での品質向上も必要だ」というような話を聞かされたことのある技術者は多いでしょう。 ソフトウエアインスペクション/レビューは、テストよりも早い段階で実施できる品質向上技法であり、やり方さえ間違わなければその効果は絶大です。ウォータフォールモデルでの開発の通過イベントと考えられていることもありますが、特定の開発モデルに依存したものではなく、繰り返し型開発、オープンソース開発でも使われています。また、ペアプログラミングの代替手段として位置づけている組織もあり、実は広く使われている技法なのです。 ソフトウエア開発は要件定義、設計、コーディング、テストの順番でコーディングまでは段階的な詳細化が進められます。期待どおり詳細化できたかどうかはテストでプログラムを動