組み込みソフトウェア／ハードウェア開発における技術力の向上、改善・最適化などを幅広く支援する“組み込み開発エキスパート”のための情報フォーラム
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
組み込みソフトウェア／ハードウェア開発における技術力の向上、改善・最適化などを幅広く支援する“組み込み開発エキスパート”のための情報フォーラム
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
alternative dvamp project 個人主義vsチームワーク
今まで、Agile、TOC-CCPMといった様々なチームを前提とするプロセスカイゼンをしてきた。 運良く、Agile、TOC-CCPM共に良い結果も出してきた。 しかし、役員からの評価は良いものの、プロジェクト管理者や上司からの評価が悪い。 どうしてダメなのか説明もない為、つい最近まで「きっと自分の説明力が足りず、その為に誤解されているのだろう」「きっとわざわざプロセスを変革する必要があると判断出来る程の成果が出ていない為に、評価されていないのだろう」と考えていた。 だがしかし、それが全く別だという事が先日分かった。自分は「個人個人では解決出来ない問題も皆で協力すれば解決出来る！」というチームワークを重視したプロジェクトマネジメントを行うことで、プロジェクトを成功に導く方法が、技術が日進月歩する今の時代に適していると考えている。 だがしかし、プロジェクト管理者や上司の考え方は「一人一人が自
高信頼化ソフトウェアのための開発手法ガイドブック－予防と検証の事例を中心に－：IPA 独立行政法人 情報処理推進機構
2011年6月6日改訂 2010年9月15日公開 独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター 概要 1 背景と目的 ITの進展により情報システムは、利用範囲が広がり一般国民の生活に直結する重要な社会インフラを支える存在となっています。インフラは「産業構造ビジョン2010」においても重要な世界戦略商品であり、そのインフラを構成する部品のひとつとして情報システムは、高い信頼性・安全性を要求されています。他方、企業の業務の一端を担う情報システムでも、企業活動に重大な被害を与える計画外なシステム停止が存在します。これらのシステムも社会インフラの構成要素と同様に高い信頼性・安全性を要求します。 このような状況下で、情報システムの重要な構成要素であるソフトウェアは、開発量の増大と機能の複雑化、さらにコスト削減と開発期間の短縮などの要求とともに、信頼性・安全性への対応課題が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
