• Us Citizen

• Green Card

• Corp-Corp

• Consulting/Contract

• UG :- - Not Required

• PG :- - Not Required

• No of position :- ( 1 )

• Post :- 10th Apr 2021

Obtain access to all Client systems required to deliver on success criteria to close GFMS SII for “individuals have the ability to modify desktop packages between SDLC phases”  Assess any gaps for the current SDLC migration phase for Config Manager applications, Packages, and Software Updates.  Assess gaps for Operating Systems, Boot Images, Drivers, Driver Packages, Compliance Items, Global Conditions, and Task Sequences.  Gaps are defined as any human with the capability to manually copy or modify content in an SDLC environment they should not have access to.  For example, QA human operators must not have the ability to copy binary content into a UAT class binary Windows share, and they must not have the ability to modify the content in the share.  All QA human operators must use abstract technologies such as SharePoint and Orchestrator to modify binary contents of Config manager objects.  With gaps assessed, design enhancements to existing automation to encompass all migratable Config Manager objects.

Author design and architecture documentation as needed in Word and Visio.  The documents must clearly illustrate and describe all aspects of the object migration process and compliance with bank SDLC process.  The role based access model must be clearly defined along with a “break glass” process in the event that automation process should be in an offline state.   The documentation must be submitted and presented to bank management with enough time for review and revisions for ratification prior to the Delivery Date.

SharePoint, Orchestrator, and PowerShell code must be generated and fully functional in a DEV class environment.  The role based access model must be in place, as well as the break glass process model in the event that automation is offline.  Testing use cases must be fully defined in preparation for the next deliverable.

The DEV class SharePoint, Orchestrator and Powershell code must be tested according to bank SDLC standards in the  HP ALM test suite.  Each testing use case and scenario must pass, and if any bugs are found that violate the approved definition and design they must be remediated and passed through the DEV testing cycle.  Final DEV code must be submitted and presented to bank management prior to the Delivery Date for review and revisions for ratification.

SharePoint, Orchestrator, and PowerShell code must be generated and fully functional in a UAT class environment.  The role based access model must be in place, as well as the break glass process model in the event that automation is offline.  Code from the DEV environment must be migrated into the UAT server environment.  Final documentation for the migration process and components must be in place and delivered to the bank’s QA “Production Testing” team.  A formal testing request must be made with the Production Testing team prior to the Delivery Date.

Support the efforts of the Production Testing team by providing any presentations, power points, training materials and conference calls to walk them through migration process documentation and functionality.  Address any bug defects found by the Production Testing team, and rapidly pass them through the DEV environment with promotion to UAT for retest.  Open a “dbUnity” release in Service Now and fill out all artefacts required to satisfy DB global SDLC.  These artefacts include all documentation made in previous milestones as well as links to successful HP ALM test executions in the DEV and UAT environments.

Based on the final product delivered in the UAT environment and lessons learned with onboarding with the QA Production Testing team, update training materials for end user operators of the final migration solution.  Author knowledge base (KB) articles for publishing in dbUnity (Service Now) based on FAQs and common, friendly end user error messages.  Generate end user communications draft messages to be reviewed, approved, and sent out by DB management.

With a “green” release in dbUnity with all artefacts satisfied, generate a change control for implementation.  Plan the implementation day and time, which may be on a weekend to prevent any outages and reduce implementation risk.  Plan the specific steps of the implementation task, as well as validation tasks to confirm positive (everything working) and negative (nothing else broken) tests.  Begin pilot migration work following the implementation and then proceed to full release and usage of the new migration models and process.  Close the change implementation and verification tasks with success.

Meet with all operators and stakeholders to present the migration tools.  Educate them on functionality and usage of the migration tools, as well as the break glass process. Share KB article content.  Onboard L2 teams to KB article support process.  Complete the controlled removal of any human rights to binary content objects after onboarding.

Address any incidents raised in the early lifecycle release of the migration solution.  Schedule and conduct a retrospective meeting with project team, QA, L2, and L3 resources to review lessons learned.  Complete any final documentation and paperwork as needed to close the dbUnity release.