Agile to Lean Software Development Transformation

公開されている

「Agile to Lean Software Development Transformation」のキモ部分です。

間違っていたら、ごめんなさい。

 

0.概要

アジャイルをスケールアップする方法として、リーン開発が提唱されている。

この論文の目的は、アジャイルをリーン開発へ変更することについて

（１）そのメリット（２）変更点（３）変更を測定するメトリクス

を明らかにすること。

その方法として、　Systematic Literature Review(SLR)を利用した。

結果、主なメリットとしては、次があった

（１）時間の削減　（２）フローの改善　（３）継続的な改善（４）欠陥のFIX率の改善

主な変更点としては、次があった

（１）マインドセットを変えること　（２）無駄の削減のコンセプトの理解　（３）スケールのフレキシビリティ

利用されるメトリクスとしては、（１）リードタイム　が最も使われていた

１．はじめに

リーンソフトウェア開発は、開発プロセスを最適化するために、ムダを削減するものである。

この論文の目的は、アジャイルからリーンへの変更に関して、そのメリット、変更点、利用されるメトリクスを明らかにすること。

２．SLR

Systematic Literature Reviewは、文献をシステマティックな方法でまとめるもの。

A.Needs for an SLR


 アジャイルからリーンへの変更に関しての研究は、ウォーターフォールから、アジャイルへの変更に関しての研究に比較して、少ない。

B.リサーチクエスチョン

RQ1　アジャイルにリーンの原則を組み込むことで、どんなメリットがあるか

RQ2　アジャイルにリーンの原則を組み込むことで、どんな変更があるか

RQ3　アジャイルにリーンへ変更することに関して測定するメトリクスは

C.Search strategy & Study selection

省略

D. Study quality assessment criteria

対象の18の論文に関して、目的に合っているかを確認するために、次の調査を行った。

c1. アジャイルが変更前の状態か

c2.実際に、リーンソフトウェア開発のプラクティスを採用したか

c3.変更のメトリクスがあるか

3.SLA Result

A.benefit (RQ1)

レポートされているbenefitを分析した

(1)リードタイムの短縮

もっとも多く報告されているbenefitであった

(2)フローの改善

(3)継続的な改善


B.challenges(RQ2)

アジャイルから、リーンへの変更には、いろいろなことが必要となる。プロセスの可視化、持続性のマネジメント、チーム間のコミュニケーションが、よく見られるものである。

テストプロセスの変更もよく重要な変更と言われる。それは、ソフトウェアの欠陥に関して、真の原因を見つけるものである。

アジャイルからリーンへの変更のキモとして、ムダの最小化と品質の改善がある。

C.メトリクス(RQ3)

(1)リードタイム

(2)欠陥数

単位時間当たりの欠陥など

(3)欠陥の修正時間

(4)Velocity

Velocityは、タスクの完了に必要と予測した時間を、実際にかかった時間で、割ったものである。

(5)Line of code

(6)イテレーション事のストーリー数

(7)リリースの頻度

4.結論

概要と同じ

アルゴリズムの考え方

総当たりアルゴリズム

すべての場合をためし、解を求める。

近似アルゴリズム

 ・正解に近い解を探す

・正解との誤差がある範囲におさまると保証されているものを

　精度保証付アルゴリズムという。

・精度の保証のないアルゴリズムを、発見的手法(ヒューリスティック)
　
　という。

Webエンジニアリング

WEBアプリケーションの仕様化と分析

 

仕様化とは、次の問いに答えること

・Webアプリケーションが必要となる主要なモチベーションは、何か？

・誰が、Webアプリケーションを必要としているか？

・誰が、Webアプリケーションを使うか？

これを基に、目標を設定する

目標には、次が含まれる

・どんな情報やコンテンツを提供するか

・Web App で何ができるのか

分析は、要件を定義するものであるが、Web特融の点としては、以下がある

1．コンテンツの分析

　Webアプリケーションで提供するコンテンツを特定する
　
　データモデリング手法も利用できる

2．インタラクション分析

　ユーザとのかかわり合いを分析する

　ユースケースを利用できる

3.機能分析

　　ユースケースシナリオを作り、オペレーションや機能を特定する

4.コンフィグレーション分析

