タグ

ソフトウェアと開発に関するmcqのブックマーク (11)

  • ソフトウェア開発プロセス残酷物語 - give IT a try

    昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや人が直接手を動かすことはありませ

  • 2017年のCI/CDの動向 | gihyo.jp

    あけましておめでとうございます。ソフトウェア開発をめぐる環境は相変わらず日進月歩です。この変化に伴って、ソフトウェア開発そのもののあり方も変化を続けています。稿では、少し大きな視点から継続的インテグレーション(CI⁠)⁠・継続的デリバリ(CD)の最近の動向を紹介します。 CI/CDの大きなうねり 筆者がJenkinsに携わって12年になります。かつて、CI/CDの取り組みは、現在の機械学習やスケールアウト技術のような将来の可能性が注目される若い技術でした。ここ数年、この若い技術は、広く産業界で大規模に組織がかりで展開される成熟した技術に変貌してきました。 この背景にあるのは、ソフトウェア開発・運用全般における自動化のさらなる浸透です。このような自動化の進展は2つの側面から考えることができます。一つは、ソフトウェア開発に必要な様々な作業それぞれの「部品の自動化」という側面です。もう一つは、

    2017年のCI/CDの動向 | gihyo.jp
  • マイクロにしすぎた結果がこれだよ!

    This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

    マイクロにしすぎた結果がこれだよ!
  • アジャイルな開発には安全性が不可欠 : 現実世界の安全機構との3つのアナロジー | POSTD

    (2016/7/15、著者プロフィールを修正いたしました。) 仮に、高速道路の自動車をより速く走らせることがあなたの務めだとします。もしあなたが、ドライバー全員にただ「アクセルを思いきり踏むように」と言ったら、一体どうなるでしょうか? 結果は明らかに、大惨事となるでしょう。それなのに、ソフトウェアの構築を速めようとする時に、多くの開発者がまさにそんな態度を取っているのです。その理由として持ち出されるのは、以下のようなことです。 「当にアジャイルに進めたいので、デザインやドキュメントには時間をかけられない」 「これは番環境にすぐ反映しなきゃいけないから、テストを書く時間はない」 「何もかも自動化する時間はなかったので、コードのデプロイは手作業でやる」 自動車が高速道路を高速で走るには、安全性が欠かせません。より速く走るためには、ブレーキやシートベルト、エアバッグといった、いざという時にド

    アジャイルな開発には安全性が不可欠 : 現実世界の安全機構との3つのアナロジー | POSTD
  • 要件が確定しなかったことにつきベンダに責任がないとされた事例 東京地判平22.7.22(平20ワ16510号) - IT・システム判例メモ

    ユーザがベンダに対し,ベンダが一方的に開発契約を解除したとして,損害賠償を求めたが棄却された事例。 事案の概要 ユーザXは,ベンダYに対し,平成14年9月18日に,Xの人材派遣業務に必要なシステムとして2つのシステムの開発を委託した(契約金額の合計は840万円)。 その後,Yは,9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが,Xは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに,下請業者が交替するなどして,翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが,Xは,やはり記名捺印を拒絶し,確定しなかった。その後もYからはドキュメントが提出されているが,Xはやはり拒絶した。Yは,Xに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局,平成16年9月になっ

    要件が確定しなかったことにつきベンダに責任がないとされた事例 東京地判平22.7.22(平20ワ16510号) - IT・システム判例メモ
  • NTTデータ、既存システムのソースコードをもとに設計書を再生するサービス

  • 継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)

    Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境

    継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
  • きっと何者にも成れないモジュールたちに告げる~静的解析、しましょうか~ - mixi engineer blog

    たんぽぽグループのhirokiです。たんぽぽグループとはmixi内の「刺身にたんぽぽをのせる仕事をなくす」ことを目的とした技術者集団です。 「あれは、たんぽぽではない用菊である」 「スーパーの生鮮品バックヤードが片手間にやってるよ。」 というご批判・ご指摘をうけ、今後は「道路に片方だけの軍手を落とす仕事をなくす」ことを目的としていこうかなどの検討を重ねました結果、「細けぇこたぁいいんだよ。」という結論に至ったことをこの場を借りてご報告させていただきます。今後ともたんぽぽグループを御ひいきによろしくお願いいたします。 と、ご報告をさせていただいたところで、題にはいります。 YAPC::Asia Tokyo 2011 先日Perlのお祭りことYAPC::Asia Tokyo 2011においてLTをさせていただきました。その資料のご紹介とちょっとした解説をさせていただきます。 静的解析、し

    きっと何者にも成れないモジュールたちに告げる~静的解析、しましょうか~ - mixi engineer blog
  • 一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス

    石橋秀仁 Hideto Ishibashi @zerobase 先日某社のIT担当者と話して着々とベンダー(SIer)外しが進んでいる実態を知った。新規案件はどんどんAmazon EC2に構築し、委託先もウェブ系の制作会社やソフトハウス。それに対応できない大手ベンダーの「ジレンマ」。まあ対応せず潰れてください。社会のために。 2011-02-05 15:45:49

    一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス
  • 受託開発が抱える本質的な非効率性に関する考察 - GeekFactory

    受託開発が抱える質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会(=教育)が十分にないため、極めて非効率な学習にならざるを得ない。

    受託開発が抱える本質的な非効率性に関する考察 - GeekFactory
  • 400万行のコードを15分で見える化! プログラム解析ツール『Understand』で開発効率アップ

    システムの多機能化により、プログラムの内容が複雑化している。テクマトリックスの『Understand』は、プログラムの構造を可視化することで、ソースコードの解析時間を大幅に削減できる開発支援ツール。今回は同社の福永一寛氏に、Understandの機能や特徴について聞いた。 システムの多機能化により、プログラムの内容は複雑化している。既存コードの改修や多人数での開発における情報共有のためには、プログラム構造の理解が必須だが、ドキュメントと実装内容とが乖離している場合も多く、解析自体に工数がかかることもある。テクマトリックスの『Understand』は、プログラムの構造を可視化することで効率的なソフトウェア開発をサポートするソフトウェア開発環境。「組込みシステム開発技術展(ESEC)」にて、同社の福永一寛氏にその特徴を聞いた。 ソースコードの解析作業時間を大幅に削減する『Understand』

    400万行のコードを15分で見える化! プログラム解析ツール『Understand』で開発効率アップ
  • 1