タグ

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

  • 逆転敗訴した野村情シスがIBMに送った悲痛なメール、横暴なユーザーを抑えきれず


    HDIBM362019320214姿  HDIBMX HDIBM X X
    逆転敗訴した野村情シスがIBMに送った悲痛なメール、横暴なユーザーを抑えきれず
  • 人月の神話 - Wikipedia


    : The Mythical Man-Month: Essays on Software Engineering [] IBM  OS/360    197519952020
    peketamin
    peketamin 2021/06/05
    初めて作ったシステムがバグだらけのひどいものだったとき「一から全部作り直したい」と上司に言うと却下された。あれはセカンドシステム症候群を止めていたのだと今理解した
  • 国の情報システム契約 70%超で入札参加は1業者 会計検査院 | IT・ネット | NHKニュース


    調701 30調 4231173.9 9613.5 
    国の情報システム契約 70%超で入札参加は1業者 会計検査院 | IT・ネット | NHKニュース
    peketamin
    peketamin 2021/05/26
    ブコメ参考になる
  • 非機能要件を見極める【前編】:ヒアリングでは不十分


     10宿2  
    非機能要件を見極める【前編】:ヒアリングでは不十分
  • Smart UI が優れている? | システム設計日記


    Domain-Driven Design (DDD)  Smart UI ( context) Smart UI 5Smart UI     )   Visual Studio      104
  • 近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)

    2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー

    peketamin
    peketamin 2014/12/11
    ""チームの記憶" に価値を認めるなら, こうしたプロジェクト単位のチーム構成がどれだけ散財なのかがわかると思う"/めっちゃ文章うまい/Blink の開発者なのか!
  • 永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

    この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 | 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り

    永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
    peketamin
    peketamin 2014/09/18
    確かに要件定義に価格設定しておけば、最悪その段階で契約打ち切りでも要件自体は他社開発へ流用可能だしね…
  • コモンクライテリア - Wikipedia


    Common Criteria, CC ISO/IEC 15408  IT  "Common Criteria for Information TechnologySecurity Evaluation" ISO/IEC 15408  "Evaluation criteria for ITsecurity", JIS X 5070  201933.1 520174 CC
  • 「納品」をなくさなくてもうまくいく - arclamp


      IT使  
    「納品」をなくさなくてもうまくいく - arclamp
  • SIerの社内フレームワークを前向きに捉えてみる - たけぞう瀕死ブログ

    その昔、僕が客先常駐ソルジャーだった頃、そこには辺り一面炎上プロジェクトばかりでした。 当時僕の参加していたプロジェクトでは、 SQLで書いたら数秒〜数分で済むであろうバッチ処理をなんちゃってEJB 1.0のような独自フレームワークを使って数時間かけて処理し、挙句に朝までに終わらないと問題になって作り直したり なぜかすべてのバッチがSQL*Plusを叩くシェルスクリプトで実装されており条件分岐で済むようなケースがすべて別ファイルとしてパターン数分用意されていたため処理を少し修正するだけでも数百のシェルスクリプトを修正しなくてはいけなかったり はたまたオンラインの処理では1人のユーザがボタンを押すだけで200M以上のメモリを消費しこれ想定ユーザ数での使用にどう考えて耐えられないでしょみたいなものがあったり ResultSetをJSPまで持ち合わしてどこでもクローズされていなくてJMeterで

    SIerの社内フレームワークを前向きに捉えてみる - たけぞう瀕死ブログ
  • デスマーチが起きる理由 - 3つの指標

    Your system administrator has blocked your computer or device. Please contact the system administrator.

  • 神秘かつ壮大な銀行システム建造物、みずほ銀行の「桜田ファミリア」 : 市況かぶ全力2階建

    決算発表が出ないことを怪しんでストップ高まで買われたエックスネット、TOBされるどころか逆に資提携解消で切られて過剰にお金が流出するお笑い劇場に

    神秘かつ壮大な銀行システム建造物、みずほ銀行の「桜田ファミリア」 : 市況かぶ全力2階建
  • Amazon.co.jp: なぜ、システム開発は必ずモメるのか?: 細川義洋: 本

    Amazon.co.jp: なぜ、システム開発は必ずモメるのか?: 細川義洋: 本
  • IT業界は業界の外へ向けて語る言葉を持つ気がない - アンカテ


    IPAX 2008 -  @IT調id:next49 IT 西西101010  8393
    IT業界は業界の外へ向けて語る言葉を持つ気がない - アンカテ
    peketamin
    peketamin 2014/02/22
    "日本のIT産業は、30年前の技術に最適化されている。"
  • 「どうすれば価値を生み出すか」を知るためにヌーラボ で行っていること | 株式会社ヌーラボ(Nulab inc.)


     10西   20  Backlog  Cacoo 使
    「どうすれば価値を生み出すか」を知るためにヌーラボ で行っていること | 株式会社ヌーラボ(Nulab inc.)
  • 分かりやすい提案書はアウトラインが美しい

    分量がある文書を作成する際には、文書全体の「アウトライン(骨格、構成)」をきちんと作り上げてから内容を記述する必要があります。今回は、「読みやすく分かりやすい提案書」にするアウトラインの作成方法について紹介します。 読みやすい文書は「階層構造」をしている 読みやすい、分かりやすい文書は、全体が階層構造になっています。文書は、一般的に下記のような階層で構成されています。 大見出し(章) 中見出し(節) 小見出し(項) 階層構造は、複雑で大量の情報を含んだ文書の内容を、分類・整理するために必要不可欠です。階層化した文書は、各トピックで記述される範囲が決まっているため、焦点を絞って読むことができます。このことは、読者の理解を大いに助けます。 階層構造の方法について、順を追ってみていきましょう。まず「大見出し」の層に分割します。その後に各「大見出し」を「中見出し」の層に、さらに必要であれば「中見出

    分かりやすい提案書はアウトラインが美しい
  • 開発プロセスと開発標準化 | ITエンジニアが作るメディア Tech Fun Magazine

    通常、受注をする前に営業やITコンサルタントが、エンドユーザのシステムに関する要望や、現状システムの問題点などをヒアリングします。要望や問題点を踏まえて企画を立て、エンドユーザにプレゼンをして内容のすり合わせを行います。 要件定義では、エンドユーザの現状業務をシステム分析し、業務要件とシステム化するために必要なことを定義します。また、要件定義を、システム方式設計と呼ぶ場合もあります。 エンドユーザは、システムについて詳しくない場合もあります。要求が曖昧だったり、矛盾することもあります。実現可能なものとして、エンドユーザの要求をITコンサルタントやSE(システムエンジニア)がとりまとめていきます。 エンドユーザとシステム開発者で認識のズレが生じると、致命的な設計上の欠陥や実装漏れにつながる可能性があります。

  • システム開発の王道を極める


    |  |  .  .  .  .  .  |  | |  |  .  .  .  .  .  |  | |  |  .  .  .  .  .  |  | |  |  .  .  .  .  .  |  |   
  • 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」~情報システム・モデル取引・契約書~

    情報システムの信頼性 非機能要求グレード報告書 ソフトウェアメトリクスの高度化 産業構造・市場取引の可視化 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」 ~情報システム・モデル取引・契約書~ 情報サービスソフトウェア産業における下請適正取引等の推進のためのガイドライン ADR(裁判外紛争解決手続) 情報システムにおける価値の可視化 「IT投資価値評価に関する調査研究」(試行版) 情報サービス・ソフトウェアを巡る取引構造・産業構造の不透明性が、ベンダ間、ユーザ・ベンダ間、ユーザ内に存在しております。 また、不透明な取引構造・産業構造は、ベンダの産業構造転換の遅れ、情報システムの信頼性問題の温存、ユーザ・ベンダ一体となった生産性向上の阻害の要因となっています。 このため、各局面の取引構造を透明化するツールを整備し、これらを普及することで、ベンダの産業構造転換、情報システム信

  • システムを作るとはどういう事なのか?  ~人の感性は十人十色~ - plumauto892のブログ


     http://anond.hatelabo.jp/20131003212934   使 13502200  ±30 
    システムを作るとはどういう事なのか?  ~人の感性は十人十色~ - plumauto892のブログ