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

私は、アクセス制御（認可）に関して、ロールとパーミッションの固有のトレードオフを理解しようとしています。 与えられたものから始めましょう：私たちのシステムでは、パーミッションはきめ細かいアクセス単位です（「リソースXの編集」、「ダッシュボードページへのアクセス」など）。役割は 1+権限のコレクションになります。ユーザーは 1+役割を持つことができます。これらの関係（ユーザー、ロール、権限）はすべてデータベースに保存され、必要に応じてその場で変更できます。 私の懸念： （1）アクセス制御のためにロールをチェックすることの「悪い」ところは何ですか？代わりにアクセス許可を確認することでどのような利点が得られますか？言い換えると、これらの2つのスニペットの違いは次のとおりです。 if(SecurityUtils.hasRole(user)) { // Grant them access to a feature } // vs. if(SecurityUtils.hasPermission(user)) { // Grant them access to a feature } そして： （2）このシナリオでは、ロールはどのような有用な価値を提供しますか？1つ以上のアクセス許可をユーザーに直接割り当てることはできませんか？ロールはどのような抽象化の具体的な価値を提供しますか（特定の例を挙げられますか）？

45 security  permissions  authorization  access-control  roles 

私の経験では、ソフトウェア開発者は複数の帽子をかぶって、複数の役割を異なる責任で満たす傾向があります。コーディングだけでなく、SQLの作成、ユーザーインターフェイスの設計、データベースの設計、グラフィックス操作、QAテストまでも行います。 主な役割がソフトウェア/コードの作成である場合、開発者はどのような役割を引き受けるべきではありませんか？ いずれかがあります？ この質問の意図は、開発者が別の役割を果たせないためではありませんが、追加の役割を持つことは実際には主な役割に対して機能するか、実際には主にプログラムしない人の専用の役割でなければなりません。

29 team  roles 

チームマネージャーがスクラムマスターであってはならないということは一般的に認められていますが、その理由を理解するのに苦労しています。コンテキストでは、私はスクラムチームに4人の開発者がいるアプリケーション開発マネージャーです。私はスクラムマスターのバックグラウンドを持ち、組織にスクラムを導入しました。私はチームをゼロから構築し、私がやることはすべてチームを促進することであり、彼らが決定を下すことを明確にしました。チームとして私たちは非常にオープンです-彼らは私たちが取得し始めていた「報告」の感覚を排除するために、しばらくスタンドアップで私を黙らせさえしました。一般的に、オープン性の欠如は、スクラムマスターとしてのマネージャーに対する最大の議論ですが、適切に処理されれば、適切な文化で簡単に克服できます。 経験豊富なスクラムコーチから、これは危険な状況であり、「物事がうまくいかない場合」のリスクがあると警告されています。私の考えでは、2つの役職は対立しません。どちらの役割においても、チームと個人の目標は同じです。スクラムは、チーム内の競合を解決します。これは、従来はマネージャーの役​​割でした。スプリントの自己管理の性質により、マネージャーが従来行っていた作業の割り当てがなくなります。 開発者マネージャーが個人のニーズを満たしていること、キャリアの目標、職場などを確認しているので、ピックアップするのは本当に残っていると思います。これの多くは、チームに直接関係しています。または、とにかくスクラムマスターとしての私の役割に関連しています。 大規模な組織では、これが管理不可能で別の役割になることを理解していますが、小規模な組織では、別のスクラムマスターまたは開発マネージャーを正当化することはできません。 スクラムマスターとしての開発マネージャーの落とし穴について教えてください。上で挙げた点と既に克服した点を除きます。

27 scrum  teamwork  team  roles 

私が取り組んできたより伝統的なプロジェクトでは、プロジェクトマネージャー（および、大規模なプロジェクトでは、1人の担当者が利用できない場合、アソシエイト/代理/アシスタントのプロジェクトマネージャーが存在する可能性があります）は、プロジェクトと顧客とのコミュニケーションの責任者ですヘルスとステータスの更新、スケジューリングと予算の決定、プロセスの管理、チームがタスクを完了するために必要なものを確保するなど。 ただし、スクラムでは、これらの責任はプロダクトオーナーとスクラムマスターの間で分割されます。製品所有者は顧客の声です。顧客と直接やり取りし、ユーザーストーリーを作成し、製品バックログやその他のユーザー/顧客が直面する問題を整理して優先順位を付けます。ScrumMasterはプロセスを処理し、会議（推定と計画を含む）を監督し、障害を取り除き、プロジェクトの全体的な健全性を監視し、必要に応じて調整します。 Wikipediaを含む複数の情報源で、ScrumMasterとプロダクトオーナーの役割は2人の異なる人物が担うべきだと読みました。私は読んだだけでなく、両方のアクティビティが1人の個人によって処理される、成功した「伝統的な」スタイルのプロジェクトに取り組みました。実際、1人から3人の人々がプロジェクト（人事/人員を含む）とプロセスレベルのタスクを処理する責任があることは、彼らがしばしば手をつないで行くので、より理にかなっています。プロセスの変更は、スケジューリング、予算編成、品質、およびその他のプロジェクトレベルの目標に影響を与え、プロジェクトの変更はプロセスに影響を与えます。 スクラムがこれらのアクティビティを2つの役割に分離する必要があるのはなぜですか？これは実際にどのような利点を提供しますか？プロダクトオーナーとスクラムマスターが同じ個人であるスクラムプロジェクトで成功した人はいますか？

19 project-management  scrum  team  roles 

役割ベースのアクセス制御モデルに従って、システムでユーザーができることまたはできないことを制限しようとしています。 これまでのところ、次のエンティティがあります。 users-システムを使用する人。ここにユーザー名とパスワードがあります。 roles-ユーザーが持つことができる役割のコレクション。マネージャー、管理者などのリソースのような もの-ユーザーが操作できるもの。契約、ユーザー、契約草案などの 操作のように -ユーザーがリソースでできること。作成、読み取り、更新、削除など。 さて、このような関係があるダイアグラムでは、ここで疑問が浮上します。 操作（0 .. *）は リソース（0 .. *）に対して実行され、permissionsという名前のテーブルを生成し、操作とリソースを保存します。 許可テーブルは次のようになります（1行）： ID： 1、操作： create、リソース： contract。 どの意味許可する作成の契約を。 一部のリソースにはすべての種類の操作が含まれていない可能性があると感じているため、このようにしました。たとえば、契約を登録する場合、ユーザーはファイルをアップロードできますが、この操作はプロバイダーの登録には使用できません。 そのため、管理者がロールにアクセス許可を付与するときに、システムに登録されたすべての単一操作のリソースのリストはありません。 各リソースには、自分で実行できる独自の操作のコレクションがあると思います。 何かが理解できない場合は明確にすることができます。 これは、rbacを実装する正しい方法ですか？ 編集 つまり、操作とリソースを持つアクセス許可テーブルを使用することで、リソースを操作に関連付けるために2つの余分なテーブルがあります。また、私はちょうど行っている可能性のリソースが持っている権限の許可テーブルが権限を格納します。 しかし、その場合、管理者がリソースを割り当てたときに、一部のリソースには存在しないアクセス許可が表示されていた可能性があります。 だから私は、データベース設計の観点から、1つの列操作と別のリソースを持つこのテーブル権限が正しいかどうか知りたいですか？この状態が続くと問題が発生しますか？

15 database-design  authorization  permissions  access-control  roles 

私はジュニアソフトウェア開発者で、1年未満の会社で働いています。 ソフトウェア開発者であるということは、ソフトウェアとCODEを開発することを意味するといつも思っていましたが、私の仕事は、Jenkins、SQLレプリケーションなどのセットアップなど、管理タイプの仕事にあります。 これらのタイプのジョブは開発者の役割に含まれていますか、それとも開発者はソフトウェアのみを開発していますか？これについて上司と話すべきですか？これは、企業が「開発」スキルを評価するための一般的な方法ですか？

10 company  roles  task