　Webアプリケーションの環境やインフラを定義する

Webアプリケーションの設計

 

アーキテクチャ・デザイン

 

　Webベースのシステムのアーキテクチャデザインは、Webのコンテンツの構造を定義する

 

ナビゲーションのデザイン

異なるロールのユーザに対して、アクセスできるコンテンツが異なる場合がある

その時、個々のロールに応じたナビゲーションを決定する必要がある

また、ナビゲーションの手段として、テキストベースのリンク、アイコン、ボタン、画像等から適切なものを選択する

また、ボタンが押せる、押せないを、ボタンの形状で変える、テキストベースのリンクの色で変更する等からも選択する

これ以外にも、サイトマップの利用、インデックス、サーチエンジン、helpの利用等を考慮する必要がある

 

インターフェースのデザイン

インターフェースのデザインに関していは、次のようなものがある

・サーバエラーを、利用者に見せない

・レスポンスを保つため、テキストや画像の両をしぼる

・スクロールを少なくする

・メニュー、ナビゲーション、ヘッダー、フッターは、統一し、すべてのページで利用可能とする

・意図が伝わらないアイコン、画像等はさける

ストレージの種類

ブロックストレージ

ブロック単位でアクセス。FCやiSCSIなどのプロトコルが使われる。

ファイルストレージ

ファイル単位でアクセス。NFSやNASなど。

オブジェクトストレージ

オブジェクト単位でアクセス。RESTでのAPIアクセスなど。

アルゴリズム「エラトステネスのふるい」の例

 たとえば、100までの素数を求める場合、以下のアルゴリズムとなる。

(1) 100個の配列を用意する。

(2) すべて配列の値を、1とする。

(3) 2の倍数番目の配列の値を、0とする。

(4) 3の倍数番目の配列の値を、0とする。

(5) 4は、すでに、0なので、次に進む。

(6) 5の倍数番目の配列の値を、0とする。

これを、100の平方根まで繰り返す。

[データ構造]グラフの種類

無向グラフ

エッジに方向がなく、エッジで結ばれたノードは、双方向の関係がある。

有向グラフ

エッジに方向があり、エッジで結ばれたノード間には、意味のある関係がある。


(親子関係など)

非連結グラフ

エッジで結ばれていないノードが、1つ以上ある。

非巡回グラフ

循環を含まないグラフ。

完全グラフ

すべてのノードが他のすべてのノードとエッジでつながる。

重み付きグラフ

ノード間のエッジが重み付けられたグラフ。

論文 Software Application Security Test Strategy with Lean Canvas Design

公開されている論文

Software Application Security Test Strategy with Lean Canvas Design

のキモ部分です。

1.概要

この論文は、ソフトウェアのセキュリティテスト計画に対して

リーンキャンパスデザインが、利用できるかを検証するもの


2.問題

セキュリティの品質を保持するチームは、多くの問題に直面する

・セキュリティテスト戦略の不足

・セキュリティテストが早期に開始できない

・セキュリティテストに精通した要因がいない

・適切なツールがない

・適切なテスト計画やテストデータがない


3.SDLCにおけるセキュリティテストとリーンキャンパスデザイン

SDLCにおけるセキュリティテストは、以下のように扱われる

(1)要件定義

セキュリティ要件や、誤利用などのテストケースを分析する。

(2)設計

システムのリスク分析を行う

(3)コーディングとユニットテスト

認証・認可、暗号化、入力の検証やエンコーディング

ユーザセッションの管理、エラーと例外ハンドリング、

監査とロギングなどの実装とテスト

(4)総合テスト

ブラックボックスでのテスト

(5)システムテスト

SQLインジェクションなどのホワイトボックステスト

(6)稼働

脆弱性のSCANや、ペネトレーションテスト

(7)サポート

ソフトウェアのパッチ、アップデート


4.アジャイルとセキュリティテストの関連

(1)新しいイテレーションの開始

セキュリティ要求の収集

(2)ユーザーストーリー

セキュリティアーキテクチャのレビュ

(3)ユーザーストーリーの実装

アプリケーションの脆弱性の検査

(4)Deploy

外部のセキュリティテスト


5.セキュリティアーキテクチャの概要

(1)要求

