タグ付けされた質問 「reporting」

まず、これは軽視されている質問/領域であるように思われるので、この質問を改善する必要がある場合は、他の人に利益をもたらすことができる素晴らしい質問にしてください！試してみたいアイデアだけでなく、この問題を解決するソリューションを実装した人々からのアドバイスやヘルプを探しています。 私の経験では、アプリケーションには2つの側面があります。主にドメイン駆動型で、ユーザーがドメインモデル（アプリケーションの「エンジン」）とやり取りする「タスク」側と、ユーザーがタスク側で何が起こるかに基づいてデータを取得します。 タスク側では、リッチなドメインモデルを備えたアプリケーションにはドメインモデルのビジネスロジックが必要であり、データベースは主に永続化のために使用する必要があることは明らかです。懸念の分離、すべての本はそれについて書かれています、私たちは何をすべきか、素晴らしいを知っています。 レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。データベースのデータをデータウェアハウスデータに集約するには、データにビジネスロジックとルールを適用している必要があります。そのロジックとルールはドメインモデルからではなく、データ集約プロセスからのものです。それは間違っていますか？ 私は、ビジネスロジックが広範囲にわたる大規模な財務およびプロジェクト管理アプリケーションに取り組んでいます。このデータのレポートを作成するとき、レポート/ダッシュボードに必要な情報を取得するために多くの集計を行うことが多く、集計には多くのビジネスロジックが含まれています。パフォーマンスのために、高度に集約されたテーブルとストアドプロシージャを使用してこれを行っています。 例として、アクティブなプロジェクトのリストを表示するためにレポート/ダッシュボードが必要だとしましょう（10,000個のプロジェクトを想像してください）。各プロジェクトには、次のような一連のメトリックが必要です。 総予算 これまでの努力 燃焼速度 現在の燃焼速度での予算枯渇日 等 これらのそれぞれには、多くのビジネスロジックが含まれます。そして、私は単に数字の乗算やいくつかの単純なロジックについて話しているのではありません。予算を得るために話しているのは、各従業員の時間（一部のプロジェクトでは、他のプロジェクトでは乗数があります）に1つずつ、500の異なるレートのレートシートを適用し、費用や適切なマークアップなどを適用する必要があることですロジックは広範です。クライアントにとって妥当な時間内にこのデータを取得するには、多くの集約とクエリのチューニングが必要でした。 これは最初にドメインを介して実行する必要がありますか？パフォーマンスはどうですか？単純なSQLクエリを使用しても、クライアントが妥当な時間内に表示するのに十分な速度でこのデータを取得することはほとんどありません。これらすべてのドメインオブジェクトをリハイドレートし、アプリケーションレイヤーでデータを混合および照合して集約する場合、またはアプリケーションでデータを集約しようとする場合、クライアントにこのデータを十分に速く取得しようとすることは想像できません。 これらのケースでは、SQLはデータの処理に優れているように思われますが、使用しないのはなぜですか？ただし、ドメインモデルの外部にビジネスロジックがあります。ドメインモデルおよびレポート集計スキームでビジネスロジックを変更する必要があります。 ドメイン駆動設計と優れた実践に関して、アプリケーションのレポート/ダッシュボード部分をどのように設計するかについて、私は本当に困っています。 MVCはデザインフレーバーデュジュールであり、現在のデザインで使用しているため、MVCタグを追加しましたが、レポートデータがこのタイプのアプリケーションにどのように適合するかわかりません。 本、デザインパターン、グーグルのキーワード、記事など、この分野での助けを探しています。このトピックに関する情報が見つかりません。 編集と別の例 今日出会った別の完璧な例。顧客が顧客営業チームのレポートを望んでいる。彼らは単純なメトリックのように見えるものを望んでいます： 各営業担当者の現在までの年間売上はいくらですか？ しかし、それは複雑です。各販売員は複数の販売機会に参加しました。勝った人もいなかった人もいます。各販売機会には、それぞれの役割と参加ごとに、販売に対するクレジットの割合が割り当てられた複数の販売員がいます。それでは、このためにドメインを通過することを想像してください。すべての営業担当者のデータベースからこのデータを引き出すために必要なオブジェクトの再水和の量： すべての取得SalesPeople- > それぞれが得るために彼らのSalesOpportunities- > 各販売の彼らの割合を取得し、その販売量を算出するために 、すべての彼らの最大の追加SalesOpportunity販売量を。 そして、それは1つのメトリックです。または、迅速かつ効率的に実行し、高速に調整できるSQLクエリを作成できます。 編集2- CQRSパターン CQRSパターンについて読んだことがありますが、興味深いことに、Martin Fowlerもテストされていないと言います。それで、過去にこの問題はどのように解決されましたか。これは、何らかの点で全員が直面していなければなりません。成功の実績を持つ確立されたアプローチまたは使い古されたアプローチとは何ですか？ 編集3-レポートシステム/ツール このコンテキストで考慮すべきもう1つのことは、レポートツールです。Reporting Services / Crystal Reports、Analysis Services、Cognoscentiなどはすべて、SQL /データベースからのデータを想定しています。これらのデータが後であなたのビジネスに届くとは思いません。それでも、彼らと彼らのような人々は、多くの大規模システムのレポートの重要な部分です。これらのシステムのデータソースやレポート自体にもビジネスロジックがある場合、これらのデータは適切に処理されますか？

