RPAの設計書サンプル

ロボットの設計書、フォーマットどうしたら良いのか問題。

参考になればと思って、一部公開します。

ライトなロボットの設計書なのでスカスカですが、雰囲気をつかんでもらえたら幸いです。

一般的な業務システム等の設計書に比べると、かなりスッキリさせてます。


ロボットの処理する内容によりけりですが、なるべく設計書が散在しないように1つにまとめたいなーとは思ってるので、概要・基本・詳細設計を1つの設計書としてまとめて書いてしまうときもあります。


処理内容、例外処理の他に「ログ」列を入れたほうがいいかもしれませんね。



ループ処理

ループ処理は以下のように書いてます。Automation AnywhereやWinAutomationと同じような表現で書いてます。

多重ループの時は色分けして書いており、この辺もおそらく上記RPAツールと同じ表現ですね。


分岐処理

if分岐は以下のように書いてます。

これも直感的にわかると思います。

基本的にはロボットの処理の流れをダラ~っと書いていくイメージですが、要所要所でログの出力だったり、例外処理の詳細を書いています。

また、ロボットの稼働前に事前に準備しておくことがあれば、「処理名」列に「前提条件」と記して準備の詳細を書いています。


設計書の修正は誰がやる?

設計書はお客さんからの要件ヒアリング後に作っていますが、そういった意味では概要設計書=ヒアリングメモとして、まずは叩き台を作っています。


概要設計のような詳細設計のような設計書を一通り作ってから、要件がFixしているか否かは関係なく、実装者に実装をお願いしています。


RPAに関しては後付けで要件が追加されたり削除されるケースも多々あるため、それを待っていてはいつまでたっても実装に着手できないからです。まずは形にすることを優先します。

実装中に要件が変わった場合は、その要件にフィットする設計を設計者が考え、設計書に反映します。

変更・追加箇所は色を付け、設計書のバージョンも上げます。


仕様が変わった場合はこれでいいのですが、実装中に設計不備の箇所が判明した場合は、実装者に設計書を修正してもらっています。

もちろん修正が必要と判明したタイミングで、都度実装者から口頭で話を聞きますが、定期的に設計書を見直し、変更箇所を確認します。


今のところ設計書も納品しろとまで言われたことはないのですが、一応内容は実装と乖離がないように、かつ、見た目が綺麗に保たれるように心がけています。



テストケースは設計書ベースで

余談ですが、テストケースを作る時もこの設計書をベースに作っています。


「処理内容」列や「例外処理」列の右隣に「テスト実施日」「テスト担当者」「テスト結果」列を追加して、各処理のテスト結果を記入できるようにすることで、テスト仕様書の8割方は完成ですw


多端末テストやロボット起動時に流し込むデータのパターンテスト等、別途ケースを起こす必要のあるテストについては、別途ドキュメントを作っています。


テストのエビデンスは、解像度を限界ギリギリまで下げた動画で残しています。


今のところは上記内容でロボットは実装できていますが、随時ブラッシュアップ中です。


こうしたほうが良い等アドバイスあれば、Twitterにて教えてください><

いろはまるのしごと

IT×業務効率化・自動化にしたたかに燃えるうさぎです。

0コメント

  • 1000 / 1000