・ユーザーストーリー

・アーキテクチャやシステムコンポーネントのリスク分析

・セキュリティ要求の詳細化

(2)設計

・リスク分析

・脅威モデル

(3)コーディング

コードのレビュ

(4)テスティング

ペネトレーションテストなど

(5)リリース

セキュリティポリシーの設定、セットアップ

(6)保守

オペレーションのセキュリティ

ソフトウェア開発での再利用の対象

 再利用の対象は、ソフトウェアの生産性や品質を上げるのに、重要な手段である。

一般的には、次のような再利用の対象が考えられる。

・アーキテクチャ

・ソースコード

・要求定義

・設計

・データ

・見積　

・画面

・プロジェクト計画

・テスト計画

・テストケース

・テストスクリプト

・ユーザ文書

・ユーザインターフェース

論文 Web Frameworks, Database and Web Stacks

 公開されている

「Web Frameworks, Database and Web Sacks」

のキモ部分を読んで勉強してみたいと思います。

概要

Webアプリケーション構築には、フロントエンド、バックエンドとも

多くのフレームワークがある。

適切なフロントエンド、バックエンド、データベースを選択することが必要である。

フレームワーク、データベース、OSの環境をWeb Stackと呼ぶ

Webアプリケーションを構築する技術やフレームワークは、数多い。

その1つにマイクロサービスベースのアーキテクチャがある。

マイクロサービスは、システムをサービスの集合体とすることで、

疎結合、高い保守性、独立したディプロイを提供しようとするもの。

サービス間は、APIでつながる。


フロントエンドは、ユーザインタフェースを提供し、

バックエンドは、ビジネスロジックを提供する。

この２つを独立させることで、迅速な開発、容易なアップグレード、高い保守性を実現できる

フロントエンドのフレームワーク

ユーザとのインタラクションを提供するコンポーネントをフロントエンドという。

フロントエンドに関するテーマは、パフォーマンスとレスポンシビリティ。

また、画面の大きさに合わせた出力等も必要になる。

1.AngularJS

SPAをつくるJavaScriptのフレームワーク。

HTMLを拡張してアプリケーションのコンポーネントを表現する。

2.ReactJS

効率的で多機能なユーザインタフェース向けのJavaScriptフレームワーク。

再利用可能な部品から複雑なUIを組み立てる。

ReactJSは、JSXを利用する。

JSXは、XMLのシンタックスにJavaScriptを加えたプリプロセッサである。

3.VueJS

Vueは、ユーザインタフェース、SPAを作るフレームワーク。

リアクティブやコンポーネントの利用に特徴がある。

バックエンドフレームワーク

バックエンドは、数多くの機能からなる。

たとえば、外部からの攻撃に対するAPIの保護、認証、データベースとの連携、

ユーザからのリクエストに応じた処理等である。

NodeJS

NodeJSは、非同期でイベントドリブンなJavaScriptのランタイムで、

スケーラブルなアプリケーションを構築することができる。

数多くのコネクションを同時に管理できる。

それぞれのコネクションは、コールバックがトリガーとなる。それ以外の時は、Sleepしている。

この動作は、他の多くのスレッドを利用する同期モデルとは異なる。

さらにNodeでは、lockを利用しないので、デットロックを心配する必要がない。

I/Oを発生させる機能が少ないため、プロセスがブロックされることはない。

これらの特質のため、Nodeは、スケーラブルなものとなっている。

Nodeは、オプティマズされたV8エンジンを利用している。

 

Django

Python用のWebフレームワーク。

高速に動作し、開発者が迅速に開発できるようになっている。

開発者がビジネスロジックの実装に集中できるようにしている。

Gjangoは、認証、サイトマップ、コンテンツ管理、RSS feedsなど、

多くの機能を支援している。

Djangoは、MVCアーキテクチャを採用している。

Modelは、ロジカルなデータ構造で、Webインターフェイスとデータベースの仲介を行う。

Viewは、ユーザインターフェイスのロジックを含む。

controllerは、modelからviewのデータのやり取りを行う。

Spring Boot

Spring bootは、巨大なモノリックなアプリケーションより、

マイクロサービスに適している。

Docker のコンテナにダイレクトにDeployできる。