44 mvc  architecture  domain-driven-design  reporting  data-warehouse 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 で別の質問、私は、開発者が好きではないかもしれない理由について尋ねた毎日スクラム。開発者と話をして、しばらくの間毎日のスクラムを開催しないことにしました（最初の試みで試してカスタマイズしたスクラムを提供するため）。これは、開発者と直接相談した結果です。 一方、開発者を毎日調整する機会を得たり、主要業績評価指標のように作業の進捗を監視したりして、早期にアクションを起こすなど、毎日のスクラムの良い部分を失いたくありません。 毎日のスクラムに代わるものとして、開発者に次の条件で毎日のレポートを提供するよう依頼することを考えています。 特定の形式に従う必要はありません。すべての形式が受け入れられます。 作業が完了していなくても、進捗状況を聞きたいと思っています。 各タスクに費やされた時間を言及する必要はありません。 開発の障害と調整の要件に言及する必要があります。 毎日のレポートに取りつかれている必要はありません。そんなに厳しくはありません。 これにより生産性が低下すると思いますか？日報の経験はありますか？マイクロ管理を行っていないことを確認できるように、何か提案がありますか？

18 productivity  management  scrum  meetings  reporting 

大量のデータを収集し、レポートが組み込まれたアプリケーションがあります。最初のイテレーションは、Crystal Reportsの統合で、うまく機能しました。Crystal Reportデザイナーでレポートを作成し、RPTファイルをアプリケーションにインポートします。これはうまくいきましたが、ユーザーはレポートを実行するためにアプリケーションが必要であり、さらにユーザーはレポートを作成できませんでした。RPTファイルをカスタマイズできるようにフィルター、ソーター、およびグループ化を追加しましたが、ゼロから作成することはできませんでした。 2番目の対話は、SSRS、SSAS、およびMicrosoftのレポートビルダーツールを使用したWebベースのソリューションでした。これには、いくつかのデータベース作業とOLTPスキーマからキューブを起動して実行するための作業が必要でしたが、最終的には、ロールアップレポートを作成するのがはるかに簡単になりました。ただし、レポートビルダーツールを使用してレポートを作成し、その後公開する必要があります。また、フィルター、ソーター、グルーパーを追加して「カスタマイズ可能」にします。 これらのシナリオの両方で、約30から50の時間外レポートがすぐに作成されます。 ユーザーがその場でレポートを最初から作成できるように、アドホックレポートを追加することについての議論があります。現在、データモデルは非常に複雑であり、それを理解するには実用的な知識が必要です。これを最小限にするには、データモデルを「レポート可能」で理解しやすいスキーマにするために、かなりの作業が必要になります。私たちのアプリケーションがアドホックレポートに適しているとは思いません（努力する価値はありません）。 アドホックレポートの提供に成功した人はいますか？どのツールセットを使用しましたか？アプリケーションの成功に影響を与えましたか？

16 business  reporting 

雇用主に進捗を報告するのに問題があります。私はパートタイムプログラマで、学校の（非技術）部門のソフトウェアプロジェクトを担当しています。 担当者： 1.実際にソフトウェアを使用し、機能要求を提起するスタッフ 。2.私の上司（プログラマーではない）。彼女はソフトウェアのユーザーではありません。 プロジェクトの性質： サードパーティから購入した既製のソフトウェアです。部門のニーズに応えるために、このソフトウェアの機能を変更または追加する必要があります。これは学期を通して使用する必要があるソフトウェアです。すべての機能を最初に使用する必要があるわけではありません。 そのため、アジャイルモデルを使用しています。スタッフが特定の機能を必要とするとき、リクエストを出し、変更を加えます。学期の終わりまでに、必要なすべての機能が引き上げられ、実装されると思います。 問題： 上司が進捗状況を尋ねるたびに、答える方法がわからないので、答えられません。すべての必要な機能の完全なリストがありません。先週提起された機能を完了しましたが、上司に「完了」したことを伝えることはできません。新しい機能も追加されており、その程度はわかりません。「％の完了率があります」や「xxxで完了します」とは言えません。3つのリクエストのうち、2を完了することができたので、上司に「2を完了しましたが、まだ完了していない機能が1つあります」と伝えます。長い時間を経て、「長い間、いつも終わらない何かがあります」と聞こえます。 進捗状況を報告できないことは、私にとって本当に悪いように見えます。それは私がどれだけやったかではなく、人々に知らせる方法です。私がマネージャーであり、私のスタッフが何ヶ月も進捗を報告し続けない場合、この男も能力がないと感じます。 「ソフトウェア変更のステータス/進捗状況」と同じくらい簡単に報告する方法、または質問に答える方法がありますか？ 更新 私の上司は開発タスクに直接関与していないため、私が何をしているか、またはプログラムがどのように機能するかについて、手がかりがありません。彼女は忙しいので、定期的に会うことはありません。彼女はメインユーザーではなく、プログラムの詳細を知らないので時間の無駄になると思います。 私はソフトウェアを使用し、ソフトウェアについてよりよく知っているスタッフと定期的に会います。 上司に進捗を説明するのは難しいと感じています。

15 project-management  agile  reporting 

私は彼らが何を決定するのか理解していますが、見つかった問題にそれらを割り当てることは本当に便利ですか？つまり、すぐに修正する必要があるかどうかです。 それらの設定方法、分類方法などを知っています。IEEE/ ISOがそれを行う必要があることは知っています。理由がわかりません。

11 testing  reporting  defect 

時々、私のQAチームはバグを報告しますが、私も彼らもそれらを再現する方法について何の考えも持っていません。これにより、非常に長くてイライラするデバッグセッションが発生し、結果が得られない場合もあります。 私のソフトウェアは専有のハードウェアと強く結びついているので、バグは一度に多くの方向から発生する可能性があります。 「ボタンを押したときにソフトウェアがクラッシュした」以上のことを期待するべきでしょうか、それとも自分で何が起こったのかを理解する必要がありますか？ 編集： 私の同僚の1人は、おそらくここではすべての開発者であるため、結果には少しバイアスがかかる可能性があると指摘しました

10 testing  bug  qa  reporting