User:Markbassett/Sandbox/sandbox3

RS discussion examples

 * Option 2: per WP:USEBYOTHERS tied to BBC et al, and extent of WP acceptance directly cited to on 609 articles; .  And it seems a major WEIGHT media player.


 * Option 2 - per WP:USEBYOTHERS mentioned use by "PBS, USA Today, Reuters, NBC Boston, the Washington Post, etc.", and extent of WP acceptance shown by  5,450 citations to it.  And it seems a major WEIGHT media player.   I would suggest that any use should as always follow WP:CONTEXTMATTERS and the question should be is it a good cite for a line in question.  If it’s an opinion piece, then don’t use it as a fact cite.   I would note WP:RSOPINION and WP:NEWSBLOG should still apply and complaints here about pieces clearly stated as opinion should be mitigated by that.   I would also note the ownership may be something to consider on specific topics, as it should be for any media source.

Systems Engineering
AFSC STANDARD: SYSTEMS ENGINEERING REQUIREMENTS AND PRODUCTS everyspec

Revisit DAU sites, check for deadlinks
 * find DAG article mistitled ... hmm, make guide a redirect and make new guidebook ?

SE Processes (DAG chap 4) includes ... technical assessment, requirements management, risk management, configuration management, ...

traceability matrix,

Overview of the SE Process, ND DOT

TEMP
TEMP, SEP, RMP, CMP ... TEMP - within framework of DID 90106, summarize actuals and official docs to date, or present intended plans and notional estimates as best available, or make statement where material is not available at this point.

MOE/MPS/MOS - not significant enough for articles, ditto specific SMART measure (Specific, Measurable, Achievable, Relevant, Timebound) principle; nor principle to be traceable to system requirements. The taxonomy of measurement types (quality / quantity / timeliness / cost...) and numeric or descriptive is not in WP although the terms are used.


 * TEMP Content - name all test events, roles, etc
 * - Gen test strategy, list tests & short descr; KPPs & measures; OT thoughts