サーバサイドのアプリケーション、REST API、イベント駆動型の処理を容易に作成できる。

また、health check(モニタリング)、メトリクスデータの提供などの機能もある。

SAMLやOAuth、LDAPなど業界標準の認証プロトコルをサポートする。

多くのリレーション、非リレーショナルのデータベース、クラウド・サービス、

MapReduceフレームワーク等に対応している。

データベース

リレーショナルデータベース(SQL)とノンリレーショナル(NoSQL)のデータベースの

選択がある。リレーショナルデータベースは、データが少ないOLTPに適している。

ノンリレーショナルデータベースは、非構造データを利用するときに好まれる。

PostgreSQL

PostgreSQLは、OLTPシステムに適している。また、分析用データベースにも適している。

高いスケーラビリティを持ち、Webシステムにも適している。

Django、Hibernate、NodeJSなどモダンなフレームワークと一緒に使われることが多い。

レプリケーションに優れており、多くのサーバが必要になる時などに利用される。

NoSQLスタイルでも利用できる。

MongoDB

ドキュメント指向のNoSQLのデータベースである。

コレクションとドキュメントと呼ばれる概念がある。

ドキュメントには、key-valueのペアが含まれ、こればリレーショナルデーターベースのレコードにあたる。

同じタイプのドキュメントの集合がコレクションである。

MongoDBは、レプリケーションの機能を利用して、スケーラビリティを実現する。

WEB STACK

webアプリケーション構築に必要なソフトウェアの集合である。

web stackには、OS、データベース、プログラミング言語、Webサーバが含まれる。


〇 LAMP/LEMP

Linux 、Apache/Nginx、MySQL、PHP

〇 MEAN/MERN/MEVN

MongoDB、ExpressJS/AngularJS/ReactJS/VueJS、NodeJS

〇 Spring STACK

[データ構造]線形リストの種類

単方向線形リスト

リストに保管するオブジェクトが、次のオブジェクトの位置が分かる。

(ポインターを持っている)

双方向線形リスト

次のオブジェクトではなく、前のオブジェクトの位置も持っている。

環状リスト

最後のオブジェクトが、最初のオブジェクトの位置も持っている。

クロニクル ユースケースシナリオ:初期画面表示を書いてみる

ユースケースシナリオの練習です。


1.ユースケース名

　初期画面表示

2.事前条件

　利用者がシステムへログインする

3.事後条件

　利用者へ応じた初期画面が表示される

4.正常系シナリオ
　
　(1)システムは、ログインした利用者の属性を取得する

　(2)システムは、(1)で取得した属性から、属性に応じた画面名を取得する

    (3)システムは、(2)で取得した画面を表示する

5.異常系シナリオ
　
　(1)正常系シナリオの(1)、(2)、(3)のいずれかで失敗した場合は、
　　システムはSorry画面を表示する

論文 Does Software Modernization Deliver What It Aimed for ?

論文

Does Software Modernization Deliver What It Aimed for ?

の概要です。

1.概要

ソフトウェアのモダニゼーションで、ビジネスの目的が達成されたかの研究は少ない。

5つのケーススタディからこれを分析する

2.はじめに

ソフトウェアのモダニゼーションは、主に保守性や柔軟性を高め、コストを削減するもの

3.関連研究

literature reviewでは、次のBenefitがあった

・コスト削減

・再利用性の向上

・アジリティの向上

・柔軟性の向上

・パフォーマンスの改善

・保守性の向上

・競争への追随

・可用性の向上

・市場投入のスピードアップ

・相互運用性の向上

4.Case Study

(1)ケース1

次の目的で、モダナイズされた

・ユーザビリティの向上

・一貫性の向上

・保守性の向上

意図しなかった効果

・組織内でのコミュニケーションの向上

(2)ケース2

次の目的で、モダナイズされた

・フレキシビリティの向上

・保守性の向上

・ユーザビリティの向上

意図しなかった効果

・メンテナスコストの低減


(3)ケース3

次の目的で、モダナイズされた

・保守コスト、運用コストの削減

・レガシーテクノロジーからの脱却

意図しなかった効果

・組織のフレキシビリティの向上


(4)ケース4

次の目的で、モダナイズされた

・運用コストの削減

