User:Markbassett/Sandbox/sandbox3

Notice that you are now subject to an arbitration enforcement sanction

The following sanction now applies to you:

You have been topic banned indefinitely from post-1932 politics of the United States, broadly construed.

You have been sanctioned for long-time disruption of talkpages in the area. I have come to this decision after reading Mr X's detailed posts here and here on your page, as well as your own woefully inadequate response, which suggests you simply don't care if you disrupt talkpages and waste other people's time or not. It's my hope that you will profit from MONGO's advice just above, to "venture outside the realm of politics and current events and find arenas that bring you more joy".

This sanction is imposed in my capacity as an uninvolved administrator under the authority of the Arbitration Committee's decision at Wikipedia:Arbitration/Requests/Case/American politics 2#Final decision and, if applicable, the procedure described at Wikipedia:Arbitration Committee/Discretionary sanctions. This sanction has been recorded in the log of sanctions. If the sanction includes a ban, please read the banning policy to ensure you understand what this means. If you do not comply with this sanction, you may be blocked for an extended period, by way of enforcement of this sanction—and you may also be made subject to further sanctions.

You may appeal this sanction using the process described here. I recommend that you use the arbitration enforcement appeals template if you wish to submit an appeal to the arbitration enforcement noticeboard. You may also appeal directly to me (on my talk page), before or instead of appealing to the noticeboard. Even if you appeal this sanction, you remain bound by it until you are notified by an uninvolved administrator that the appeal has been successful. You are also free to contact me on my talk page if anything of the above is unclear to you. Bishonen | tålk 16:52, 4 August 2020 (UTC)

RS discussion examples

Option 2: per WP:USEBYOTHERS tied to BBC et al, and extent of WP acceptance directly cited to on 609 articles; aninews.in . 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 www.washingtontimes.com 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.

Articles in Systems Engineering

Systems Engineering

AFSC STANDARD: SYSTEMS ENGINEERING REQUIREMENTS AND PRODUCTS everyspec

find DAG article mistitled ... hmm, make guide a redirect and make new guidebook ?

Revisit DAU sites, check for deadlinks

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

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.

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.

[could offer example categories - external legal or command items, logistics and maintenance concerns, ...]

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

External thought - BINGing data-driven views and dodaf architecture compared

- 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 ?

Internal topic issue : Hm, Architecture framework does not mention DODAF

- 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 ...

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

DAU search

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.

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.

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).
Sustaining Engineering. Technical tasks (engineering and logistics investigations and analyses) that ensure continued operation and maintenance of a system with managed risk.
Product Support Management. Plan, manage, and fund weapon system product support across all IPS Elements.
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.
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 .
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.

References

External Links

Category:Living people