- 相關(guān)推薦
一套軟件開(kāi)發(fā)工程師筆試題
軟件開(kāi)發(fā)是一個(gè)很吃香的行業(yè)，下面unjs小編整理了一套軟件開(kāi)發(fā)工程師筆試題，歡迎閱讀!
1、試分析下面的SQL語(yǔ)句的優(yōu)劣，并用另外的方法實(shí)現(xiàn)，
一套軟件開(kāi)發(fā)工程師筆試題
。(1) Select * from empe where e.No in (select a. No from amp a )
Select * from empe e where NOT EXISTS (Select a.No from amp a where e.NO=a.No)
(2) select * from emp e, anp a where e. No=a. No
2、用Decoole 重寫(xiě)下面的socl 語(yǔ)句
SELECT COUNT(*)，SUM(SAL) FROM EMP WHERE DEPT_NO = 0020 AND ENAME LIKE ‘SMITH%’;
select count(*),sum(sal) from emp where dept_no = 0030 and ename like ‘smith%’;
select count(decode(dept_no,0020,’x',null)) d0020_count,
count(decode(dept_no,0030,’x',null)) d0030_count,
sum(decode(dept_no,0020,sal,0)) d0020_sal,
sum(decode(dept_no,0030,sal,0)) d0030_sal
from emp where ename like ‘smith%’;
3、下面哪幾種SQL不好。2,4,5
(1) update 語(yǔ)句 (2)in語(yǔ)句 (3)子查詢(xún) (4)多查等值查詢(xún) (5)笛卡爾乘積
4、請(qǐng)?jiān)斐鱿铝心?種命名正確 A,B,D
A、ASD B、$abc C、const D、_asd E、3_asd
5、texarea java (1)寫(xiě)出文件名 (2)補(bǔ)充代碼
6、型轉(zhuǎn)換
example:
public String getValue(Object a,Object b){}
當(dāng)下列方法調(diào)用時(shí)將出現(xiàn)何種異常,如何修正
String c=new String(“aaa”);
int d =123;
my.getValue(c,d);
(1) Integer d=new Integer(123);
(2) My.getValue(c,(String)d);
7、在JSP上顯示Araylist中的元素
序號(hào) 姓名
8、解釋
beam:遠(yuǎn)程接口的具體實(shí)現(xiàn)
Home:管理和創(chuàng)建遠(yuǎn)程對(duì)象
Romate:提供給用戶(hù)的遠(yuǎn)程接口
9、解釋Javabean與EJB的區(qū)別
10、SeSS’on bean與Entitybean區(qū)別
11、解釋Commend、DAO模式，試舉例說(shuō)明。
Command定義
不少Command模式的代碼都是針對(duì)圖形界面的,它實(shí)際就是菜單命令,我們?cè)谝粋�(gè)下拉菜單選擇一個(gè)命令時(shí),然后會(huì)執(zhí)行一些動(dòng)作，將這些命令封裝成在一個(gè)類(lèi)中,然后用戶(hù)(調(diào)用者)再對(duì)這個(gè)類(lèi)進(jìn)行操作,這就是Command模式,換句話(huà)說(shuō),本來(lái)用戶(hù)(調(diào)用者)是直接調(diào)用這些命令的,如菜單上打開(kāi)文檔(調(diào)用者),就直接指向打開(kāi)文檔的代碼,使用Command模式,就是在這兩者之間增加一個(gè)中間者,將這種直接關(guān)系拗?jǐn)?同時(shí)兩者之間都隔離,基本沒(méi)有關(guān)系了.
顯然這樣做的好處是符合封裝的特性,降低耦合度,Command是將對(duì)行為進(jìn)行封裝的典型模式,Factory是將創(chuàng)建進(jìn)行封裝的模式,
從Command模式,我也發(fā)現(xiàn)設(shè)計(jì)模式一個(gè)”通病”:好象喜歡將簡(jiǎn)單的問(wèn)題復(fù)雜化,
喜歡在不同類(lèi)中增加第三者,當(dāng)然這樣做有利于代碼的健壯性 可維護(hù)性 還有復(fù)用性.
如何使用
具體的Command模式代碼各式各樣,因?yàn)槿绾畏庋b命令,不同系統(tǒng),有不同的做法.下面事例是將命令封裝在一個(gè)Collection的List中,任何對(duì)象一旦加入List中,實(shí)際上裝入了一個(gè)封閉的黑盒中,對(duì)象的特性消失了,只有取出時(shí),才有可能模糊的分辨出:
典型的Command模式需要有一個(gè)接口.接口中有一個(gè)統(tǒng)一的方法,這就是”將命令/請(qǐng)求封裝為對(duì)象”:
程序代碼:
public interface Command { public abstract void execute ( );}
//具體不同命令/請(qǐng)求代碼是實(shí)現(xiàn)接口Command,下面有三個(gè)具體命令
程序代碼:
public class Engineer implements Command {
public void execute( ) { //do Engineer’s command }
}
public class Programmer implements Command {
public void execute( ) { //do programmer’s command }
}
public class Politician implements Command {
public void execute( ) { //do Politician’s command }
}
按照通常做法,我們就可以直接調(diào)用這三個(gè)Command,但是使用Command模式,我們要將他們封裝起來(lái),扔到黑盒子List里去:
程序代碼:
public class producer{
public static List produceRequests() {
List queue = new ArrayList();
queue.add( new DomesticEngineer() );
queue.add( new Politician() );
queue.add( new Programmer() );
return queue; }
}
這三個(gè)命令進(jìn)入List中后,已經(jīng)失去了其外表特征,以后再取出,也可能無(wú)法分辨出誰(shuí)是Engineer
誰(shuí)是Programmer了,看下面如何調(diào)用Command模式:
程序代碼:
public class TestCommand {
public static void main(String[] args) {
List queue = Producer.produceRequests();
for (Iterator it = queue.iterator(); it.hasNext(); )
//取出List中東東,其他特征都不能確定,只能保證一個(gè)特征是100%正確,// 他們至少是接口Command的”兒子”.所以強(qiáng)制轉(zhuǎn)換類(lèi)型為接口
Command((Command)it.next()).execute();
}
}
DAO：
由此可見(jiàn),調(diào)用者基本只和接口打交道,不合具體實(shí)現(xiàn)交互,這也體現(xiàn)了一個(gè)原則,面向接口編程,這樣,以后增加第四個(gè)具體命令時(shí),就不必修改調(diào)用者TestCommand中的代碼了.
12、談一下對(duì)“保障軟件質(zhì)量”的理解。
有效的軟件質(zhì)量管理
一、引言
隨著社會(huì)信息化水平的不斷提高，信息行業(yè)急速膨脹，信息企業(yè)快速成長(zhǎng)，隨之帶來(lái)的信息市場(chǎng)競(jìng)爭(zhēng)激烈，企業(yè)為了求生存，滿(mǎn)足客戶(hù)要求則成為各行各業(yè)的首要責(zé)任。依賴(lài)于質(zhì)量、成本和進(jìn)度的客戶(hù)滿(mǎn)意度，質(zhì)量則是重點(diǎn)支撐之一，這樣要求我們對(duì)質(zhì)量管理需要加強(qiáng)認(rèn)識(shí)。我們都知道pmbok把項(xiàng)目管理劃分為9個(gè)知識(shí)領(lǐng)域，即范圍管理、時(shí)間管理、成本管理、質(zhì)量管理、人力資源管理、溝通管理、采購(gòu)管理、風(fēng)險(xiǎn)管理和綜合管理。質(zhì)量管理作為9大知識(shí)領(lǐng)域之一，可見(jiàn)其重要性。
質(zhì)量管理包括：質(zhì)量計(jì)劃編制、質(zhì)量保證和質(zhì)量控制三個(gè)過(guò)程域。質(zhì)量計(jì)劃是質(zhì)量管理的第一過(guò)程域，它主要結(jié)合各個(gè)公司的質(zhì)量方針，產(chǎn)品描述以及質(zhì)量標(biāo)準(zhǔn)和規(guī)則通過(guò)收益、成本分析和流程設(shè)計(jì)等工具制定出來(lái)實(shí)施方略，其內(nèi)容全面反應(yīng)用戶(hù)的要求，為質(zhì)量小組成員有效工作提供了指南，為項(xiàng)目小組成員以及項(xiàng)目相關(guān)人員了解在項(xiàng)目進(jìn)行中如何實(shí)施質(zhì)量保證和控制提供依據(jù)，為確保項(xiàng)目質(zhì)量得到保障提供堅(jiān)實(shí)的基礎(chǔ)。質(zhì)量保證則是貫穿整個(gè)項(xiàng)目全生命周期的有計(jì)劃和有系統(tǒng)的活動(dòng)，經(jīng)常性地針對(duì)整個(gè)項(xiàng)目質(zhì)量計(jì)劃的執(zhí)行情況進(jìn)行評(píng)估、檢查與改進(jìn)等工作，向管理者、顧客或其他方提供信任，確保項(xiàng)目質(zhì)量與計(jì)劃保持一致。質(zhì)量控制是對(duì)階段性的成果進(jìn)行檢測(cè)、驗(yàn)證，為質(zhì)量保證提供參考依據(jù)，它是一個(gè)PDCA循環(huán)過(guò)程。
二 質(zhì)量管理責(zé)任分配
我們公司在開(kāi)發(fā)項(xiàng)目上按照規(guī)范化軟件的生產(chǎn)方式進(jìn)行生產(chǎn)，在生產(chǎn)流程上采用ISO9000的標(biāo)準(zhǔn)進(jìn)行。每個(gè)項(xiàng)目除配備了項(xiàng)目開(kāi)發(fā)所需角色外，還專(zhuān)門(mén)配備了配置管理小組、測(cè)試小組和質(zhì)量保證小組確保質(zhì)量管理的實(shí)施，下面針對(duì)這三種角色進(jìn)行說(shuō)明：
1、配置管理小組職責(zé)
配置管理小組是保證項(xiàng)目開(kāi)發(fā)完畢的同時(shí)，內(nèi)部文檔和外部文檔都同時(shí)完成。內(nèi)部文檔的及時(shí)產(chǎn)生和規(guī)范，是保證項(xiàng)目開(kāi)發(fā)各小組能夠更好的接口和溝通的重要前提，從另一個(gè)方面講，也是保證工程不被某個(gè)關(guān)鍵路徑所阻塞而延滯的前提。如上所述，配置管理小組還是保證質(zhì)量保證小組得以發(fā)揮作用的基礎(chǔ)。配置管理小組的主要職責(zé)包括： 完善各個(gè)部門(mén)發(fā)送需要存檔和進(jìn)行版本控制的代碼、文檔(包括外來(lái)文件)和階段性成果; 對(duì)代碼、文檔等進(jìn)行單向出入的控制; 對(duì)所有存檔的文檔進(jìn)行版本控制; 提供文檔規(guī)范，并傳達(dá)到開(kāi)發(fā)組中。
2、測(cè)試小組職責(zé)
測(cè)試小組作為質(zhì)量控制的主要手段，負(fù)責(zé)軟件的測(cè)試設(shè)計(jì)和執(zhí)行工作。如同軟件開(kāi)發(fā)一樣，測(cè)試在執(zhí)行之前，同樣需要進(jìn)行測(cè)試計(jì)劃和測(cè)試策略的設(shè)計(jì)，通常情況下測(cè)試可以分為如下幾種類(lèi)型，如：正確性測(cè)試、功能性測(cè)試、性能測(cè)試、安全測(cè)試和系統(tǒng)測(cè)試等。而這些測(cè)試均需要在測(cè)試計(jì)劃和測(cè)試策略中進(jìn)行描述用以指導(dǎo)測(cè)試小組成員進(jìn)行測(cè)試用例編寫(xiě)和測(cè)試執(zhí)行，
資料共享平臺(tái)
《一套軟件開(kāi)發(fā)工程師筆試題》(http://www.oriental01.com)。程序員在交給測(cè)試人員之前是進(jìn)行過(guò)一定的單元測(cè)試，確保程序編譯、運(yùn)行正確。測(cè)試人員根據(jù)詳細(xì)設(shè)計(jì)的文檔對(duì)軟件要實(shí)現(xiàn)的功能進(jìn)行一一測(cè)試，保證軟件的執(zhí)行正確的實(shí)現(xiàn)設(shè)計(jì)要求，在此也只證明了軟件正確的反映了設(shè)計(jì)思想，但是否真正反映了用戶(hù)的需求仍需要進(jìn)一步的功能性測(cè)試。
測(cè)試人員只有根據(jù)軟件需求規(guī)格說(shuō)明書(shū)所提及的功能進(jìn)行檢測(cè)，才能確保項(xiàng)目組開(kāi)發(fā)的軟件產(chǎn)品滿(mǎn)足用戶(hù)需求。在正確性測(cè)試完成之后，需要測(cè)試的是軟件的性能，軟件的性能在本項(xiàng)目中占有重要的地位，性能要求有可能改變軟件的設(shè)計(jì)，為避免造成軟件的后期返工，測(cè)試在性能上需要較大的側(cè)重。如果有必要的話(huà)，測(cè)試小組還需要做安全測(cè)試，以確保系統(tǒng)使用安全可靠。
3、質(zhì)量保證小組職責(zé)
質(zhì)量保證小組作為質(zhì)量保證的實(shí)施小組，主要職責(zé)是保證軟件透明開(kāi)發(fā)的主要環(huán)節(jié)。在項(xiàng)目開(kāi)發(fā)的過(guò)程中幾乎所有的部門(mén)都與質(zhì)量保證小組有關(guān)。質(zhì)量保證小組對(duì)項(xiàng)目經(jīng)理提供項(xiàng)目進(jìn)度與項(xiàng)目真正開(kāi)發(fā)時(shí)的差異報(bào)告，提出差異原因和改進(jìn)方法。
在項(xiàng)目進(jìn)度被延滯或質(zhì)量保證小組認(rèn)為某階段開(kāi)發(fā)質(zhì)量有問(wèn)題時(shí)，提請(qǐng)項(xiàng)目經(jīng)理、項(xiàng)目負(fù)責(zé)人等必要的相關(guān)人員舉行質(zhì)量會(huì)議。解決當(dāng)前存在的和潛在的問(wèn)題。質(zhì)量保證是建立在文檔的復(fù)審基礎(chǔ)之上，因而文檔版本的控制，特別是軟件配置管理，直接影響軟件質(zhì)量保證的影響力和力度。質(zhì)量保證小組的檢測(cè)范圍包括：系統(tǒng)分析人員是否正確的反映了用戶(hù)的需求; 軟件執(zhí)行體是否正確的實(shí)現(xiàn)了分析人員的設(shè)計(jì)思想; 測(cè)試人員是否進(jìn)行了較為徹底的和全面的測(cè)試; 配置管理員是否對(duì)文檔的規(guī)范化進(jìn)行的比較徹底，版本控制是否有效。
三 質(zhì)量管理實(shí)施
有了良好的資源配備，又如何在項(xiàng)目全生命周期內(nèi)實(shí)施質(zhì)量保證，讓我們從以下幾個(gè)方面來(lái)看質(zhì)量保證的實(shí)施過(guò)程：
1、項(xiàng)目進(jìn)度的質(zhì)量保證
項(xiàng)目進(jìn)度是項(xiàng)目進(jìn)行是否順利的最直觀表現(xiàn)。顯然在項(xiàng)目開(kāi)始之前，項(xiàng)目開(kāi)發(fā)計(jì)劃是必須的。如果項(xiàng)目開(kāi)發(fā)計(jì)劃的制定的是完全合理的，那項(xiàng)目進(jìn)度也就真正表達(dá)了項(xiàng)目與最終的交付使用之間的距離，然而要制定完全合理的項(xiàng)目開(kāi)發(fā)計(jì)劃幾乎不太可能�？梢�(jiàn)要保證項(xiàng)目進(jìn)度，首先要保證項(xiàng)目開(kāi)發(fā)計(jì)劃盡可能合理。
項(xiàng)目計(jì)劃的合理程度與項(xiàng)目計(jì)劃制定者從事類(lèi)似規(guī)模和類(lèi)似業(yè)務(wù)的項(xiàng)目的經(jīng)驗(yàn)有直接關(guān)系，通過(guò)經(jīng)驗(yàn)往往能夠預(yù)見(jiàn)潛在的阻礙，這樣要求項(xiàng)目計(jì)劃制定者需要集眾人之力來(lái)完善計(jì)劃。
當(dāng)項(xiàng)目計(jì)劃制定初期，由質(zhì)量保證小組組織召開(kāi)的項(xiàng)目計(jì)劃評(píng)審會(huì)，邀請(qǐng)公司技術(shù)專(zhuān)家、用戶(hù)以及項(xiàng)目組小組成員一起討論項(xiàng)目計(jì)劃的可行性，會(huì)議通常采用頭腦風(fēng)暴法，各抒己見(jiàn)，會(huì)后由指定的記錄員形成質(zhì)量記錄，發(fā)送給相關(guān)人員，對(duì)其計(jì)劃中不合理的地方進(jìn)行修改完善，并由質(zhì)量保證人員對(duì)其結(jié)果跟蹤，以確保項(xiàng)目計(jì)劃完整性、可行性，完善后的計(jì)劃交由配置管理人員進(jìn)行版本控制。
然而在計(jì)劃實(shí)施過(guò)程中，計(jì)劃不是“固定化”。常有人道，“計(jì)劃趕不上變化”，但“要跟上變化”。項(xiàng)目計(jì)劃以里程碑為界限，將整個(gè)開(kāi)發(fā)周期劃分為若干階段。根據(jù)里程碑的完成情況，適當(dāng)?shù)恼{(diào)整每一個(gè)較小的階段的任務(wù)量和完成的任務(wù)時(shí)間，這種方式非常有利于整個(gè)項(xiàng)目計(jì)劃的動(dòng)態(tài)調(diào)整。也利于項(xiàng)目質(zhì)量保證的實(shí)施。
實(shí)際運(yùn)作中，當(dāng)質(zhì)保小組發(fā)現(xiàn)計(jì)劃實(shí)施的差異后，報(bào)告項(xiàng)目經(jīng)理，由項(xiàng)目經(jīng)理組織負(fù)責(zé)對(duì)計(jì)劃進(jìn)行周期性維護(hù)，對(duì)于已經(jīng)變動(dòng)的計(jì)劃由質(zhì)保小組協(xié)助配置管理小組完成版本控制。本公司已經(jīng)開(kāi)發(fā)湖南移動(dòng)的集中客服系統(tǒng)，開(kāi)發(fā)中的子項(xiàng)目多達(dá)六個(gè)，歷時(shí)十個(gè)月，目前多數(shù)項(xiàng)目已經(jīng)開(kāi)發(fā)完畢，系統(tǒng)正在試運(yùn)行階段，項(xiàng)目金額數(shù)千萬(wàn)元。在這樣的項(xiàng)目中，從管理者到開(kāi)發(fā)人員到測(cè)試人員都積累了較為豐富的經(jīng)驗(yàn)，特別是項(xiàng)目開(kāi)發(fā)計(jì)劃的制定，和項(xiàng)目進(jìn)度的控制。
2、項(xiàng)目開(kāi)發(fā)各階段的質(zhì)量保證
a、需求分析
需求分析是開(kāi)發(fā)人員對(duì)系統(tǒng)需要做什么和如何做的定義過(guò)程。從系統(tǒng)分析的經(jīng)驗(yàn)來(lái)看，這個(gè)過(guò)程往往是個(gè)循序漸進(jìn)的過(guò)程，一次性對(duì)系統(tǒng)形成完整的認(rèn)識(shí)是困難的。只有不斷地和客戶(hù)領(lǐng)域?qū)＜疫M(jìn)行交流確認(rèn)，方能逐步明了用戶(hù)的需求。從系統(tǒng)開(kāi)發(fā)的過(guò)程得知，系統(tǒng)分析時(shí)犯下的錯(cuò)誤，會(huì)在接下來(lái)的階段被成倍的放大，越是在開(kāi)發(fā)的后期，糾正分析時(shí)犯下的錯(cuò)誤所花費(fèi)的代價(jià)越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。
解決系統(tǒng)分析錯(cuò)誤的方法我們公司通常采用邀請(qǐng)用戶(hù)參與進(jìn)行需求評(píng)定，然后對(duì)其用戶(hù)的意見(jiàn)由質(zhì)保成員跟蹤檢測(cè)是否納入需求規(guī)格說(shuō)明書(shū)，同時(shí)與用戶(hù)簽字確認(rèn)形成需求基線(xiàn)，交由配置管理員放入配置管理庫(kù)。
雖然盡早的邀請(qǐng)用戶(hù)參與，仍然避免不了項(xiàng)目進(jìn)行中用戶(hù)的需求變更請(qǐng)求。對(duì)于開(kāi)發(fā)過(guò)程存在的需求變動(dòng)，我們要求用戶(hù)填寫(xiě)變更申請(qǐng)單發(fā)送給項(xiàng)目配置管理員，在通過(guò)配置配置員轉(zhuǎn)交質(zhì)保小組，負(fù)責(zé)組織專(zhuān)家小組和項(xiàng)目組成員一起討論實(shí)施變更的可行性及實(shí)施后所帶來(lái)的影響，小的變更則直接記錄入變更記錄原因分析項(xiàng)和風(fēng)險(xiǎn)項(xiàng)欄，大的變更則需要形成正式的變更報(bào)告，無(wú)論那種變更都需要對(duì)相應(yīng)的文檔實(shí)施同步變更(包括需求規(guī)格說(shuō)明書(shū)、詳細(xì)設(shè)計(jì)文、安裝手冊(cè)、操作手冊(cè)等)。但是對(duì)于無(wú)法實(shí)現(xiàn)或是變更會(huì)帶來(lái)巨大的影響而將導(dǎo)致進(jìn)度的延期，這時(shí)，我們將變更報(bào)告提交給用戶(hù)或邀請(qǐng)用戶(hù)進(jìn)行協(xié)調(diào)會(huì)議，討論變更取舍問(wèn)題或是項(xiàng)目進(jìn)度變更問(wèn)題。
決定變更之后，由項(xiàng)目經(jīng)理組織實(shí)施變更，測(cè)試人員檢測(cè)變更結(jié)果，而質(zhì)保小組成員監(jiān)督變更實(shí)施過(guò)程并協(xié)助配置管理員對(duì)變更后的成果物進(jìn)行版本控制。變更實(shí)施完后，上線(xiàn)前還需要指定人員協(xié)助用戶(hù)一同測(cè)試并由用戶(hù)簽字后同意方可上線(xiàn)。
b、系統(tǒng)設(shè)計(jì)
優(yōu)良的體系結(jié)構(gòu)應(yīng)當(dāng)具備可擴(kuò)展性和可配置性，而好的體系結(jié)構(gòu)則需要好的設(shè)計(jì)方法，自然設(shè)計(jì)選型成為了系統(tǒng)設(shè)計(jì)首要的工作，究竟是采用哪種設(shè)計(jì)方法好呢?
對(duì)于設(shè)計(jì)選型不能一概而論，需要針對(duì)項(xiàng)目的結(jié)構(gòu)、項(xiàng)目的特征和用戶(hù)的需求來(lái)分析，同樣也要考慮到參與項(xiàng)目小組成員的素質(zhì)，如果其中大部分都沒(méi)有從事過(guò)面向?qū)ο蟮脑O(shè)計(jì)且項(xiàng)目進(jìn)對(duì)緊迫，這樣沒(méi)有多余的時(shí)間來(lái)培訓(xùn)小組成員來(lái)掌握面向?qū)ο蟮脑O(shè)計(jì)方法，盡管眾所周知面向?qū)ο笤O(shè)計(jì)方法的優(yōu)勢(shì)，我們還是不如采用面向過(guò)程的方式(除用戶(hù)指定開(kāi)發(fā)設(shè)計(jì)方式外)可以減少項(xiàng)目承擔(dān)的技術(shù)風(fēng)險(xiǎn)。
我們公司有過(guò)一個(gè)項(xiàng)目，用戶(hù)指定需要采用面向?qū)ο蠓治觥⒃O(shè)計(jì)和開(kāi)發(fā)，且開(kāi)發(fā)周期短，在無(wú)賴(lài)的情況下，項(xiàng)目小組只能選用面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程，由于項(xiàng)目小組很少?gòu)氖逻^(guò)面向?qū)ο蟮拈_(kāi)發(fā)，經(jīng)驗(yàn)缺乏，導(dǎo)致項(xiàng)目上馬后項(xiàng)目進(jìn)度延誤，項(xiàng)目沒(méi)有達(dá)到預(yù)期的效果。
針對(duì)此次開(kāi)發(fā)，我們分析其原因，發(fā)現(xiàn)小組成員在開(kāi)發(fā)過(guò)程中對(duì)于新技術(shù)互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導(dǎo)致工作重復(fù)性高，滯后項(xiàng)目進(jìn)度。建議解決方法是項(xiàng)目組成員采用集中辦公，分塊學(xué)習(xí)，學(xué)習(xí)的成果馬上向項(xiàng)目相關(guān)人員發(fā)布，再由配置管理員對(duì)其發(fā)布的文檔進(jìn)行整理、規(guī)類(lèi)放入配置庫(kù)以供大家共享。這樣方便大家的互相學(xué)習(xí)，減少重復(fù)的工作。在這次開(kāi)發(fā)中我們公司從管理人員、設(shè)計(jì)人員到開(kāi)發(fā)人員都汲取了很多教訓(xùn)，同時(shí)經(jīng)過(guò)此次項(xiàng)目的開(kāi)發(fā)，小組成員也積累了豐富的面向?qū)ο蟮拈_(kāi)發(fā)經(jīng)驗(yàn)。
除設(shè)計(jì)選型，還有一個(gè)容易被忽視的問(wèn)題，就是公共類(lèi)開(kāi)發(fā)。公共類(lèi)開(kāi)發(fā)可以減少工作中的重復(fù)工作，降低開(kāi)發(fā)成本。這要求我們?cè)僭O(shè)計(jì)階段通過(guò)對(duì)用戶(hù)需求的仔細(xì)研究，盡可能的識(shí)別出公共類(lèi)，并進(jìn)行定義指定專(zhuān)人負(fù)責(zé)設(shè)計(jì)通知其它設(shè)計(jì)人員，以減少重復(fù)工作。對(duì)于項(xiàng)目組提供的設(shè)計(jì)文檔，由質(zhì)保小組組織技術(shù)專(zhuān)家、項(xiàng)目組設(shè)計(jì)人員、開(kāi)發(fā)人員和測(cè)試人員對(duì)其設(shè)計(jì)文檔的評(píng)審，檢測(cè)設(shè)計(jì)文檔對(duì)其下一階段工作的可行性，及時(shí)發(fā)現(xiàn)設(shè)計(jì)中可能存在的錯(cuò)誤，降低項(xiàng)目開(kāi)發(fā)風(fēng)險(xiǎn)，同時(shí)確保設(shè)計(jì)文檔能為開(kāi)發(fā)人員、測(cè)試人員提供切實(shí)的指導(dǎo)。對(duì)于可復(fù)用的設(shè)計(jì)進(jìn)行提取作為公共庫(kù)設(shè)計(jì)和開(kāi)發(fā)，提供項(xiàng)目組或整個(gè)公司重用。最后交由配置管理員進(jìn)行設(shè)計(jì)文檔的版本控制。
c、實(shí)現(xiàn)
實(shí)現(xiàn)也就是代碼的生產(chǎn)過(guò)程。這里不僅包括代碼的產(chǎn)生，同時(shí)也包括測(cè)試用例的產(chǎn)生。針對(duì)上一階段提供詳細(xì)設(shè)計(jì)，程序員開(kāi)始編碼并且調(diào)試程序，測(cè)試人員則根據(jù)設(shè)計(jì)進(jìn)行測(cè)試用例的設(shè)計(jì)，設(shè)計(jì)出來(lái)的用例需要得到項(xiàng)目組成員認(rèn)可由項(xiàng)目經(jīng)理審核通過(guò)才能進(jìn)入配置庫(kù)。同時(shí)程序員調(diào)試完程序提交測(cè)試人員進(jìn)行程序正確性檢測(cè)。
d、文檔管理
文檔維護(hù)主要是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。
內(nèi)部文檔包括： 項(xiàng)目開(kāi)發(fā)計(jì)劃; 需求分析; 體系結(jié)構(gòu)設(shè)計(jì)說(shuō)明; 詳細(xì)設(shè)計(jì)說(shuō)明; 構(gòu)件索引; 構(gòu)件成分說(shuō)明; 構(gòu)件接口及調(diào)用說(shuō)明; 組件索引; 組件接口及調(diào)用說(shuō)明; 類(lèi)索引; 類(lèi)屬性及方法說(shuō)明; 測(cè)試報(bào)告; 測(cè)試統(tǒng)計(jì)報(bào)告; 質(zhì)量監(jiān)督報(bào)告; 源代碼; 文檔分類(lèi)版本索引; 軟件安裝打包文件。
外部文檔主要包括： 軟件安裝手冊(cè); 軟件操作手冊(cè); 在線(xiàn)幫助; 系統(tǒng)性能指標(biāo)報(bào)告; 系統(tǒng)操作索引。
如何保證文檔的全面性，使其真正為項(xiàng)目的進(jìn)度提供保證，又不因?yàn)槲臋n的寫(xiě)作而耽誤項(xiàng)目的進(jìn)度，這仍然是一個(gè)比較難解決的問(wèn)題。解決此問(wèn)題，其核心仍然是個(gè)”度”的問(wèn)題。在本項(xiàng)目的開(kāi)發(fā)中，配置管理小組的一個(gè)非常重要的任務(wù)還是書(shū)寫(xiě)文檔規(guī)范和文檔模板。當(dāng)有文檔模板后需要書(shū)寫(xiě)文檔的人員只剩下”填空”的工作，從某種意義上講，書(shū)寫(xiě)文檔的速度會(huì)加快。如果書(shū)寫(xiě)文檔的人員認(rèn)為文檔的更細(xì)致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時(shí)文檔并不算被正式提交，當(dāng)他人書(shū)寫(xiě)完畢之后，必須由文檔的初寫(xiě)者進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^(guò)后方可以正式提交，進(jìn)入軟件配置管理的循環(huán)中。
配置管理小組真正核心的工作是對(duì)文檔的組織管理。根據(jù)文檔的不同，文檔的來(lái)源也不同，有些是通過(guò)質(zhì)量保證小組經(jīng)過(guò)復(fù)審之后轉(zhuǎn)交給配置管理小組，有些則會(huì)直接從文檔的出處到達(dá)配置管理小組。文檔的管理是一個(gè)非常煩瑣的工作，但是長(zhǎng)遠(yuǎn)來(lái)看它不僅使項(xiàng)目的開(kāi)發(fā)對(duì)單個(gè)主要人員的依賴(lài)減少，從而減少人員流動(dòng)給項(xiàng)目的帶來(lái)的風(fēng)險(xiǎn)，更重要的是在項(xiàng)目進(jìn)行到后百分之十的時(shí)候起到拉動(dòng)項(xiàng)目的作用。
從以往做大項(xiàng)目的經(jīng)驗(yàn)來(lái)看，寫(xiě)作文檔在項(xiàng)目開(kāi)發(fā)的早期可能會(huì)使項(xiàng)目的進(jìn)度比起不寫(xiě)文檔要稍慢，但隨著項(xiàng)目的進(jìn)展，各個(gè)部門(mén)需要配合越來(lái)越多，開(kāi)發(fā)者越來(lái)越需要知道其他人員的開(kāi)發(fā)思路和開(kāi)發(fā)過(guò)程，才能使自己的開(kāi)發(fā)向前推進(jìn)。一個(gè)明顯的例子就是系統(tǒng)整合，或者某些環(huán)節(jié)是建立在其他環(huán)節(jié)完成的基礎(chǔ)之上時(shí)，就更顯現(xiàn)出文檔交流的準(zhǔn)確性和高效性。
3、系統(tǒng)維護(hù)質(zhì)量保證
在我們公司，維護(hù)小組的任務(wù)一方面是保證對(duì)項(xiàng)目客戶(hù)的跟蹤服務(wù)，另一方面是確保該項(xiàng)目其它的開(kāi)發(fā)人員從項(xiàng)目中盡快的解脫出來(lái)以便投入到下一個(gè)項(xiàng)目的開(kāi)發(fā)中。所以通常項(xiàng)目維護(hù)小組成員主要由項(xiàng)目組的少部分開(kāi)發(fā)人員承擔(dān)完成。他們不僅了解軟件的核心內(nèi)容，而且與客戶(hù)也不陌生，以便能夠以最快的速度修正錯(cuò)誤。對(duì)于一般性的錯(cuò)誤，如操作不當(dāng)?shù)纫鸬膯?wèn)題，全部由維護(hù)小組執(zhí)行完成，但需要用戶(hù)測(cè)試確認(rèn)上線(xiàn)。如果較大的修改則需要走變更控制流程，用戶(hù)或者維護(hù)人員填寫(xiě)變更申請(qǐng)，經(jīng)專(zhuān)家會(huì)議討論分析可行方案在由維護(hù)小組實(shí)施，通過(guò)測(cè)試后方可提交用戶(hù)。
維護(hù)小組的人員基本上是按項(xiàng)目跟進(jìn)的。當(dāng)一個(gè)項(xiàng)目剛剛交付用戶(hù)時(shí)，在維護(hù)小組有較多的人員進(jìn)行跟進(jìn)，隨軟件的穩(wěn)定，跟進(jìn)的人逐步減少，并轉(zhuǎn)移到其它項(xiàng)目中去。
13 3.給出一個(gè)MVC結(jié)果圖，請(qǐng)簡(jiǎn)單用文字對(duì)他進(jìn)行一次前后臺(tái)交互的描述。(這個(gè)圖你去找啦)
14 PowerDesigner
15 項(xiàng)目經(jīng)驗(yàn)
16 三層結(jié)構(gòu)的理解
【一套軟件開(kāi)發(fā)工程師筆試題】相關(guān)文章：
軟件開(kāi)發(fā)工程師崗位職責(zé)（精選13篇）03-11
阿里巴巴實(shí)習(xí)生測(cè)試開(kāi)發(fā)工程師筆試題目09-29
判斷筆試題03-13
強(qiáng)生筆試題03-13
德勤的筆試題（附匯豐銀行的筆試題）03-13
智力類(lèi)筆試題08-14
名企筆試題11-04
Java基礎(chǔ)筆試題07-06
IBM筆試題目05-02
經(jīng)歷的筆試題目03-13