・レガシーテクノロジーからの脱却

意図しなかった効果

・システムの高速化

・自動化の拡大

・セキュリティの向上


(5)ケース5

次の目的で、モダナイズされた

・運用コストの削減

・パフォーマンスの向上

・レガシーテクノロジーからの脱却

意図しなかった効果

・ベンダーロックインの回避

・柔軟性の確保

アルゴリズム設計の考え方

1.力ずく戦略

すべての方法を、しらみつぶしに試す


2.分割統治戦略

大きな問題を、小さな均質な問題に分割する


3.ダイナミック・プログラミング

分割された問題には、同じものが存在するのでこれを、何回も解くことを回避する


4.欲張り選択戦略

分割した服問題の1つを選び、他は破棄することで、効率を確保する

Comparative Study of MVC Architecture with respect to Struts Framework and PHP

 公開されている

Comparative Study of MVC Architecture 

with respect to Struts Framework and PHP

のキモ部分を読んで、Strutsを勉強してみたいと思います。

概要

Model、View、Controller(MVC)アーキテクチャは、主にミドルウェアで実装される。

MVCは、主にWebアプリケーションで利用される。

というのも、開発者が理解するのが容易だからである。

MVCアーキテクチャは、ビジネス層(Model Logic)、

表示層(View Logic)、コントロール層(Controller Logic)に分離するもの。

この研究は、StrutsとPHPを用いて、MVCの実装の差異について、

確認するもの。

MVCアーキテクチャは、複雑なアプリケーションに利用される。

Strutsを用いて、MVCを実装することは、容易である。

様々なIDEのサポートがあるためである。

PHPでは、Model、View、Controllerのフレームワークを

手動で作る必要がある。

イントロ

MVCは、大規模で複雑な問題のソリューションとして、

デザインされた。

最初は、Smalltalk-80のフレームワークとして利用された。

MVCは、理解が容易で、Webアプリケーションで利用される。

MVCは、データとコードの分離、複雑性の低減、

ビジネスロジックの統合を実現できる。

MVCアーキテクチャ

Model

モデルは、データを持つクラスで、getterやsetterを持つ。

データベースへの接続はなく、データベースから抽出されたデータを

マネジメントするだけである。

model クラスの主要な活動は、viewクラスからのリクエストへの応答、

controllerクラスからの指示への応答である。

View

Viewの主な責務は、クライアントからの指示に従って、

modelコンポーネントを適切に表示すること。

viewにも情報を持つ。modelからのレスポンスに応じて

アウトプットのための表現をつくる。

JSP、ASP、PHPなどのフォーマットでデータを表示する。

Controller

ユーザからのリクエストに応答するのが、Controllerである。

Controllerは、ユーザのインプットをViewから読み込み、

データをmodelに渡す。modelやviewの変更を起動する。

Controllerクラスは、viewやmodelクラスと関連する。

-- つづきます。--

[データ構造]木の種類

二本木

ルートノード、ノードの下のノード、リーフが2つ以下の木

全二本木

二本木の中で、全てのノードが2つの子ノードを持つ木

完全二本木

深さが同じ全二本木

平衡木

二本木にノードを追加する時、完全二本木に近づける。

ルートから葉ノードまでの深さが、ほぼ等しい二本木

変数のネーミングの方式

キャメル記法

1つ目の単語の頭文字は、小文字。

複数の単語を連結する場合には、２つ目以降の単語の頭文字を大文字にする。

例)　userName

パスカル記法

1つ目の単語の頭文字は、大文字。

複数の単語を連結する場合には、２つ目以降の単語の頭文字を大文字にする。

例)　UserName

アッパースネーク記法

すべての単語を大文字にして

複数の単語を連結する場合には、アンダースコアで連結する。

例) USER_NAME

A study of MVC - A software Design Pattern for Web

公開されている

A study of MVC - A software Design Pattern for Web

のキモの部分を読んで勉強してみたいと思います。


Model - View - Controllerのデザインパターンは、Javaの

Web開発用フレームワークで数多く採用されている。

これらの webフレームワークの欠点を分析する。

MVCは、動的なソフトウェアシステムを構築するためには、

有効である。Model、View、Controllerが独立性を保った

