4.1 硬件文檔撰寫思路
1)首先是需求定義或產品規(guī)格:
如果這些是產品最終目標的話,那么產品對硬件和軟件的要求就是技術方案的最終目標;對硬件和軟件的要求是從定義用戶界面和系統功能開始的。
2)其次,根據需求,系統整體定義文檔中給出硬件接口的具體定義:
定義硬件最有效的方法是從需求開始描述,由于硬件必須支持系統定義的所有功能,因此硬件定義是與系統說明不可分割的;
例如,我們設計一個定時器(事先需求說明定時器不能與個人電腦連接,故無法使用CRT顯示時間),我們只有兩種選擇:一種是使用發(fā)光二極管(LED),另一種是使用液晶顯示器件(LCD);盡管LCD的顯示效果比較好,但考慮到定時器要常年位于戶外,并且早期LCD顯示器不能在低溫下工作,最終還是選擇 LED設備(這整個過程描述了我們硬件選型時的一個思路,這個是密切跟需求掛鉤的)
3)一旦完成了系統整體說明文檔,就開始進行系統設計:
首先要對硬件說明的內容進行細化,包括添加能讓工程師理解的設計意圖,以及軟件工程師圍繞硬件進行程序設計時需要使用的硬件信息等。
完成硬件電路板說明文檔后,我們還要在該文檔中增加一個用來描述系統的原始要求的前言部分,包括說明方案的設計思路和方法,除此之外,還要附上軟件工程師用來對硬件進行控制所需的各類信息,這類信息主要包括如下內容(軟件工程所需信息):
-----內存和I/O端口地址(如果需要,還可以提供內存映射圖)
-----可用內存容量
-----狀態(tài)寄存器每一位的定義
-----每個端口管腳的用途
-----外部設備的驅動方法(例如,說明輸入定時器電路的時鐘頻率等)
-----其他有管軟件人員設計程序需要了解的信息
對于比較復雜的系統來說,硬件文檔中經常使用兩個獨立的部分來進行說明;其第一部分用來描述硬件指標和工作原理,第二部分則主要為軟件人員提供程序設計需要的信息。
4.2 軟件文檔撰寫思路
1) 軟件文檔與硬件文檔的組織方法類似,軟件要求文檔的主要內容則是定義軟件要實現的功能;一種是在簡單項目設計過程中,軟件定義也可以只對一種電路板使用的軟件給予描述;對較復雜的項目來說,由于參與這種項目的軟件人員分別負責設計驅動不同硬件部分的代碼(同一電路板),因此每個軟件人員可能會為自己的設計代碼指定不同的定義,這類軟件說明需要提供下列的內容:
-----論述包括需求定義、工程指標、硬件參數等實施項目需要的內容
-----說明軟件之間、處理器之間或處理器與其內部器件之間使用的通信協議:其內容應包括對緩沖區(qū)接口機制、命令/應答協議、信號控制等協議的具體說明。
-----借助流程圖、偽代碼或者其他可能的方法來描述軟件的實現方法和過程
2) 軟件與硬件所考慮的不同之處(此經驗方便技術總監(jiān)或其他相關管理者參考,因為無論是多高深的技術管理者,要么是硬件出身,要么是軟件出身,要么就是非技術出身,armjishu.com里面有少數軟硬件都精通的高手)
a. 軟件的靈活性遠遠大于硬件,要讓軟件人員搞清楚某個軟件的內部格式是非常困難的任務,解決的辦法:詳細定義其他程序員需要了解的編程接口具體內容,以及其他工程人員在實施開發(fā)項目過程中需要使用的技術細節(jié)信息。
b. 軟件工程師只有在收到硬件說明文檔后,才有可能知道如何對系統硬件進行操作;而硬件人員一般不需要了解軟件程序的技術細節(jié)。
c. 由于軟件易于更改,因此程序內容經常會按銷售人員提供的要求發(fā)生變更,在某些情況下,軟件文檔的內容無法及時反映程序的最新變化。
d. 軟件經常是工程項目最后完成的部分,因此其文檔也經常因時間不夠而欠缺完整。實際上,軟件文檔是否詳細、完整,在某種程度上是與公司或客戶的要求有關的。例如,軍事或國家工程一般要求開發(fā)商就其所有軟件實現的功能提供全面詳細的文檔
e. 有個潛規(guī)則,對軟件的要求越復雜,則需求的正確可能性就越小,這個是經驗之談了,我們需要把準需求這個準繩來做文章,而不是陷入個人主義以及對軟件要求而憑空發(fā)揮自己不切實際的想象。
f. 我們可以先硬件設計,接著圍繞該硬件編制軟件。雖然實際系統的實現過程可能是軟硬件并行開發(fā),但軟件人員基本上也是圍繞著已經實現的硬件來進行程序設計的;對于更為復雜的系統來說,開發(fā)過程可能會出現重復。
例如,某個項目的硬件工程師和軟件工程師可能會坐下來開會,共同決定使用哪種硬件來實現某種功能;軟件人員可能提出需要為數據緩沖區(qū)口沖內存容量,也可能要求提供某種外部設備接口,以便充分利用現成接口程序提供的各種驅動代碼。
總的來說,必須在提高軟件開發(fā)效率與硬件系統的復雜性與成本之間進行權衡。
評論