(list of tests, list of terms, list of players, diagrams;
 * (table of test environments Test phase (unit/int/dte), Perf by; env (dev/factory);

( Criteria (informal vs alloc rqmts using written plan; purpose (verify ...), Report (no//Yes) ( USG participation (no, no, witness, as witness, responsible to prep and do
 * (table of CTPs - Supported Capability (interop, avail, access, maint, perf, sec, sys),

technical parameter (nodes rched, avg hrs/day, num simult sesssions...) event (component test, sys test) threshold #, decision supported ..) DTE entry & exit criteria, std (goals per SRTD?) that's just the 'master plan' list... the actual may have some special bits to show

Show the V-9 : VEE model each design step produces item for matching test step
 * OCS [Rqmts Def's (JCIDS)]  Op Need: Measures of Eff and Suitabi [Transition] IOT&E
 * FRD [Rqmts Analysis]      Sys Measures /Of Performance       [Validation] Operational Testing
 * SRD [Logical Analysis]  Allocated Fn &/Perf Rqmts         [Verification] Sys testing
 * ICD [Design Solution]  Component/ Interface Definition [Integration testing]
 * Element
 * Detailed Design <> Conformation Audit (unit test)
 * Design Criteria
 * Staged components
 * onto operational host ...                          ---> Regression test pf A (check nothing else broke
 * X devel -> X sys test -> Install w int'n checks           and then do X operational test
 * (against component SRqmt; Sys meas of perf)
 * Staged components (final)
 * Z devel -> Z systems -> Z install           ---> rerun A regression text, plus that of added X, Y
 * and then do Z operational test
 * Z devel -> Z systems -> Z install           ---> rerun A regression text, plus that of added X, Y
 * and then do Z operational test

Can do modules in any order ... but takes all component OT tokens to admission for program-level IOT&E
 * (gate to full-rate; against OCS for entire SysOfSys; KPP test


 * References -
 * SEP - TEMP content appropriate w. system described there, roles said there, reflect internal coordination

Statement of work (SOW)
Improve so tag can be removed ... unk what that is so paste to TALK and speculate put in what a google finds to match the text, aim for at least one cite per section of article ...

System requirements
(Some quote mining, have to pick/cite...)


 * Any requirement from users for functional operational behavior should decompose to multiple system requirements of technical action which produce that function.


 * Things necessary to running the system or other attributes which do not relate to user visible behavior or products result in additional system requirements.

[could offer example categories - external legal or command items, logistics and maintenance concerns, ...]
 * Overall, system requirements are everything for the functional requirements plus "whatever else is needed" outside of those functional mission needs. The system requirements should state what the "whatever else" is.


 * So each functional requirement will map to system requirements, all system requiremenst shall trace from somewhere, but some system requirements shall trace from outside of functional requirements.

Architecture Frameworks
- gave me lots of DODAF and some like SOA extensions or [www.mitre.org/sites/default/files/pdf/06_0818.pdf Tailoring DODAF for Service-Oriented Architectures] and MODEL-driven views; so many frameworks and Self-adaptive system modeling and Overview of DODAF -- but where's the Data-driven ?
 * External thought - BINGing data-driven views and dodaf architecture compared

- and MODAF and DODAF do not mention each other ... and refs comparing 4 main AFs or 4 main AFs also (Zaxhman, FEA, TOGAF, Gartner), and articles do not display a body of knowledge or context/comparison ...
 * Internal topic issue : Hm, Architecture framework does not mention DODAF

MS Project
There is a wikibook, abandoned ... though there's more than one way to structure such so maybe meh. Mostly I'd want 'hot tips & shortcuts'
 * (Beware X; Easier to hit insert key; ... love compare schedules, fwd/back crit path,

And common topics
 * (Dashboards; Master/subs;  How to baseline;

And Practice / checklist / rules of thumb
 * (point to dynamic scheduling weekly updates/monthly status; how to baseline ;
 * (WBS - edit, billing usage;
 * (norm/ease of dependency; reliability +/-%

other
[SRR ? CDR ? PMO? id ..] Approves the system spec, allocation to hw/sw/human (people. processes, products); ID of all software components (deliverable/non, supports trades); Comprehensive risk assessment; SEP that addresses cost & critical path drivers Approval of ALSP defining support plan & metrics

Review Procedures
Insert specifics and cites and odd terms ...  though articles by individual event compete with the overall topic here... System Design Review Design review (U.S. government)

Various - and adherence depends on the corporate culture of them as much as on the effort itself - e.g. Office of the Deputy Assistant Secretary of Defense Systems Engineering, Template for the Post-Critical Design Review (CDR) Report

Talk:Design review (U.S. government) Solution stack Contract data requirements list
 * Deliverable
 * * deliverable could use some cites and a see also / external refs
 * Data item descriptions
 * CDRL and DID

Risk management MIL-STD-498 DOTMLPF Talk:Uptime Analysis of Alternatives Joint Capabilities Integration Development System Key Performance Parameters Generally Accepted Privacy Principles Initial operating capability Full operational capability PATCOB Functional requirement Defense Acquisition Workforce Improvement Act Defense Acquisition Guide Project management Design for lean manufacturing Talk:Non-functional requirement Functional requirement Requirement SRR Defense Acquisition University

System of record Single Source of Truth Work breakdown structure

Statement of objectives Statement of work Earned value management Hork Risk management plan System of systems Department of Defense Architecture Framework DOD-STD-2167 Concept of operations Mission Need Statement Magic quadrant

System Design Review disambiguation page for DED

Scheduling related page updates
Scheduling itself got recast and now only is timetable ... too narrow MHO but maybe suits common name Hammock activity Schedule (disambiguation) Schedule (project management) Microsoft Project Microsoft Project Server PSP (disambiguation) Planning fallacy Project portfolio management Systems development life cycle Project Management Body of Knowledge or PMBOK

Integrated master plan Iterative and incremental development Incremental build model Waterfall model Systems engineering process Scrum (software development) Rolling Wave planning Primavera Systems GanttProject

Defense Acquisition Guide or DAG

List of project management topics

Integrated Product Support Elements
Replaced the ten Integrated Logistics Support items with twelve new The Twelve IPS Elements and corresponding activities were introduced in the DoD PSM Guidebook in Appendix A and the IPS Elements Guidebook picks up where it left off.
 * DAU search
 * Google for the IPS elements guidebook

The primary difference between the ILS and IPS elements is the addition of two elements. (Product Support Mgmt, Sustaining Engrg) Product Support Management was added due to the creation of the Product Support Manager position and Sustaining Engineering was added in order to carry systems engineering and design interface activities through system sustainment.
 * The Product Support Management element was added to address the creation of the Product Support Manager position as required by Public Law 111-84 and to enable seamless product support package development and execution. The Sustaining Engineering element was added to address continued system engineering and design interface beyond the deployment phase of a system.

Other modification include name changes and expanded definition of some elements.

The guidebook aligns with the PSM guide - objective, description, the activities related, and finally the implementing in the lifecycle with I and J are always training resources and key references.


 * 1) Design Interface. Integration of the quantitative design characteristics of systems engineering (Reliability, Availability, Maintainability, etc.) with the functional logistics elements (i.e., integrated product support elements).
 * 2) Sustaining Engineering. Technical tasks (engineering and logistics investigations and analyses) that ensure continued operation and maintenance of a system with managed risk.
 * 3) Product Support Management. Plan, manage, and fund weapon system product support across all IPS Elements.
 * 4) Supply Support element focuses on the process for identifying, obtaining and delivering the right quantity of repair parts and spares to support scheduled and unscheduled maintenance requirements.
 * 5) Maintenance Planning and Management is key to  identifying the scheduled and unscheduled maintenance tasks for all levels of maintenance, and for identifying all the associated resources.
 * 6) PHS&T integrates with the other IPS Elements to determine packaging, handling, storage and transportation needs, resources, and procedures.

Specialized terms
Terms or phrases with specialized meanings about status ... often implying a formal business process or governance or review board action step.

Engineering V process - the PDR, CDR, SRR, TRR, etc are defined and wiki articles -- and in UK or US military have defined meaning of a review event. But what that event does varies, even among services, and not just in which board does the signoff. A PDR by one may be a superficial dog-n-pony powerpoint PR session; by another is a highly technical walk thru of documents and evidence; by a third as a coordination ... etcetera

Funds stages in budget terms - Proposed (Requested) Budgeted (Appropriated) Allocated, Initiated, Committed, Obligated, Invoiced, Approved, Expended (Outlayed) ... Expired.