パターンを考える。

Model

データやアクティビティを表現する。データベースのテーブルを表したり、

コンピュータ上のプロセスを表す

View

モデルの表現

Controller 

モデルの状態の変化の管理


MVCは、J2EEでも利用されている。

Struts2 フレームワークのMVCパターンは、以下である。

(1) ユーザインターフェースのコンポーネントをViewとする

(2) アプリケーションのロジックをModelとする

(3) 制御機能をControllerとする

Strutsのview componentは、JSPのtagとして実装される。

これは、フロー制御、モデルへのアクセス、HTMLのフォーマッティングなどの機能がある。

Controllerのcomponentは、actionと呼ばれるJavaのクラスで実装される。

actionは、ユーザのインプットを検証しモデルに対するトランザクションを実行する。

XMLの構成ファイルやJavaのアノテーションがActionを制御するために使われる。

Actionと出力の対応づけを行うことで、フロー制御を行う。

MVC-Webにおけるmodelの役割は、次である。

(1) データベースに対してデータの一貫性を保証する

(2) トランザクション処理

(3) 外部連系

(4) ViewとControllerからのリクエストへ対応するクエリー処理

View Component の責務は次である。

1.情報の表示

2.入力フォームの表示などユーザとのインタラクションの管理

3.クライアント側での処理

Controller の責務は、次である。

1.リクエストの処理

2.アクションの起動



-----

クロニクル ユースケースシナリオを書いてみる

名前:新規予約


目的:新たな予約を受けつけ、可能ならば予約する


起動者:利用者


主シーケンス


(1)利用者は、予約要求情報(利用日、対象会議室、利用者、開始/終了時間)を入力する

(2)システムは、

 
(3)システムは、予約要求情報に従って、会議室予約情報を作成し、予約を行う

 
(4)システムは、予約が完了した旨のメッセージを出力する


代替シーケンス


(a)主シーケンス(2)の予約要求情報が正しくない場合

 
    (a-1)正しくない内容に応じたエラーメッセージを出力する

 
     (a-2)主シーケンス(1)に戻る

 

---

名前:予約確認

目的:日を指定すると、その日の会議室の予約の一覧を表示する

起動者:利用者

主シーケンス

(1)利用者は、利用予定日を入力する

(2)システムは、利用予定日が正しいかチェックする

(3)システムは、利用予定日の会議室予約情報を取得する

(4)システムは、利用予定日の会議室予約情報を表示する

代替シーケンス

(a)主シーケンス(2)で、利用予定日が正しくない場合

　 (a-1) システムは、利用予定日が正しくない旨のメッセージを出力する

      (a-2)主シーケンス(1)に戻る

Comparative Study on Agile software development methodologies

 公開されている

Comparative Study on Agile software development methodologies

のキモ部分を読んで勉強してみたいと思います。

概要

環境変化が激しく、その変化に合わせてソフトウェア要求も変わる。

そしてスピードが求められる。

計画主導の方法では、追いつかない。

アジャイル・ソフトウェア開発は、継続的に価値のあるソフトウェアを

リリースすることで顧客への価値を提供する。

アジャイルは、イテレーティブで、インクリメンタルなプロセスであり、

自己組織化されたクロスファンクショナルなチームによって開発される。

この論文は、ソフトウェア開発プロセスを改善するアジャイルの要因を分析する。

また、アジャイル開発と伝統的な開発の比較を行う。

素早く継続的な価値のあるソフトウェアのリリースが、

伝統的な方法論に比較し、価値があるのではないかと考えている。

アジャイルには、多くの方法論があり、

ソフトウェア開発におけるテクニックやプラクティスがある。

多くのアジャイル方法論では、プロジェクトのライフサイクルを通じて、

チームワーク、コラボレーション、適用に重点を置く。

アジャイルの方法論には、XP、スクラム、ダイナミック・システム・ディベロップメント、

適応型ソフトウェア開発、クリスタルなどがある。

初期の頃から、よく知られたものは、スクラムとXPである。

スクラムは、ソフトウェア開発のプロジェクトのマネジメント、成功に重点を置いている。

XPは、ソフトウェアの実装に重点を置いている。

アジャイルには、多くの方法論があり、

