程式階段，也可以稱之為編碼階段，是將系統設計階段的設計內容用編碼的方式實現，最終形成可運行的軟體代碼。在這個階段需要在系統設計的框架內按照系統設計文檔進行編碼。這個階段中不僅僅是需要編碼，還需要進行單元測試，每完成一個模組應進行單元測試。最後，進行集成，按軟體組織結構的要求將各個子系統組合起來。
基本介紹
- 中文名：程式階段
- 外文名：program phase
- 學科：計算機
- 定義：設計內容用編碼的方式實現
- 有關術語：軟體生存周期
- 領域：程式設計
簡介,軟體生命周期,功能實現方式,程式語言,軟體開發平台,
簡介
程式階段是將軟體設計的結果轉換成計算機可運行的程式代碼。在程式階段中必須要制定統一，符合標準的編寫規範。以保證程式的可讀性，易維護性，提高程式的運行效率。程式階段是軟體生存周期中的一個階段，是一個軟體系統從理論到實現的過渡階段。程式階段主要與編程語言、功能實現方式和開發平台等因素有關。這兩種選擇關係到軟體系統怎么編碼以及後來怎么調試和維護。程式設計語言的性能和編碼風格在很大程式上影響著軟體的質量和維護性能，即對程式的可靠性、可讀性、可測試性和可維護性產生深遠的影響，所以選擇哪一種程式設計語言和怎樣來編寫代碼是要認真考慮的。
軟體生命周期
同任何事物一樣,一個軟體產品或軟體系統也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟體生存周期（軟體生命周期）。軟體生命周期(SDLC，軟體生存周期)是軟體的產生直到報廢的生命周期。為了使規模大、結構複雜和管理複雜的軟體開發變的容易控制和管理，人們把整個軟體生命周期劃分為若干階段，使得每個階段有明確的任務，整理出軟體生命周期模型。在1970年人類整理了第一個軟體生命周期，即是瀑布型生命周期。在沒有總結到其它生命周期模型時，人們直接將其命名為軟體生命周期，而隨著越來越多的生命周期模型被識別，原先的軟體生命周期就不再是瀑布型生命周期的專有名稱。而在1970年～2000年瀑布型生命周期占統治地位的時候，軟體生命周期是瀑布型生命周期的另一個稱呼，也就是說軟體生命周期指的就是瀑布型生命周期。
瀑布型生命周期包括可行性分析與開發項計畫、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等階段。而其它軟體生命周期未必有與瀑布型生命周期相同的階段。敏捷類生命周期的階段劃分是按照疊代來進行，而疊代內部不再有階段劃分，在如測試驅動開發等的實踐下，就算是更細節的活動也難以明確劃分是需求還是設計還是編碼還是測試。
功能實現方式
功能實現方式是指程式設計採取面向對象編程方式還是採取結構化編程方式，不同的編程方式，程式階段功能實現是有所區別的。
結構化程式設計（英語：Structured programming），一種編程典範。它採用子程式、程式碼區塊（英語：block structures）、for循環以及while循環等結構，來取代傳統的 goto。希望藉此來改善電腦程式的明晰性、品質以及開發時間，並且避免寫出麵條式代碼。結構化程式設計提出的原則可以歸納為32個字：自頂向下，逐步細化；清晰第一，效率第二；書寫規範，縮進格式；基本結構，組合而成。
面向對象編程（Object Oriented Programming，OOP，面向對象程式設計）是一種計算機編程架構。OOP 的一條基本原則是電腦程式是由單個能夠起到子程式作用的單元或對象組合而成。OOP 達到了軟體工程的三個主要目標：重用性、靈活性和擴展性。為了實現整體運算，每個對象都能夠接收信息、處理數據和向其它對象傳送信息。面向對象設計方法以對象為基礎，利用特定的軟體工具直接完成從對象客體的描述到軟體結構之間的轉換。這是面向對象設計方法最主要的特點和成就。面向對象設計方法的套用解決了傳統結構化開發方法中客觀世界描述工具與軟體結構的不一致性問題，縮短了開發周期，解決了從分析和設計到軟體模組結構之間多次轉換映射的繁雜過程，是一種很有發展前途的系統開發方法。
程式語言
程式語言往往使程式設計師能夠比使用機器語言更準確地表達他們所想表達的目的。對那些從事計算機科學的人來說，懂得程式設計語言是十分重要的，因為在當今所有的計算都需要程式設計語言才能完成。
目前發明了許多的程式語言，程式語言本身可能修改以匹配新需求，或是和其他的程式語言結合使用，儘管人們多次試圖創造可以匹配所有需求的通用程式語言，但以“匹配所有需求”的標準來看，這些嘗試都失敗了。之所以有那么多種不同的程式語言存在的原因是，編寫程式的初衷其實也各不相同；新手與老手之間技術的差距非常大，而且有許多語言對新手來說太難學；還有，不同程式之間的運行成本（runtime cost）各不相同。
高級語言的出現使得電腦程式設計語言不再過度地依賴某種特定的機器或環境。這是因為高級語言在不同的平台上會被編譯成不同的機器語言，而不是直接被機器執行。最早出現的程式語言之一FORTRAN的一個主要目標，就是實現平台獨立。
雖然大多數的語言既可被編譯又可被解譯，但大多數僅在一種情況下能夠良好運行。在一些編程系統中，程式要經過幾個階段的編譯，一般而言，後階段的編譯往往更接近機器語言。這種常用的使用技巧最早在1960年代末用於BCPL，編譯程式先編譯一個叫做“0代碼”的轉換程式（representation），然後再使用虛擬器轉換到可以運行於機器上的真實代碼。這種成功的技巧之後又用於Pascal和P-code，以及Smalltalk和二進制碼，在很多時候，中間過渡的代碼往往是解譯，而不是編譯的。
如果所使用的翻譯的機制是將所要翻譯的程式代碼作為一個整體翻譯，並之後運行內部格式，那么這個翻譯過程就被成為編譯。因此，一個編譯器是一個將人可閱讀的程式文本（叫做原始碼）作為輸入的數據，然後輸出執行檔（object code）。所輸出的執行檔可以是機器語言，由計算機的中央處理器直接運行，或者是某種模擬器的二進制代碼。
如果程式代碼是在運行時才即時翻譯，那么這種翻譯機制就被稱作解釋。經解釋的程式運行速度往往比編譯的程式慢，但往往更具靈活性，因為它們能夠與執行環境互相作用。
軟體開發平台
“軟體定製開發平台”在西方已開發國家是為大、中、小公司所廣泛採用的一種軟體開發形式,在企業管理軟體占有40%左右的市場份額，而在我國，由於經濟環境和傳統管理方式的不同，定製軟體還是一種新生事物，不被廣大客戶所認同。實際上，大多數企業由於自身的歷史和業務狀況，對於軟體系統會有自身特殊的要求，尤其是在企業的行業個性化需求和企業自身獨有的個性化需求方面顯得格外迫切，而市場上的通用軟體有很多，但是一方面價格可能對一些企業來說難以承受，另一方面功能只是利用套裝軟體的管理思路及模式，完全是讓客戶按照軟體的業務流程進行現實管理的流程化套用，根本不考慮兼顧到企業的行業及內部個性化需求，這樣就造成了軟體在上線和使用過程中存在著相當嚴重的“水土不服”的現象，市場上有太多的軟體失敗案例，都是因為此種原因造成的，因此不少企業在經歷過失敗的案例後，紛紛轉向定製開發.具體地說，定製開發就是根據企業的具體情況、具體要求來進行設計軟體系統，提供相應的個性化開發服務。隨著企業信息化水平的提高,已經有很多企業意識到了使用專用軟體可以大大提高資金使用率、提高員工的工作效率、降低成本、同現有業務接軌。
軟體開發平台是以遵循軟體工程的相關規範為基礎，以CMM相關質量控制方法為核心思想,對定製開發平台的全過程控制與管理。而不是常規式的“瀑布式” 開發模式，以幫助公司現實的管理提升和業務快速發展擴張的需要。
