1. 什麼是引數資料項檔案（parameter data item file）？
舉個例子，有時候我們做軟體的時候，有可能軟體本身用到的一些引數會經常變動，針對這些引數，常見的有三種做法。第一，最不方便的做法，把這些引數在程式中寫死，每次修改引數的時候開啟源**進行修改，其實這種做法在**格式比較規範、修改又不頻繁的情況下也還是可以接受的。比如把所有引數變數集中解除安裝乙個源**檔案中，這樣每次修改也比較好找；第二，把引數作為初始化的動態輸入項，由初始化函式從外部讀入，一般這種做法需要有輸入介面，我們原來寫pc程式經常這麼做，只要在輸入ui介面中將所需值填入即可；第三，對於嵌入式軟體，或者說沒有輸入介面，而且前期更改幾次，一旦確定後基本不太更改的情況下，使用輸入檔案是最好的方法。也就是說，以一定的格式把所需資料寫入某個txt檔案或規定格式的檔案中，程式執行前自動去該檔案中獲取所需要的引數值即可。pc軟體中常用的xml輸入檔案就是其中一種。飛機上，各種各樣的配置表就屬於這一類。引數資料檔案中的每一項資料被稱為引數資料項。
2. 什麼是驗證？
verification and validation.我們通常說的驗證和確認。容易搞混淆的，乙個概念是驗證和確認，另乙個是驗證和測試。驗證和確認都是比較大的概念，是一種確認物件是否正確的方法，它可能包括評審、分析、測試、**等等不同手段。所以說，測試僅僅只是支援驗證或支援確認的一種方法。do-178c中不提確認（validation），所以我們就先說驗證。計畫階段要求寫驗證計畫，那麼驗證計畫中就需要具體寫我的五份計畫檔案採用什麼方法來驗證（如計畫評審）、需求採用什麼方法來驗證（如需求評審），等等。實際上，在目標**出來之前，因為無法測試，所以基本都是採用評審的方法（當然有工具的話也可以進行**），計畫評審、需求評審、設計評審、**評審等都屬於這一類。之後會有基於需求的測試、測試覆蓋率分析（這是分析方法），等等，具體按照178c的目標要求執行。每種方法還要寫清楚進入的時機和準則，記錄的方法等等。
那麼驗證和確認什麼區別呢？學過系統工程的知道有這麼兩句話，驗證就是do things right（正確的做事）， 確認是do right things（做正確的事）. 具體怎麼講呢？拿確認來說，我怎麼知道我做的事情是不是正確呢？當然是靠使用者需求來判斷。使用者說我的需求是從西安飛到北京，那麼最後只要到了北京，而且是飛去的，那就算做了正確的事。至於怎麼做，選南航還是選東航，那是屬於驗證的事。換句話說，針對使用者需求的驗證就是確認。那178c中為什麼沒有確認呢？因為軟體的需求是系統分配的，也就是說，使用者需求從某種層面來講可以認為是系統需求。而對系統需求的驗證是在系統級別要做的事情，軟體不需要做，也就不用提確認的事情了。
3. 追蹤資料的重要性？都包括哪些？
追蹤資料能幫助梳理高層需求、底層需求（設計）、源**之間的一致性，還能在影響分析的時候幫助確定受影響範圍。從需求到**的正向追蹤可以證明每條需求都進行了實現，反向追蹤能證明沒有多餘**產生。
追蹤資料報括高層需求和低層需求之間、低層需求和源**之間、所有需求和測試用例之間、測試用例和測試程式之間、測試程式和測試結果之間的雙向追蹤。
5. 適航聯絡過程如何做？
適航聯絡過程主要是tc申請人的責任，軟體**商的職責僅僅是支援。如果只是為了寫psac，那麼相應章節只需要提到psac、sci、sas的局方提交，其餘檔案可以應局方要求進行提供（提供可以包括提交和現場供查兩種方式），以及對soi審查的支援，其餘聯絡責任由tc申請人承擔即可。
對於tc申請人來說，適航聯絡過程就包含更多的內容，但具體過程是乙個case by case的情況。需要完成的包括，與局方商定機載軟體的適航符合性方法、與局方的日常溝通方式的確立、四次soi審查的方式（哪些桌面審查，哪些現場審查，哪些局方確認要參與，哪些交由der執行等等），審查通過的形式等等。具體商定的方式不限定，應與局方審查組共同商議決定。
軟體需求評審 過程階段評審
過程階段評審，無評審，不過關！還記得在我們還是學生的年代，每次考試交卷前都會檢查好幾遍，生怕錯漏了什麼，實際上就是開展了一次評審活動，評審的人是你，評審的物件是那份卷子，評審的目的是為了發現問題並修改。在軟體生產過程中，涉及到一道道環節，軟體生命週期從專案啟動到需求，緊跟著設計，然後開發，之後測試，...
軟體測試和QA
qa和測試是不一樣的。軟體測試是軟體開發過程中的乙個環節。專案可行性分析，需求分析，概要詳細設計，編碼，測試，維護，是乙個軟體在開發過程中所必需經歷的階段。而軟體測試是其中必不可少的乙個環節。他是針對已經開發完成或者某個模組已經完成軟體進行測試。通過執行程式來找出軟體bug的過程。qa是以乙個第三方...
軟體需求設計評審須知的8大注意
一 注意對需求規格說明的正確性進行評審 需求規格說明的正確性通常可以從如下方面得以體現 是否有需求與其他需求相互衝突或者重複？通常乙份長達幾百頁的需求規格說明書都不會是一蹴而就的，它可能是系統分析師幾個夜晚的心血之作。正是因為撰寫過程的連續性，可能導致同乙份文件中前後名詞定義不一致，前後觀點上有重疊...