ソフトウェア開発におけるテクニックやプラクティスがある。

多くのアジャイル方法論では、プロジェクトのライフサイクルを通じて、

チームワーク、コラボレーション、適用に重点を置く。

要求の変更への対応

変更への対応は、ソフトウェアプロジェクトにおいて

成功のカギとなる。重量級の方法論では、製品の機能は凍結され、

変更を受け入れない。

アジャイル方法論は、「変更を歓迎する」。

軽量メソッド

ウォーターフォールやスパイラルなどのモデルでは、計画のための費用が高価であり、

事前に定められたとおりのフェーズで進み、大量のドキュメントを作り、設計に時間がかかる。

アジャイルのような軽量のプロセスでは、コードや製造に重点を置く。

ソフトウェアプロダクトの迅速なリリース

アジャイル開発では、ソフトウェアプロダクトの迅速なリリースに重点をおく。

早いサイクルと頻繁なリリースである。

ソフトウェア開発の伝統的な方法論は、要件定義、設計、実装、保守

という工程に従って進めるものである。

ウォーターフォールモデル、計画ドリブン、ドキュメントドリブン、

重厚方法論などと呼ばれている。

これらの方法論では、25%以上の要求が変更されている、と言われている。

アジャイル方法論は、ソフトウェアへの要求はダイナミックに変化するということを

前提においている。

アジャイルチームは、複数のスキルを持つ個人の集まりである。

開発者は、オンサイト顧客で、要求をよりよく理解するために、

絶え間なくドメイン知識を獲得している。

短いライフサイクルで、要求の変更へ対応し、より必要な要求を発見する。

アジャイル開発の定義に共通することは、イテレーティブで、インクリメンタルで、

自己組織化されたアドホックなソフトウェア開発であること。

アジャイルメソッドは、軽量プロセスで、短いイテレーティブで、

ユーザと協働し、要求や優先順位を決めていく。

(つづきます)

Gitを用いた開発の流れ

Gitを用いた開発の流れ

1.Clone

共有リポジトリから、ローカルへコピー

2.ファイル編集

3.add

編集したファイルをcommit対象として登録

4.commit

ローカルリポジトリへ反映

5.push

ローカルリポジトリから、共有リポジトリへの差分送信

6.pull

共有リポジトリから、ローカルリポジトリへ

他のユーザが更新した差分を反映

ラムダ式の表現

関数表現  f(x) = x + 1 

ラムダ表現  λx.x +1 

λx.x +1 で、引数 x = 2 とした場合の表現は

(λx.x +1 )2

Software Development Life Cycle AGILE vs Traditional Approaches

 公開されている

Software Development Life Cycle AGILE vs Traditional Approaches

のキモ部分を読んで、 勉強してみたいと思います。

概要

ソフトウェア開発ライフサイクルは、ソフトウェア開発で必要となる

フェーズを記述するもの。この論文では、伝統的な方法論、

およびアジャイル方法論の、それぞれのメリット、デメリットを述べる。

また、アジャイル開発の改善を提案する。

イントロ

ソフトウェア開発ライフサイクル(SDLC)は、ソフトウエアシステムを

構築、保守するプロセスである。

開発を計画し、コントロールするフレームワークである。

現在の方法論には、伝統的な方法論とアジャイル方法論がある。

伝統的な方法論

water fall モデル、V-Model 、RUPは、伝統的な方法論と呼ばれており、

重量級の方法論に分類される。

これらの方法論は、シーケンシャルに進む方法である。

要件定義、ソリューション開発、テスト、ディプロイ等である。

伝統的な方法論では、プロジェクトの最初に要件を定義し、

ドキュメント化し、固定的な要求セットをつくる。

伝統的な方法論は、4つのフェーズからなる。

最初のステップは、 プロジェクトの要求を決め、

プロジェクトの期間などを見積り、リスクを洗い出すことである。

要求が固まると、次のステップは、設計とアーキテクチャの計画、

インフラの計画である。

アーキテクチャや設計の計画が終わると、開発フェーズに入り、

コードが作られる。そして、テストされ、ディプロイされる。

伝統的な方法論は、事前に定義されたプロセスと、次工程のためのに

作られたドキュメントに依存する。

