Difference between revisions of "Subsystems Integrator"
Joelmartin (talk | contribs) |
Joelmartin (talk | contribs) |
||
Line 97: | Line 97: | ||
===Interface Management=== | ===Interface Management=== | ||
− | + | *careful interface documentation ensures proper '''function''' and '''interoperability | |
− | + | '''*ensures that all the development teams document all internal and external interface requirements | |
− | + | *documents Requirements changes in accordance with the Configuration Management Plan | |
− | + | *communicates interface information to team counterparts responsible for affected systems and system elements | |
− | + | *drives coherent testing to verify expected performance and eventually operational performance | |
− | + | *an iterative process | |
− | + | *as knowledge of the system and system elements becomes more defined during design activities, verifiable lower-level requirements and interfaces are defined and refined | |
− | + | *consider impacts of the originally defined capabilities and interfaces, and the overall system when defining and modifying interfaces | |
==Integration Plan== | ==Integration Plan== |
Revision as of 01:06, 29 April 2020
Subsystems Integrator a.k.a The Systems Engineer
Marine Science Subsystems Integrator | |||||||||||||||||||||||||||
Goals
Core Competency
- Create Direction, Alignment and Commitment
- Critical thinking and problem solving
- Excels at decision-making
- Primary Leadership and Planning (leader of leaders)
- Leads Conflict resolution
- High Degree of Adaptability
- Stress Tolerant
- Engages in contract negotiation
Technical Assessment responsibilities
Establish event-driven technical planning Identify appropriate measures and metrics Identify performance measures to assess program health and technical progress Conduct analyses to determine risk and to develop risk mitigation strategies Conduct assessments of technical maturity, process health and stability, and risk to communicate progress to stakeholders and authorities at key decision points Propose changes in the technical approach to address risk mitigation activities Advise the PM regarding the technical readiness of the program to proceed to the next phase of effort Obtain independent subject matter experts as appropriate for reviews and audits
Primary Roles and Responsibilities
Requirements Management
Requirements are the foundation of the program and requirements management process helps ensure delivery of capability that meets intended mission performance objectives. Performance objectives are identified in operational terms at the system level during implementation of the Requirements Definition and Requirements Analysis processes.
The Subsystems Integrator these responsibilities:
- maintain a current and approved set of requirements
- thoughtful analysis and management of requirements insuring for system sustainability
- synchronization with the program’s Configuration Management process to mitigate unintended or unanticipated consequences due to change
- rigorous documentation of changes to the system performance specification
Process Responsibilities
- tracks requirements changes and maintains traceability of the system performance specification and delivered capability
- traces the high-level requirements down to the system elements through the lowest level of the design as the system design evolves to lower levels of detail
- establishes and maintains a Requirements Traceability Matrix (RTM)
- capturing all requirements in the system performance specification
- documenting their decomposition/derivation and allocation history
- document rationale for all entries and changes
- work with PM to track cost, schedule, and performance impacts associated with requirement changes and/or growth
Risk Management
- prioritize identified technical risks and developing mitigation actions
- provide risk mitigation plan to PM for review and approval
Risk Management focal points
Activity | Intent Is to Answer the Question |
---|---|
Risk Identification | What can go wrong? What is the future root cause? |
Risk Analysis | How big is the risk? What is the probability of occurrence? What is the consequence of occurrence? |
Risk Mitigation | What is the approach for addressing a potential unfavorable consequence? How can the planned risk mitigation be implemented? How do we ensure that successful risk mitigation occurs? |
Risk Monitoring | How are risk management plans going? |
Configuration Management
Configuration management is the means by which the results of the systems engineering effort are documented and tracked as changes occur.
The Configuration Management process allows technical insight into all levels of the system design and is the principal methodology for establishing and maintaining consistency of a system’s functional, performance, and physical attributes with its requirements, design, and operational information throughout the system's life cycle.
Configuration Management consists of five interrelated functions that, when collectively applied, allow the program to maintain consistency between product configuration information and the product throughout its life cycle.
The following are the five Configuration Management functions:
Configuration Management Planning and Management is a formal document and plan to guide the Configuration Management program that includes items such as:
Personnel Responsibilities and Resources Training requirements Administrative meeting guidelines including a definition of procedures and tools Baselining processes Configuration control and Configuration status accounting Naming conventions Audits and Reviews Configuration Identification Configuration Change Management Configuration Status Accounting Configuration Verification and Audit
Interface Management
- careful interface documentation ensures proper function and interoperability
*ensures that all the development teams document all internal and external interface requirements
- documents Requirements changes in accordance with the Configuration Management Plan
- communicates interface information to team counterparts responsible for affected systems and system elements
- drives coherent testing to verify expected performance and eventually operational performance
- an iterative process
- as knowledge of the system and system elements becomes more defined during design activities, verifiable lower-level requirements and interfaces are defined and refined
- consider impacts of the originally defined capabilities and interfaces, and the overall system when defining and modifying interfaces
Integration Plan
The PM and SE are responsible for planning, managing, and executing the Integration process.
Programs that develop an integration plan are more successful.
This plan defines the stages of integration, during which system elements are successively integrated to form higher level elements, and eventually the finished product.
The integration plan should include a description of the required teams, test standards, testing methods, and integration schedule.