タグ

開発に関するnamanyのブックマーク (12)

  • 16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ

    技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム(16年の歴史があります)の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、

    16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
  • 「落ち着け!」 | dotkuwaの日記 | スラド

    日記 ISO9000とかWBSとかの、Re:鳴かず飛ばずの原因(#2585190)で、自分は、 >「先の見えない」場面でも10やれば1は当たるのが普通で(出来ないなら >エスカレーションするしかないですが) と書きましたが、どうもその辺の事が、生え抜きの(PG実務を経ていない)SEさんに とって理解し難い事のように見え、「プログラム設計書」を書かず、いきなりコーディング に入ろうとすると、 ・初心者のSEさんは決まって、プログラマーの手を止めさせ、「落ち着け!」と言い、 ・経験を積んだSEさんは、どうもそういう場面で手を止めさせる事は、実情に合わないと、 経験上体得はしているけれど、納得している人は見た事が無い。 事になります。 しかしながら、 『基設計から、すぐプログラムに入り、詳細設計をきちんと文書化出来るのはその後だ。』 と自分が主張出来るのも、“基設計から即コーディング”と言う

  • なぜ、詳細設計の表現は「後知恵としてなら存在する」と思ったか | dotkuwaの日記 | スラド

    日記「V字モデル」のコメント#2585095で、 #(自分では、「詳細設計」の表現は設計としては(プログラムの上位の存在として #は)原理的に存在し得ない、後知恵としてなら存在すると思っています。) と書きました。 詳細設計         単体テスト |        | プログラミング で無く、 プログラミング      単体テスト |        | 詳細設計 で有るべきだと言う事です。 なぜそう思ったかを書きます。 --------------------------------------------------------------------- 日記「ISO9000とかWBSとか」で、 たぶん、それらの管理対象は、 ・プログラムなんかと違って、安定していて、 ・そのくせ、きちんとトレサビ出来るだけの細かさもある “詳細設計の項目”を想定してるのだと思います。 と書きました

  • QMS試験受けました | dotkuwaの日記 | スラド

    会社でQMSの試験(pdf数十ページのハンドブックを見ながら、問題に答える)を受けました。 ISO 9001に準拠した内容だそうですが、せっかくISO 9001:2008の内容も反映し、"Output Matters" も踏まえ、レビューの順序などに柔軟性を持たせても良いという記述が有る一方、承認(必須)が からみ出すと途端に、 ・プログラマがプログラム設計書(謎)を作る ・責任者とプログラマがレビューを行い、責任者が承認する ・それに従いプログラムを作る と言った、ISO 9001:2000から一歩も進歩していない内容になります。レビューし、承認を得られる 「プログラム設計書」とは一体なんでしょうか? 見当も付きません。しかも、このプロセスは必須で、 これを省いたらISO 9001とは間違いなく関係なくなります。 まぁ、ISO 9001も"Output Matters(ISO 9001が

  • ISO9000とかWBSとか | dotkuwaの日記 | スラド

    ISO9000とかWBSとかは、自分ではやった事は無いですが、同じ会社のエース級の人が それこそ傍目に見ても脳漿を絞っているという感じでやっていました。 しかし、なぜか鳴かず飛ばずなんですよね。 たぶん、それらの管理対象は、 ・プログラムなんかと違って、安定していて、 ・そのくせ、きちんとトレサビ出来るだけの細かさもある “詳細設計の項目”を想定してるのだと思います。 少なくとも、プログラム自体を管理対象としている訳で無いのは事実です。 しかし、もし、詳細設計というのが「仮説の段階(握った手を見せて有るのだと 力説する人はいても、だれも手を開いて見せてくれない。そんなのが有って、 公開すれば、少なくとも1兆円は調達できて少なくとも1割は自分のものに出来る でしょうに、だれも見せてくれない。アカデミアの常道?)」だったとしたら、 鳴かず飛ばずも理解できます。 実際にあるかどうか解らず、少なく

  • V字モデル | dotkuwaの日記 | スラド

    よくソフトウェア開発の基的モデルとして、V字モデルとか有って、大まかに言うと 要件定義                  受入テスト |                          | 基設計                  結合テスト |                      | 詳細設計                  単体テスト |                  | プログラミング だが、実際は 要件定義                  受入テスト |                          | 基設計                  結合テスト |                      | プログラミング            単体テスト |                  | 詳細設計 が正解なのではないか? それは、 ・要件定義は現実

  • オフショア開発の要点とインド出張で感じたこと - OPTPiX Labs Blog

    ウェブテクノロジ代表の小高です。 先日、インドに出張してきました。オフショア開発を併用する取引先のプロジェクトに当社が参画することになり、その推進のため当社メンバーと一緒にオフショア先を訪問してきました。 ところで、オフショアと聞いて多くの方が頭に浮かぶことがありますよね。Googleで「インド オフショア」と入力すると…。「失敗」「問題点」というサジェストが現れるくらい、オフショアでのトラブルは良く耳にします。 インドに限らず、オフショア開発をスムーズに進めるためにはノウハウが必要で、阿吽の呼吸が通じる(こともある)日の開発会社と同じように発注してもうまくいきません。 この記事では、前職でオフショア開発の経験を積んできたメンバーの知見とあわせ、今回の出張を通して感じたことをまとめてみました。 プロジェクトの背景 今回、当社が開発に参画した半導体製造装置の制御ソフトウェア開発プロジェクト

    オフショア開発の要点とインド出張で感じたこと - OPTPiX Labs Blog
  • 自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)
  • プログラミングにかかる時間、正確に見積もるには? | スラド

    ストーリー by makeplex 2010年02月10日 23時47分 1人月と1人月を合わせて2人月!!いつもより2倍残業して4人月、そして休日出勤をすれば4人月*3、これが工数を上回る12人月だーっ! 部門より オラクルのシニアソフトウエアエンジニアであるSuvro Upadhyaya氏が、プログラミング時間の見積もりに関するブログエントリをIT worldに寄せている。同氏の経験では、スクラムが一つの有効な手法であるという。しかし、しっかりした開発チームであっても正確な見積もりを出せるようになるまで6カ月ほどかかることもあるそうだ。 Upadhyaya氏曰くプログラミングにかかる時間を正確に見積もることは、限界を明確化するプロセスであるとのこと。プログラマーの経験や知識、スピードと質の兼ね合いなどさまざまな要素が関わっており、チームや組織のカルチャーに依るところも非常に大きいという

  • ソフトウェアエンジニアのためのホームページ Presented by System Creates Inc.

  • プロジェクトマネジメントスキル 実践養成講座

    エンジニアとしてキャリアアップを考える際、ぜひ身に付けておきたいのがプロジェクトマネジメント(PM)のスキルだ。特に近年のシステム開発プロジェクトは低予算化・短期化が進んでおり、ただでさえ計画どおりにプロジェクトを運営することは困難になっている。こうした中、多くの現場で「経験のあるプロジェクトマネージャが不足している」という声を聞く。 しかし、PMスキルを実際に習得するとなると、これがなかなか難しい。ちまたにはPMBOK(Project Management Body Of Knowledge)をはじめとするPM関連のがあふれ、体系的に学習できる素材はそろってきた。しかし、実践的なものは少なく、理論と現場のギャップに戸惑うことも多々あろう。 そこで、この連載では実際の現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所をケーススタディ形式で紹介していく。これからプロジェ

    プロジェクトマネジメントスキル 実践養成講座
  • マイクロソフト - PressPass ホーム - 製品画像ダウンロード

    すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画テレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W

  • 1