プロジェクトの成否は、開発を始める前に、どれだけすべての要求を

理解しているかに依存する。途中での要求への変更は、何等かの問題を起こす。

というのも、プロジェクトのコスト、スケジュール、リソースの配分は、

速い段階で決められるから。

3. アジャイル ソフトウェア開発

アジャイル開発は、インクリメンタルで、イテレーティブな開発に基づいている。

 開発の中で、フェーズが何度も行われる。

イテレーションは、顧客からのフィードバックなどで行われる。

アジャイル開発では、開発ライフサイクルは、小さな部分に分割される。

インクリメンタルやイテレーションと呼ばれるものである。

アジャイル開発方法論に分類されるものには、

クリスタル方法論、タイナミックソフトウェア開発、

フィーチャードリブン開発、リーンソフトウェア開発、

スクラム、エクストリームプログラミングがある。

クロニクル MacでC#

1. NETのインストール

こちらから、プラットフォームに合うインストーラーをダウンロードしました。

https://dotnet.microsoft.com/ja-jp/download

今回は、.NET8のSDKにしました。

ダウンロードしたファイルを実行して、全てデフォルトで実行。

無事終了しました。

確認のため、ターミナルで、以下を実行しました。

$dotnet --version

          

8.0.414

2.Hello world 

ターミナルで、作業用のディレクトリを作成する。

$mkdir work

$cd work

C#のコンソールアプリの雛形を作成する。

$dotnet new console

実行してみる

$dotnet run 

Hello, World!

が表示されました。

3.修正してみる

　　Program.csを、次のように修正します。

　修正前

 　　　Console.WriteLine("Hello, World!");

　修正後

 　　using System;

 

          class Program

         {

              static void Main()

            {

                Console.WriteLine("Hello, World!!!");

           }

       }

コマンドプロンプトで、ビルド&実行してみます。

$dotnet build

$dotnet run

Hello, World!!!

が表示されました。修正できているようです。

方法論 DOAの概要

1.概要

・システムを設計する際にデータを中心において設計する方法。

・データはプロセスに比べれば普遍的（変更が少ない）であると考え、

業務プロセスについてもデータを中心に設計することで、変更に強いシステムができる。

・データを決め、そのデータを処理するプロセスを決める、

方法でシステムの分析、設計を行う。

・データの操作が、プログラムごとに重複してしまうことを防止し、

システムの保守効率の向上、データの整合性や一貫性の維持を図る考え方。

2.進め方

まず、データを共有物として設計し、そのデータに基づいて、

システムを設計していく。

擬似コードの文法例

擬似コードの文法例

Input:〇〇

入力や関数の引数などを記述する

Output:〇〇

出力や関数の返り値を記述する

for 変数 = 値１ to 値2  do 
      処理
end for

変数の値を、値１から値２まで、１ずつ増やしながら処理を実行する

while 条件 do
     処理
end while

条件が真の間、処理を実行する

if 条件 then 
   処理１
else 
   処理2
end if 

条件が真ならば、処理１を、真でなければ、処理2を実行する

return 値

関数の返り値として、値を返す

値1 == 値2 (比較演算）

値１と値２が等しければ、真。そうでなければ、偽

値1 != 値2 (比較演算）

値１と値２が等しくなければ、真。そうでなければ、偽

条件1 and 条件2 (論理演算）

条件1と条件2が、ともに真のとき真

条件1 or 条件2 (論理演算）

条件1か、条件２のいずれかが、真のとき真

変数 = 値（代入演算）

変数に値を代入

配列名[添字]

配列の添字番目の要素

木構造

・節点（ノード）を、線（枝、エッジ）で結んでいくもの

・頂上の節点がルート、一番下の節点が葉（リーフ） 

・節点が持つ子の数が、２つ以下のものを、２分木という 

 ・２分木の中で、すべての葉が同じ深さを持ち、

　葉以外のすべての節点について、子の数が２つの２分木を、完全２分木という 

 ・子の値が、親の値よりも、つねに等しいか大きい、という成約があるものを、

 ヒープという

 ・木構造において、左右の節点の数のバランスが取れている（ほぼ同じ）ものを、

 平衡木という 

・平衡木の中で、節点に複数の子のキーを格納するものを、B木という