Systems Engineering Competencies - NASA
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPNASA’s Systems EngineeringCompetencies1
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPSystems Engineering Competencies*Competency Area:Competency Area:1.0 Concepts and Architecture6.0 NASA Internal and External Environments1.1 Mission Needs Statement1.2 System Environments1.3 Trade Studies1.4 System ArchitectureCompetency Area:2.0 System Design2.1 Stakeholder Expectation Definition & Management2.2 Technical Requirements Definition2.3 Logical Decomposition2.4 Design Solution DefinitionCompetency Area:3.0 Production, Product Transition, Operations3.1 Product Implementation3.2 Product Integration3.3 Product Verification3.4 Product Validation3.5 Product Transition3.6 OperationsCompetency Area:4.0 Technical Management4.1 Technical Planning4.2 Requirements Management4.3 Interface Management4.4 Technical Risk Management4.5 Configuration Management4.6 Technical Data Management4.7 Technical Assessment4.8 Technical Decision Analysis6.1 Agency Structure, Mission, and Internal Goals6.2 NASA PM/SE Procedures and Guidelines6.3 External RelationshipsCompetency Area:7.0 Human Capital Management7.1 Technical Staffing and Performance7.2 Team Dynamics and ManagementCompetency Area:8.0 Security, Safety and Mission Assurance8.1 Security8.2 Safety and Mission AssuranceCompetency Area:9.0 Professional and Leadership Development9.1 Mentoring and Coaching9.2 Communication9.3 LeadershipCompetency Area:Competency Area:5.0 Project Management and Control10.0 Knowledge Management5.1 Acquisition Strategies and Procurement5.2 Resource Management5.3 Contract Management5.4 Systems Engineering Management10.1 Knowledge Capture and Transfer2
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPDescription of Proficiency Levels Associated with the APPEL Model for Systems EngineersTo determine how best to proceed after entering the NASA workforce and progress through the technical professional development model,it is helpful to understand the definition of each level. The following table is intended as a guide for use with the technical developmentmodel for systems engineers.SE Proficiency Level IEngineeringLeadershipDescription ofRole/ResponsibilityLevel ofExpertise(LEO)/Competencyto AttainProficiencyLevelValidation ofLevelsLearning andDevelopmentemphasisTechnical Engineer / ProjectTeam MemberPerforms fundamental androutine SE activities whilesupporting a Level II-IVsystems engineer as amember of a project teamPractitioners have obtained aworking knowledge of technicalintegration, systemsengineering (SE) and projectmanagement (PM) conceptsand tools and performed tasksand activities to support andcontribute to a project. Theydemonstrated an awarenessand understanding of NASA'sSE and PM tools, techniques,and lexicon. They havesufficient experience andresponsibility and are preparedto contribute to fundamentaland routine SE activities.Practitioner’s immediatesupervisorThe emphasis at Level I isknowledge and understandingof technical integration, SE andbasic project management.SE Proficiency Level IISE Proficiency Level IIISE Proficiency Level IVSubsystem LeadProject Systems EngineerPerforms SE activities for asubsystem or simple project(e.g. no more than two simpleinternal/external interfaces,simpler contracting processes,smaller team/budget, shorterduration)Practitioners participated in orled SE activities (e.g.requirements development,budget and scheduledevelopment, riskmanagement). Theydemonstrated the applicationof SE/PM tools, techniques,and lexicon at the projectsubsystem level, including useof SE/PM best practices. Theyhave sufficient experience andresponsibility and are preparedto lead SE and technicalintegration activities for asubsystem or simple project.Performs as a systemsengineer for a complex project(e.g. several distinctsubsystems or other definedservices, capabilities, orproducts and their associatedinterfaces)Practitioners have taken asignificant leadership role inmultiple phases of a project lifecycle managing bothprogrammatic and technicalaspects and/or managing alltechnical integration and SEfunctions for a subsystem orsmall project. Theydemonstrated the integration ofSE/PM tools, techniques, andbest practices acrosssubsystems at the projectlevel. They have sufficientexperience and responsibilityand are prepared for atechnical leadership role insupport of a major system orprojectCenter Peer Group and EDPpanelThe emphasis at Level III is thedirecting, structuring, andintegration activities of SE.Program Systems Engineer orCenter/AgencyOversees SE activities for aprogram with several systemsand/or establishes SE policiesat the Agency or Center level.Center Peer Group and EDPpanelThe emphasis at Level II isleadership application andparticipation in SE.Practitioners will havecontributed to Agency goalsand be effective in managingprogrammatic, technical, andstrategic interfaces bothinternal and external to theAgency. They demonstratedsuperior competencies in allSystems Engineeringformulation andimplementation activities.They have sufficientexperience and responsibilityand are prepared for atechnical leadership role at theprogram, center, or agencylevel.Center Peer Group, EDP andAgency-wide panelsThe emphasis at Level IV is onthe strategy for SE of largecomplex initiatives and thestrategy and management ofAgency initiatives.3
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPStructure of the Systems Engineering Competency FrameworkThe SE Competencies are structured as follows:1) Competency Areas: These describe, in broad terms, what is expected of Systems Engineer personnel in terms ofparticular components or functions of the job.2) Competencies: These express the overall knowledge, skills, behaviors that SEs are expected to posses and/or performas a part of their job.3) Competency Elements: Each Competency Area and Competency consists of Competency Elements that describe thespecific knowledge, skills, behaviors, which can be measured against established standards, can be improved viatraining and development activities, and correlate to performance on the job.4) Proficiency Level Descriptions: These specify the knowledge/performance to be achieved in order to demonstratesuccessful mastery of the competency and are expressed in terms of levels.5) HQ courses, Center courses, OJL activities, Other learning activities, Assessment Guidelines: These outline therequired/suggested courses and activities to obtain proficiency in the competencies by level. The AssessmentGuidelines indicate the evaluation and/or assessment of the competencies by level and are used as entry/exit criteriafor each level of development.6) The Competency framework is hierarchal and the numbering scheme is as follows:Competency Area – #.0Competency – #.# – the first number indicates the Competency Area the competency falls into, the second is theCompetency numberCompetency Element - #.#.# - the first and second numbers indicate the Competency Area andCompetency, respectively, that the Element is related to, the third is the particular Element number4
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPCompetency Area: 1.0 Concepts and ArchitectureCompetency: 1.1 Mission Needs StatementCompetency Elementsand Descriptions1.1.1 Mission Needa. Identify needb. Identify basis of need1.1.2 Current Situationa. Describe currentsituationb. Identify deficiencies ofsituationc. Identify what works incurrent situation1.1.3 Mission NeedsStatement Formulationa. Get agreement onproblem definitionb. Define desired outcomesc. Define success criteriad. Document NeedProficiency Level DescriptionsLevel 1Aware that projects start withusers having an unsatisfiedneedContribute to definition of thecurrent situation to includewhat does and doesn’t workContribute to preparation ofthe mission needs statementLevel 2Level 3Level 4Able to (for a subsystem orsimple project): Identify the users Distinguish between whatthe users want and what theusers needAble to (for a subsystem orsimple project) describe thecurrent situation to includewhat does and doesn’t workAble to (for a system): Identify the users Distinguish between whatthe users want and what theusers needAble to (for a program): Identify the users Distinguish between whatthe users want and what theusers needAble to (for a system) describethe current situation to include: What does and doesn’t work What has and hasn’t workedin similar projectsAble to (for a program)describe the current situation toinclude: What does and doesn’t work What has and hasn’t workedin similar programsAble to (for a subsystem orsimple project): Create consensus regardingthe problem definition Describe, identify or definedesired outcomes andsuccess criteria Write a mission needsstatementAble to (for a system) createconsensus regarding theproblem definitionAble to (for a program) createconsensus regarding theproblem definitionDirect (for a system): Description, identification ordefinition of desiredoutcomes and successcriteria Drafting of a mission needsstatementDirect (for a program): Description, identification ordefinition of desiredoutcomes and successcriteria Drafting of a mission needsstatementHQ coursesCenter coursesOJL activitiesOther learning activitiesAssessment5
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPCompetency Area: 1.0 Concepts and ArchitectureCompetency: 1.2 System EnvironmentsCompetency Elementsand DescriptionsProficiency Level DescriptionsLevel 11.2.1 SystemEnvironmentIdentificationInvolved in identifyingconstraints and the expectedsystem environmenta. Identify constraintsb. Identify expected systemenvironmentc. Analyze/quantifyexpected environmentAble to analyze/quantifyexpected environment1.2.2 Design GuidanceUnderstand the purpose ofhaving a margin philosophyagainst the expectedenvironment and how thatleads to design guidancea. Establish marginphilosophy against theexpected environmentb. Establish designguidance for theexpected environmentApply provided designguidanceLevel 2Level 3Level 4Able to (for a subsystem orsimple project): Identify constraints Identify expected systemenvironment Analyze/quantify expectedenvironmentDirect (for a system): Identification of constraints Identification of expectedsystem environment Analysis/quantification ofexpected environmentDirect(for a program): Identification of constraints Identification of expectedsystem environment Analysis/quantification ofexpected environmentApply (for a subsystem orsimple project): Margin philosophy againstthe expected environment Design guidanceEstablish (for a system): Margin philosophy againstthe expected environment Design guidanceEstablish (for a program): Margin philosophy againstthe expected environment Design guidanceDefine Agency/Center designguidance policiesHQ coursesCenter coursesOJL activitiesOther learning activitiesAssessment6
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPCompetency Area: 1.0 Concepts and ArchitectureCompetency: 1.3 Trade StudiesCompetency Elementsand Descriptions1.3.1 Concept Definitiona. Define scope optionsb. Define operationsconceptc. Define technical solutionoptions1.3.2 System Modela.b.c.d.Create system modelValidate system modelOperate system modelCorrelate system modelwith operational data1.3.3 SystemPerformancea. Evaluate possibleconceptsb. Select technical solutionProficiency Level DescriptionsLevel 1Contribute to definition ofscope optionsUnderstand the need for anoperations concept early in theprojectContribute to: Creation of system model Validation of system model Correlation of system modelwith operational dataAble to operate a systemmodelContribute to: Evaluation of possibleconcepts Recommendation of atechnical solution thatbalances technical and nontechnical features of thesystemLevel 2Able to define (for asubsystem or simple project): Scope options Technical solution optionsContribute to (for a subsystemor simple project) developmentof the operations conceptAble to (for a subsystem orsimple project): Create, validate, and operatea system model Correlate a system modelwith operational dataAble to (for a subsystem orsimple project): Evaluate possible concepts Recommend a technicalsolution that balancestechnical and non technicalfeatures of the systemLevel 3Level 4Direct (for a system): Definition of scope options Definition of technicalsolution options Development of theoperations conceptDirect (for a program): Definition of scope options Definition of technicalsolution options Development of theoperations conceptDirect (for a system): Creation, validation, andoperation a system model Correlation of system modelwith operational dataDirect (for a program): Creation, validation, andoperation a system model Correlation of system modelwith operational dataDirect (for a system): Evaluation of possibleconcepts Selection of a technicalsolution that balancestechnical and non technicalfeatures of the systemDirect (for a program): Evaluation of possibleconcepts Selection of a technicalsolution that balancestechnical and non technicalfeatures of the systemHQ coursesCenter coursesOJL activitiesOther learning activitiesAssessment7
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPCompetency Area: 1.0 Concepts and ArchitectureCompetency: 1.4 System ArchitectureCompetency Elementsand Descriptions1.4.1 FunctionalAnalysisa. Establish systemboundariesb. Define architecturefunctionsc. Analyze architecturefunctional performanceProficiency Level DescriptionsLevel 1Level 2Level 3Level 4Aware that overall architecturecan be broken into functionalsegmentsAble to (for a subsystem orsimple project): Identify system boundariesincluding external interfaces Segment an architecture intofunctions Analyze functionalperformance of multiplesegmentsAble to define (for asubsystem or simple project): Subsystems from thearchitecture functions Subsystem relationships Internal interfacesDirect (for a system): Identification of systemboundaries including externalinterfaces Segmentation of anarchitecture into functions Functional analysis of allsystems architecturesegmentsDirect definition of (for asystem): Subsystems from thearchitecture functions Subsystem relationships Internal interfacesDirect (for a program): Identification of systemboundaries including externalinterfaces Segmentation of anarchitecture into functions Functional analysis of allsystems architecturesegmentsDirect definition of (for aprogram): Subsystems from thearchitecture functions Subsystem relationships Internal interfacesParticipate in documentationof the systems architectureAble to (for a system)document systems architectureDirect (for a program)documentation of systemsarchitectureAble to analyze functionalperformance of at least onesegment of the architecture1.4.2 SubsystemMappingAware that architecturefunctions become subsystemsa. Map architecturefunctions to subsystemsb. Define subsystemrelationshipsc. Identify internalinterfacesContribute to: Definition of subsystemrelationships Identification of internalinterfaces1.4.3 SystemsArchitectureDocumentationContribute to documentationof systems architecturea. Document the systemsarchitectureHQ coursesCenter coursesOJL activitiesOther learning activitiesAssessment8
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPCompetency Area: 2.0 System DesignCompetency: 2.1 Stakeholder Expectation Definition & ManagementCompetency Elementsand Descriptions2.1.1 StakeholderIdentificationa. Identify all stakeholders2.1.2 StakeholderExpectation Definitiona. Elicit stakeholderexpectationsb. Define stakeholderexpectation inacceptable statementsc. Generate MOEs fromstakeholder expectationstatements2.1.3 StakeholderExpectation Validationa. Validate traceability ofdefined stakeholderexpectation statementsb. Obtain stakeholder buyin of validated set ofexpectationsc. Baseline stakeholderexpectations2.1.4 StakeholderExpectationManagementa. Manage expectations ofstakeholdersProficiency Level DescriptionsLevel 1Level 2Level 3Level 4Aware that stakeholders mustbe involved early in the projectlifecycleAble to (for a subsystem orsimple project) identify projectstakeholdersAble to (for a system) identifyproject stakeholdersAble to identify programstakeholdersContribute to: Translation of stakeholderexpectations into acceptablestatements Creation of MOEs fromstakeholder expectationstatementsContribute to (for a subsystemor simple project) obtainingstakeholder expectationsDirect (for a system): Obtaining of stakeholderexpectations Translation of stakeholderexpectations into acceptablestatements Creation of MOEs fromDirect (for a program): Obtaining of stakeholderexpectations Translation of stakeholderexpectations into acceptablestatements Creation of MOEs fromstakeholder expectationstatementsstakeholder expectationstatementsContribute to: Validation of stakeholderexpectations statements Baselining of stakeholderexpectationsAware that stakeholder buy-inmust be obtainedAware that stakeholdersexpectations must be managedthroughout the project lifecycleAble to (for a subsystem orsimple project): Translate stakeholderexpectations into acceptablestatements Create MOEs fromstakeholder expectationstatementsAble to (for a subsystem orsimple project): Validate stakeholderexpectations statements Baseline stakeholderexpectationsContribute to (for a subsystemor simple project) obtainingstakeholder buy-in of validatedexpectationsParticipate in management ofstakeholders expectationsthroughout the project lifecycleDirect (for a system): Validation of stakeholderexpectations statements Baselining of stakeholderexpectationsDirect (for a program): Validation of stakeholderexpectations statements Generation of baselinedstakeholder expectationsAble to (for a system) obtainstakeholder buy-in of validatedexpectationsAble to (for a program) obtainstakeholder buy-in of validatedexpectationsAble to (for a system) managestakeholders expectationsthroughout the project lifecycleAble to (for a program)manage stakeholdersexpectations throughout theproject lifecycleDefine Agency/Centerstakeholder expectationmanagement policiesHQ coursesCenter coursesOJL activities9
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPOther learning activitiesAssessment10
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIPCompetency Area: 2.0 System DesignCompetency: 2.2 Technical Requirements DefinitionCompetency Elementsand Descriptions2.2.1 RequirementsScopea. Analyze scope of thetechnical problemb. Define design andproduct constraints2.2.2 Conversion fromExpectations toRequirementsa. Define functional andbehavioral expectationsin acceptable technicaltermsb. Define the performancerequirements for eachdefined functional andbehavioral expectationc. Define technicalrequirements inacceptable “shall”statements2.2.3 Conversion fromRequirements toTechnical PerformanceMeasuresProficiency Level DescriptionsLevel 1Aware that Design cannot begin untiltechnical scope has beendefined Design and productconstraints will impact theproductContribute to: Conversion of functional andbehavioral expectations intotechnical terms withperformance requirements Expression of technicalrequirements in anacceptable formContribute to definition ofMOPs and TPMsLevel 2Level 3Level 4Aware of technologydevelopmentsAware of technologydevelopmentsAware of technologydevelopmentsContribute to (for asubsystem or simple project)definition of: Technical problem scope Design and productconstraintsAble to (for a subsystem orsimple project): Convert functional andbehavioral expectations intotechnical terms withperformance requirements Express technicalrequirements in anacceptable formAble to define (for a system): Technical problem scope Design and productconstraintsDirect (for a system): Conversion of functional andbehavioral expectations intotechnical terms withperformance requirements Expression of technicalrequirements in anacceptable formAble to define:
ACADEMY OF PROGRAM/PROJECT & ENGINEERING LEADERSHIP Structure of the Systems Engineering Competency Framework The SE Competencies are structured as follows: 1) Competency Areas: These describe, in broad terms, what is expected of Systems Engineer personnel in terms of particular components or functions of the job.
teamwork competencies, strategic action competencies, global awareness competencies, self-management competencies and communication competencies. Strategic action competencies Strategic action competencies refer to the manager’s abilities to grasp the overall strategy of the company and ensure employees’ efforts are in line with the strategy.
2016 nasa 0 29 nasa-std-8739.4 rev a cha workmanship standard for crimping, interconnecting cables, harnesses, and wiring 2016 nasa 0 30 nasa-hdbk-4008 w/chg 1 programmable logic devices (pld) handbook 2016 nasa 0 31 nasa-std-6016 rev a standard materials and processes requirements for spacecraft 2016 nasa 0 32
focused competencies. Competency Area NP Core Competencies Neither Curriculum Content to Support Competencies required nor comprehensive, this list reflects only suggested content specific to the core competencies Scientific Foundation Competencies 1. Critically analyzes data and evidence for improving advanced nursing practice. 2.
focused competencies. Competency Area NP Core Competencies Neither Curriculum Content to Support Competencies required nor comprehensive, this list reflects only suggested content specific to the core competencies Scientific Foundation Competencies 1. Critically analyzes data and evidence for improving advanced nursing practice. 2.
Jan 10, 2012 · The NASA STI program provides access to the NASA Aeronautics and Space Database and its public interface, the NASA Technical Report Server, thus providing one of the largest collections of aeronautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA
The NASA STI program provides access to the NASA Aeronautics and Space Database and its public interface, the NASA Technical Report Server, thus providing one of the largest collections of aero-nautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA
The NASA STI program provides access to the NASA Aeronautics and Space Database and its public interface, the NASA Technical Report Server, thus providing one of the largest collections of aero-nautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA STI Report Series, which includes
The NASA STI program provides access to the NASA Aeronautics and Space Database and its public interface, the NASA Technical Report Server, thus providing one of the largest collections of aero-nautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA STI Report Series, which includes
