Software Development and Management

The Assignment Smart Shape is specifically designed to present screens and forms to end users for interaction or data entry. Connectors route flows between shapes, Integrators connect to external systems, and Flow Actions define what happens after a user submits an assignment.

The Obj-List method returns results in a clipboard page of class Code-Pega-List. This is a standard Pega list class, not Rule-Pega-Obj (used for rule instances) or pxResults (a page name, not a class).

The Requestor page holds session information including access roles, RuleSet list, and HTTP parameters. Process pages track work objects, Thread pages hold execution context, and User Pages is not a standard clipboard page.

For a RuleSet with 5 versions, Rule-RuleSet-Name has 1 instance (one name entry) while Rule-RuleSet-Version has 5 instances (one per version like 01-01, 01-02, etc.). The name is shared across versions.

Not all classes require direct inheritance. Pattern inheritance and directed inheritance can be used separately. @baseclass is the root and has no inheritance, but other classes can inherit through patterns without direct parent specification.

Property rules in PRPC can be created with the same name in different rulesets (allowing versioning and specialization) and in different classes (enabling class-specific properties). They cannot be overridden with the same name in the same ruleset and class combination, but PRPC's inheritance facility allows derived classes to access properties defined in parent classes.

All custom classes in PRPC inherit from the three base classes: Work- (for work objects and case types), Data- (for reusable data and reference data), and History- (for historical instances and audit records). These form the foundation of PRPC's class hierarchy.

ASAP (Application Security Assessment and Protection) is most effective when applied throughout the entire software development lifecycle. Starting from requirements analysis allows security considerations to be integrated early, while continuing through rollout ensures vulnerabilities are caught before deployment. Applying it only during specific phases misses opportunities for prevention and increases cost of fixes later.

In the ASAP methodology, the requirements analysis phase focuses on capturing and documenting security requirements in the User Requirement Specification (URS) and Software Requirement Specification (SRS) documents. This ensures security is built into the foundation of the application rather than added later as an afterthought.

During the design and build phase, ASAP performs static code analysis which examines source code without executing it to identify security vulnerabilities, coding errors, and policy violations. This allows issues to be found early when they're cheaper to fix.

ASAP provides Security URS (User Requirement Specification) and Security SRS (Software Requirement Specification) artifacts to guide the analysis phase. These documents capture security requirements and specifications that must be addressed throughout development.

In corporate frameworks (specifically TCS processes), the ASAP (Application Security Assurance Program) Team is tasked with reviewing security elements of updated project artifacts at the end of each development phase. Distractors like the generic development, project management, or testing teams do not have this specialized compliance role.

The ASAP (Application Security Assessment and Protection) process should be applied during all phases of development, starting with requirement analysis and ending with rollout. This comprehensive approach ensures security is considered from the beginning, rather than being added as an afterthought. It's more effective and cost-efficient to integrate security throughout the lifecycle rather than addressing it in a single phase.

In the ASAP process requirement analysis phase, the main activity is to capture and update the URS (User Requirements Specification) and SRS (Software Requirements Specification) with security requirements for the project. This ensures that security considerations are documented alongside functional requirements from the very beginning, creating a foundation for secure design and implementation.

Static code analysis examines source code without executing it to identify security vulnerabilities during the design and build phases. This allows security issues to be caught early in the development lifecycle before runtime testing begins.