タグ

システム開発に関するokitaのブックマーク (50)

  • エンジニアリングの必須図書 40冊 2023年版

    はじめに 今回の記事では、私の独断と偏見でエンジニアリングにおける必須の書籍を、以下の分野に分けて40冊共有する。 Web開発 行動経済学 ソフトスキル その他 対象とする読者 プログラミング初心者 どの書籍から読み進めればいいかわからないプログラマー なにか新しい書籍を読みたいひと なんとなくタイトルが気になったひと Web開発 『リーダブルコード』 良質なコードの原則と具体的なテクニックを丁寧に解説している。プログラミング初心者はまずこれを読むべき。良質なコード―要は、メンテナンスしやすいコードを書く上で重要なヒントを教えてくれる。コーディングで一生役立つ知識が満載だ。何度読んでも決して色褪せることのない不朽の古典である。 『14歳からのプログラミング』 図解付きでプログラミングの基礎(例:変数、関数、条件分岐)を理解できる。小難しい専門用語が一切なく、初心者でも問題なく理解できるよう

    エンジニアリングの必須図書 40冊 2023年版
  • プロジェクトマネージャ試験に20時間の独学で一発合格した方法 - 斗比主閲子の姑日記

    昨年10月にIPA(情報処理推進機構)の国家資格『プロジェクトマネージャ試験』を受験しました。 年が明けて「そういえば合格発表はいつだったっけ?」とIPAのサイトを見に行ったら、昨年12月下旬には合格発表がされていて、無くさずに持っていた受験票の情報を使ってチェックしたら、合格していたのでした。結構厳しいかと思っていたので、新年早々かなり驚いてしまい声が出たので、家族には変な目で見られました。 ※午前1は免除。午前2と午後1は60点以上で合格、午後2は4段階でAが必須 この記事では、非エンジニアの私がどうしてプロジェクトマネージャ試験を受験をしようとしたのか、どのような勉強をしたのかを紹介します。どなたかの参考になれば幸いです。 受験のきっかけ 2週間(20時間)しか勉強しなかった背景 勉強計画の策定 各試験のリソース配分 午前2(試験時間40分) 勉強時間 3時間 午後1(試験時間90分

    プロジェクトマネージャ試験に20時間の独学で一発合格した方法 - 斗比主閲子の姑日記
  • システム基盤設計の基礎

    交通量に見合った道路を作ったり,工場の排煙を減らす高度なごみ処理施設を建設したりする,といった基的な都市計画がなされていない,つまり「都市基盤」が整備されていなければどうなるか。道路は慢性的に渋滞しており,たどりつくだけで一苦労。街で交通事故が発生しても救急車が現場に到達することさえままならない。工場は排煙をまき散らし,深刻な大気汚染を引き起こす──。 情報システムにも,同じことが当てはまる。豊富な機能を持つアプリケーションを開発することは確かに重要だ。だが,サーバーやストレージの性能や信頼性,ネットワークの回線速度などを無視していては,システムの品質を保つことは難しい。システム開発に携わるあらゆるITエンジニアにとって,システムの性能や信頼性などを左右する「システム基盤」の知識は不可欠だ。そこで講座では,システム基盤を理解するための基的な技術や用語から,実践的な開発方法論までを解説

    システム基盤設計の基礎
  • 上流工程-見積もり---目次:ITpro

    新法で「アプリストアを競争状態に」の現実味、公取委はAppleGoogleと長期戦も 2024.05.16

    上流工程-見積もり---目次:ITpro
  • 機能要件の合意形成ガイド

    機能要件の合意形成技法WG の成果として、「発注者ビューガイドライン」 (2008年7月に公開)を改訂し「機能要件の合意形成ガイド」を公開します。 開発者が設計書を記述することのみではなく、発注者と開発者がシステム像をいかに共有し、行き違いなく合意形成を行うかに注目して、有効と思われる事柄を「コツ」としてまとめました。 「発注者ビューガイドライン」では画面、システム振舞い、データモデルの3つの技術領域、187のコツを掲載していましたが、「機能要件の合意形成ガイド」では、外部インタフェース、バッチ、帳票の3つの技術領域を追加するとともに、発注者視点のコツも充実させ、278のコツを掲載しました。 なお、初めて利用される方は、概要編を読んでいただくことをおすすめします。

  • ITシステム開発の実践プロマネ

    プロマネの手法は画一的ではありません。でも、学習して慣れることができます。そして、応用が効き、どんどんスキルアップします。 カスタム検索 プロジェクト全般 プロジェクトコスト管理 顧客満足を得るには プロマネと組織の係わり 第三者点検のありかた 新3K職場からの脱却 問題プロジェクトの回避 ヘルプマン投入の責任 IT環境変化とプロマネの役割 人材の有効活用と育成 高度IT人材の確保 パッケージソフトの適用 プロマネのリーダシップ モチベーションを高める 理想的な組織のありかた 商談フェーズ 提案を有利に進めるのには 魅力ある提案書の書き方 価格競争に陥らないために 正しい見積もりの仕方 RFPと提案型商談推進 既存顧客の商談推進 見積もりの妥当性を考える 要件定義フェーズ 重要なシステム要件定義 お客様志向の要件定義 要件定義に必要なもの 開発準備フェーズ 開発計画の策定 リスク分析と対策

  • プロジェクトの進め方

    計画プロセス 成果物と目標の明確化フェイズ このフェイズでやるべきこと プロジェクトが作り出す成果物やサービスの機能、特徴を明確にする。 プロジェクトの定量的な達成目標を明らかにする 【手順】 スコープ記述書を作成する スコープ・マネジメント計画書を作成する Project : ファイルのプロパティにプロジェクト名、プロジェクトマネージャ名を入力する Project : サマリータスクを表示する Project : プロジェクトの開始日・終了日を設定する Project : プロジェクト・カレンダを設定する Project : プロジェクト・カレンダをスケジュール領域に表示する

  • SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro

    ユーザー企業のみなさんは、システム開発プロジェクトを進める際、ITベンダーに次のような依頼をしたことはないだろうか。 経営判断でシステムの稼働日は決まっている。だが、肝心の要件は固まっていない。「何としても納期を守ってくれ。要件定義と並行して、仕様が固まっている部分から、開発作業に着手してくれないか」。 すでに開発が済んだ部分について、利用部門から大きな仕様変更の依頼が来た。「予算はもう増やせない。申し訳ないが、最初に契約した金額のままで修正してくれないか。次の案件も御社に発注するから」。 新システムの予算を何とか確保した。あとはこの予算でシステムを開発してもらうだけ。「ハードウエア込み、要件定義から運用設計まで、すべて一括で契約してほしい」――。 頻繁とは言わないまでも、システム開発を進めるうえでは“よくある話”だ。問題があると分かっていても、経営層や他部門からの要請で、こうした依頼を

    SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro
  • IBM Lotus Domino 8.5 XPagesによるアプリケーション開発 - 中級

  • ユーザがなかなか仕様を決めてくれないって? - 設計者の発言

    「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。検討の過程で明確にされたいくつかの選択肢があって、ユーザに決断力がないゆえに決めきれていないとすれば、確かに困ったものだと思う。しかし「ユーザがどんなシステムにしたいかをなかなか明確に語ってくれない」といったレベルの悩みなのであれば、問題はどちらかといえば設計者の側にある。 ◆デートの過ごし方を決める過程 休日のデートの過ごし方に関して男性から尋ねられて、事細かに意向を説明してくれる女性はどちらかといえば少ない。たいていは「うーん、いい景色を見て、なにか美味しいものを何かべたいな」なんて曖昧な答えが返ってくる。そのときに彼は「イイケシキだのナニカオイシイモノなんて曖昧な言い方をされてもわからない。もっと具体的に説明してくれないか」なんて言うだろうか。 そんなことを言う男がいるとすれば、彼女のいぶかる様子に気づくこと

    ユーザがなかなか仕様を決めてくれないって? - 設計者の発言
  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • Shibu's Diary: 「ソースコードをきれいに書く唯一の方法」は4つある

    渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 taken by Manuel_Marin なんとなく書いたら、アクセス数が10000件超えたソースコードをきれいに書くための方法の記事。r-westさんの「きれいなソースコードを書くために必要な、たったひとつの単純な事」と、uwiさんの「誰がためのきれいさ?」と、フォローのトラックバックまで頂きました。僕のも含めてそれぞれスタンスが違いますが、どれが正しいとか、どれが一番いいかというのはないと思っています。人によってどっちがいいかは別れるはずです。人によっていちばん苦労がなくて、モチベーションがあがる方法がそれぞれの人にとっての正解である、というのが僕の考えです。 モチベーションマネージメントというのがよく言われるけど、「モチベーションを上げろ」と言われて上がる人なんていませ

  • マジカランド --- 業務フローが誰でも簡単に作れる魔法のカード「マジカ」

    マジカを使った上流工程セミナーの受付を開始しました。 ※お申込は終了いたしました。多数のご参加、誠にありがとうございました。

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その1)

    ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。 曰く、 この無駄な成果物を作らされているのはウォーターフォールだから あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから スケジュール後半になって追い立てられるのはウォーターフォールだから いつまでたっても品質が向上しないのはウォーターフォールだから 赤字プロジェクトが垂れ流されているのはウォーターフォールだから このプロジェクトがデスマってるのはウォーターフォールだから 偉大な(?)グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。 仕事ができないのは道具が悪いと

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その1)
  • プロセス図の描き方とお作法--実は超簡単 !

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回は、仕事にプロセス志向を適用し、仕事の流れを図として「見える化」することで、改善すべきポイントがどこにあるかを把握しやすくなることを説明した。この「プロセス図」は見る人にとって理解しやすく、仕事の流れを正しく表現できているものであれば、実際にはどのように描いても差し支えない。 ただ、そうした図を描くときに覚えておくといいルールや、図を他の人と共有する場合に、より都合のよい描き方というものが存在する。まずは、それについて紹介しよう。 図でコミュニケーションのギャップを埋める 先ほど「どのように描いても差し支えない」としたが、実際に仕事の流れ図を描くとき、自分流に描いてしまうと問題が起こるケースもある。たとえば、後で複数の人が集まって図

    プロセス図の描き方とお作法--実は超簡単 !
  • Selenium

    Selenium automates browsers. That's it!What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should) also be automated as well. Selenium WebDriver If you want to create robust, browser-based regression automation suites and tests, scale and di

  • 満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ

    ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo

  • JFPUG COSMIC METHOD(COSMIC法)

    会は、1994年3月に設立以来、ソフトウェアメトリクスの団体としてファンクションポイント法の普及やソフトウェア定量化技術の確立に努めてまいりました。 この度、30周年の節目を契機に、今後のさらなる発展を目指して、会の名称を『ITシステム可視化協議会(MCIS)』に改称しました。ファンクションポイントは今後もひとつの技術として扱いつつ、ITシステム測定・可視化の推進を通じて、会員(法人・個人)の成長と、ITシステムに関わる全ての人や社会の発展に貢献します。

  • XML設計 - 要素か属性か

    ネイルで使う材料で、DIY時の木割れやネジ跡を派手にしたらかわいい OSB合板でちょっとしたボックスをつくりました。 ビス止め下手すぎて木を割ったり穴あけすぎたりした場所に、好きな派手色の樹脂を詰めてパテ代わりにしてみました。 ちょっと某HAYっぽみ出て可愛かったので、自分用にメモです。 手順 塗装 派手色グミジェルで失敗部分…

    XML設計 - 要素か属性か
  • 「テストコードにはWhat,ソースコードにはHow,そして,ドキュメントにはWhyを書くんだよ!」 : ξ*゜ー゜)ξ { 遅レス。 - 日本Rubyカンファレンス 臨時打ち上げ

    もう声が出ませんでした。終新幹線をスルーしてもう一泊。 テストについて熱く テストコードにはWhat, ソースコードにはHow, そして,ドキュメントにはWhyを書くんだよ! by 角谷さん。角谷さんの LightningTalk が聞けるのは(ここ数ヶ月の間は)「- 夏イベント」だけ! 追記: 個人的には、この説明がテストコードから始まっているのもポイントだと思う。 アサマシ! APIドキュメントはテストコードにあるべきでは? by すとうさん 嫁に隠れてバカエロ 嫁のコンピューターの hosts で自サイトを適当な IP にしておく。 キーボードショートカットで別アプリで隠す準備をしつつ、対面でサーフしてるらしい ハルヒは流石に寝静まってから見てるらしい。 SeasarはJava界の救世主

    「テストコードにはWhat,ソースコードにはHow,そして,ドキュメントにはWhyを書くんだよ!」 : ξ*゜ー゜)ξ { 遅レス。 - 日本Rubyカンファレンス 臨時打ち上げ
    okita
    okita 2009/01/28
    テストコードにはWhat,ソースコードにはHow,そして,ドキュメントにはWhyを書くんだよ!