Figma（フィグマ）とは？初心者でも分かるWebデザインツールの使い方
UIデザインやワイヤーフレームの作成に便利なデザインツールがほしいと思ったことはありませんか？Adobe XDやSketchなどがメジャーなところですが、他にもインターフェースがわかりやすく、操作性と利便性の高いツールがいくつかあります。 今回紹介する「Figma（フィグマ）」は、それらに引けを取らず、さらに便利な機能も備えたツールです。Figmaがどのように役立つものなのか、使い方を初心者にもわかりやすいようにシンプルにまとめました。 ▼ディレクターとデザイナーで読みたい資料 マーケ思考のデザイナーは強い！ 提案型デザイナーのススメ リード獲得が重視される「広告・LP・サービスサイト」などに携わるデザイナーの皆様に向けての資料です。成果を出すデザインにするために心がけたいポイントを制作前、制作中、提出と修正、公開後の効果検証まで一連の流れに沿ってまとめています。 Figma（フィグマ）と
時間がない時のテスト項目書の作り方 - Qiita
開発期間が短いプロジェクトでも、しっかり試験を行うには プログラムの品質を高めるには、試験工程でどれだけ良いテストを行ったかも鍵になります。 試験工程で良いテストを行うには、良いテスト項目書が必要です。 開発期間の短いプロジェクトでは、試験工程になかなか時間を割けないものですが それでも、短い時間で良いテスト項目書を作成する方法を……まずは自分のやってきたことを以下に纏めてみます。 時間がない時にまずやること 以下の作業を通し、テスト対象となるシステムを理解します。 要件定義を機能ごとに理解する 業務フローを、要件定義を意識しながら理解する 設計書を、要件定義・業務フローを意識しながら理解する 画面項目を、要件定義・業務フロー・設計書を意識しながら理解する DB項目を、要件定義・業務フロー・設計書・画面定義を意識しながら理解する 2.の業務フローの理解の時点で要件定義と合わない箇所を見つけ
若手プログラマー保存版！フローチャート徹底解説と作成カンニングペーパー
フローチャートを書く能力はプログラマーにとって必須スキルであり、優秀なプログラマーになるための第一歩です。なぜなら、フローチャートの有無、もしくはフローチャートの内容次第で出来上がるプログラムの品質に大きな差が出るためです。だからこそ、若手プログラマーやSE教育の場で必ず登場するのです。 しかし、フローチャートというテーマは、それだけで書籍１冊になるほどの分野であり、多忙なIT業界においていかに効率的に学習するか悩んでいる方も多いと思います。 プログラマーとしてスキルを高めたいが… 実はそもそもフローチャートのことをよく理解していない 最低限の知識で良質なフローチャートを作りたい フローチャートを書くことに自信がないが、今さら人には聞きづらい このようなことをお思いではないですか？このような悩みから解放頂けるよう、最短ルートで良質なフローチャートを書くための方法を１ページにまとめました。
単体テスト≠ユニットテストなんだという事 - modest violet
近年のソフトウェア開発では単体テストの自動化が当たり前になってきています。 「いや、とっくに当たり前だよ！」というお言葉も多いと思いますが、現実的にまだまだ取り入れていない企業も多いのです。現に僕自身も取り入れていなかった1人な訳でして。 簡単そうな問題なのですが、意外と商慣習的な問題が根強く絡んでいる気がしてなりません。 ソレは納品資料になるの？ ソフトウェアを納品する際には納品物としてソフトウェアの他に分厚〜い資料を渡します。その資料の中に単体テスト仕様書兼報告書といった資料がある場合があります。もしかすると単体テストは社内だけで留めておいて、その後の結合テストや総合テストから収めているというケースもあります。今回は単体テスト仕様書も納品物として収めているケースとして予めご理解ください。 さて、資料に報告書と冠しているのは『キチンとテストしてますよ！』という証拠を提示する為です。じゃあ
超上流から攻めるIT化の事例集：要件定義 | アーカイブ | IPA 独立行政法人 情報処理推進機構
・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら
バグが激減？ 手間が倍増？ Wモデル導入成否の分かれ道 ―― ソフトウェアテストシンポジウム 2012東京（JaSST'12 Tokyo）（2）
バグが激減？ 手間が倍増？ Wモデル導入成否の分かれ道 ―― ソフトウェアテストシンポジウム 2012東京（JaSST'12 Tokyo）（2） 酒井 郁子 ここでは，2012年1月25日～26日に開催された「ソフトウェアテストシンポジウム 2012東京（JaSST'12 Tokyo）」において，筆者が特に興味深く感じたセッション「Wモデルで品質向上」についてレポートする． Wモデルとは，開発プロセスの「V字モデル」を2重化したモデルを指し，ソフトウェアのテストだけでなく，開発全体の改善を図る考え方として期待されている．Wモデルという言葉そのものは，筆者も何年か前から技術記事などで目にしている．しかし，実際にWモデルに基づいて取り組んだソフトウェア開発の結果報告や，Wモデルを採用した組織の具体的な改善事例などを目にすることは少ない．そういったこともあってか，本セッションには約300名の聴講
分類と分解をUMLで表現する
汎化関係 【汎化と特化】 「第3回 複雑なものを単純に～分類と分解～」（注1）で説明したクラスの階層をUMLで表現すると、汎化関係という特殊な関係になります。図1は、UMLで表現した汎化のイメージです。スーパークラス側を白抜き三角にして、線でサブクラスとつなぐという決まった表記があります。 サブクラスからスーパークラスに、より一般化することを汎化（generalization）、逆にスーパークラスからサブクラスに、より特殊化することを特化（specialization）と呼びます。スーパークラスを親、サブクラスを子、3階層以上の場合はそれぞれ祖先、子孫と呼ぶこともあります。 第3回の図1「クラス階層－乗り物の分類」をUMLで表すと図2のようになります。汎化は何階層でも描くことができます。
○×△（まる ばつ さんかく）英語でもそのまま使っていませんか？ | SDNA ローカライズチームブログ
○×△（まる ばつ さんかく）記号は日本では評価や製品のサポート情報など、いろいろな用途で使用されているのを目にします。一般的に○は良い、×はダメ、△はその中間といった意味で使用されていることが多いですが、海外ではそれぞれの記号が国や地域によって意味が異なる、わからない、場合によっては反対の意味になることがあります。 あるゲーム機ではアジア仕向けと欧米仕向けで〇（決定）ボタンと×（キャンセル）ボタンは逆の機能になっていたりします。 アメリカ人のSDNA ネイティブチェック担当者はこれらの記号について以下のように述べています。 〇（circle）:「オフ」を意味する。電気機器では電源スイッチに「オン」の位置を示す縦棒（アルファベットのIのような）と「オフ」の位置を示す○がよく使用されている。○は一般的に“empty”、または否定的な状況を示すことが多い。 ×（ex）: “X“は“do not
英語で過剰書きする際の動詞の形
No. 4です。ちょっと修正を… いろいろご意見が出てますので（No. 5の方とは異なる意見になります）お困りかも知れませんね。加えて修正までされるとややこしくなると思いますが、ご質問を再読したところ、「～ということ」という目的のいくつかを箇条書きにされたいということではないようですね。 そこで、箇条書きの一般論で言いますと、各箇条は動詞、準動詞、名詞で始めるようなっています。各箇条共に開始のスタイルを合わせます。動詞は命令文のように原形で、準動詞はto不定詞が使われることが多いようです。 また、文章を箇条書き形式で書き直したような形というのは、本来の箇条書きではありません。例えば： A. This machine will ensure low running costs, reduce production time and improve product quality. ということ
「【改訂版】初歩のUML」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
【改訂版】初歩のUML： 第5回 少しだけ高度なモデリング技術（その2）クラスの依存関係と実現関係 今回も「第4回 少しだけ高度なモデリング技術（その1）」に引き続き、高度なモデリングの考え方についてクラス図を取り上げて説明していきます。今回取り上げるのはクラスの依存関係と実現関係です。（2012/10/1） 【改訂版】初歩のUML（13）： UMLモデリングのノウハウ、最後の秘訣（UMLモデリングの開発過程 開発編その2） （2004/1/10） 【改訂版】初歩のUML（12）： UMLモデリングの開発過程 開発編 （2003/12/20） 【改訂版】初歩のUML： 第11回 UMLモデリングの開発過程（ビジネスモデリング編） （2003/11/15） 【改訂版】初歩のUML： 第10回 開発プロセスの上手な組み合わせ （2003/10/8） 【改訂版】初歩のUML： 第9回 UMLベー
[ThinkIT] 第2回：ERの基礎知識とツールの活用法 (1/3)
前回からデータモデリング全体の利用法が理解できたかと思います。今回はデータモデリングの中身の話に入り、ERの基礎知識とツールの活用方法について解説します。データ中心設計（DOA）の基礎となるERについて、ぜひマスターしてください。 ERの醍醐味はリレーションです。リレーションの線がなければERはただの箱（エンティティ）の羅列で、無味乾燥したものになります。エンティティとエンティティの関係が一目であらわされることがER図の意義なのです。 ERのリレーションには依存型と非依存型があります。親エンティティがなければ子エンティティが存在できないものが依存型リレーション、親がなくとも子が独立して存在できるものが非依存型リレーションです。 図1はSQL ServerのサンプルデータベースNorthwindをリバースしたER図の一部です。 「受注」と「受注明細」の関係は、依存／非依存のどちらでしょうか。
ER図の目的とは？ 初心者向けに書き方を教えます
ER図（Entity Relationship Diagram） ER図とは、データベースのテーブル（Entity）とテーブル同士の関連（Relationship）を図に表したものであり、データベースのテーブル設計に用いられる。ER図において、エンティティは四角形の記号、リレーションは四角形同士を結ぶ線で表現される。 書き方 ER図の書き方は、エンティティとリレーションを記号で表して書く。ER図の書き方には、以下に示す２種類がある。 IDEF1X記法 IE記法 エンティティ 論理モデルのER図の場合、エンティティ（実体）は業務におけるひとまとまりのデータを表している。物理モデルのER図の場合、エンティティはデータベースのテーブルを表す。 エンティティには2種類あり、非依存実体と依存実体に分けられる。 非依存実体 非依存実体とは、他のエンティティに依存せずに存在できるエンティティである。例え
EXCELのカギ型コネクタでER図を描く － その１
つい先日、仕事でER図を書いた。何十カラムもある大きなテーブルがいくつもあって、しかもExcelで書いて欲しいという条件付き。早速ググってみたのだが、皆さん苦労しておられる様子だ。特にカギ型コネクタ(笑)。 せっかくなので、カギ型コネクタの使い方について、僕のやり方をご紹介してみる。 なお、この記事はあくまでコネクタの使い方のヒントなので、ER図の表記法について知りたい方はもっと詳しいサイトがあると思うので、そちらを参考にされたほうがいいと思う。当然リバースエンジニアリングができるわけでもないし、そのような向きにはそれ用のツールがいろいろと出てるし、Microsoft製品ならVisioなんかは相当便利だ。 しかし、ER図をExcelで書くというメリットも全く無いわけでもないと思う。正式な表記法にこだわらずに色や、様々な修飾を施したり、Excelで書かれたテーブル定義書があれば、項目を計算式
ObjectClub - アジャイル勘違い集
やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。 アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。 アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
第23回「要件定義（システム要件）」｜株式会社エグザート
インターネットビジネスの本格的参入 第23回「要件定義（システム要件）」 これまでに３回にわたり要件定義について書いていますが、本メールマガジンはユーザ側の視点から書いていますから、システム側の方には十分な情報ではありませんのでご注意ください。 ────────────────────────────── □ 要件定義で定義すること（システム要件） ────────────────────────────── ５．システム要件 システム要件については、業務要件に基づいてシステム開発の委託先がリードしてくれるべきものです。 システムに明るい方であれば自分で定義することもできるかもしれませんが、コンピュータシステムは新しい技術への変化が激しい分野ですので、やはり、その道のプロに任せることが懸命です。 ゆえに本メルマガにおいて、詳細は書きませんが、どんなことを定義するのかということを例を挙げて簡
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕事を「見える化」する 業務フローのかんたんな作り方【エクセルテンプレート付き】 | 小さな会社のための DIYシステム工房
http://randy.22web.org/classes/cop2000/sel_case.html
ERD