09---設(shè)計文檔化

1、第一頁，編輯于星期五：二十一點 三十分。第一頁，編輯于星期六：十二點 十八分。outline設(shè)計描述文檔評審與設(shè)計評審集成測試方案設(shè)計階段的配置管理第二頁，編輯于星期五：二十一點 三十分。第二頁，編輯于星期六：十二點 十八分。設(shè)計描述文檔的目的describes the functional structure, data, and algorithms to be implemented, identifies required system resources, can be used to assess the impact of requirements changes, assist

2、 in producing test cases, can be used to verify compliance with requirements, and will aid in maintenance activities第三頁，編輯于星期五：二十一點 三十分。第三頁，編輯于星期六：十二點 十八分。什么是好的設(shè)計描述文檔好的設(shè)計文檔可以幫助開發(fā)者 “整理清楚個人的思路。好的設(shè)計文檔可以幫助團(tuán)隊“有效的交流溝通。第四頁，編輯于星期五：二十一點 三十分。第四頁，編輯于星期六：十二點 十八分。為什么要有設(shè)計文檔模板好的模板不是固化而是引導(dǎo)開發(fā)者的思路。好的模板可以提供文檔的一致性、可讀性。

3、第五頁，編輯于星期五：二十一點 三十分。第五頁，編輯于星期六：十二點 十八分。設(shè)計概念定義第六頁，編輯于星期五：二十一點 三十分。第六頁，編輯于星期六：十二點 十八分。高層視角第七頁，編輯于星期五：二十一點 三十分。第七頁，編輯于星期六：十二點 十八分。設(shè)計元素第八頁，編輯于星期五：二十一點 三十分。第八頁，編輯于星期六：十二點 十八分。第九頁，編輯于星期五：二十一點 三十分。第九頁，編輯于星期六：十二點 十八分。設(shè)計描述文檔模板 ieee 1016-1998introductiondesign overviewrequirements traceability matrixsystem ar

4、chitectural designchosen system architecturediscussion of alternative designssystem interface descriptiondetail description of componentscomponent ncomponent n+1user interface designdescription of the user interfacescreen imageobjects and actionsadditional material第十頁，編輯于星期五：二十一點 三十分。第十頁，編輯于星期六：十二點

5、十八分。設(shè)計文檔模板要素frontspiecedate of issue and statusissuing organizationauthorshipchange historyintroductionpurposescopecontextsummaryreferencesglossarybodyidentified stakeholders and design concernsdesign viewpoint 1design view 1design viewpoint ndesign view ndesign rationale第十一頁，編輯于星期五：二十一點 三十分。第十一頁，編輯

6、于星期六：十二點 十八分。sdd樣例大學(xué)網(wǎng)絡(luò)校友數(shù)據(jù)庫第十二頁，編輯于星期五：二十一點 三十分。第十二頁，編輯于星期六：十二點 十八分。ieee software document definitionssqap software quality assurance plan ieee 730scmp software configuration management plan ieee 828std software test documentation ieee 829srs software requirements specification ieee 830svvp software

7、 validation & verification plan ieee 1012sdd software design description ieee 1016spmp software project management plan ieee 1058第十三頁，編輯于星期五：二十一點 三十分。第十三頁，編輯于星期六：十二點 十八分。defect amplification and removalibm81 “implementing software inspections第十四頁，編輯于星期五：二十一點 三十分。第十四頁，編輯于星期六：十二點 十八分。第十五頁，編輯于星期五：二

8、十一點 三十分。第十五頁，編輯于星期六：十二點 十八分。why you want to avoid reviews第十六頁，編輯于星期五：二十一點 三十分。第十六頁，編輯于星期六：十二點 十八分。types of model reviewthere are different “flavors of model review. a requirements review is a type of model review in which a group of users and/or recognized experts review your requirements artifacts.

9、 the purpose of a user requirement review is to ensure your requirements accurately reflect the needs and priorities of your user community and to ensure your understanding is sufficient from which to develop software. similarly an architecture review focuses on reviewing architectural models and a

10、design review focuses on reviewing design models. as you would expect the reviewers are often technical staff. 第十七頁，編輯于星期五：二十一點 三十分。第十七頁，編輯于星期六：十二點 十八分。informal reviewdesk checkcasual meetingreview oriented aspects of pair programming第十八頁，編輯于星期五：二十一點 三十分。第十八頁，編輯于星期六：十二點 十八分。desk check1calcsquares()2

11、 display “x, “x squared3 for x=1 to 3 do4 xsquared=x*x5 display x,xsquared6 endfor7stoplnxxsquaredconditionsinput/output12x, xsquared311=3?is t41*1=15x=1,xsquared=161+1=232=3?is t42*2=45x=2,xsquared=462+1=37第十九頁，編輯于星期五：二十一點 三十分。第十九頁，編輯于星期六：十二點 十八分。formal technical reviewswalkthroughinspection第二十頁，編輯

12、于星期五：二十一點 三十分。第二十頁，編輯于星期六：十二點 十八分。walkthrougha form of software peer review in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of develo

13、pment standards, and other problemsthree specialist roles in a walkthrough the author, who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items; the walkthrough leader, who conducts the walkthrough, handles adm

14、inistrative tasks, and ensures orderly conduct (and who is often the author); and the recorder, who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meetings. 第二十一頁，編輯于星期五：二十一點 三十分。第二十一頁，編輯于星期六：十二點 十八分。inspectionrefers to peer review of any work

15、product by trained individuals who look for defects using a well defined processinspection rolesauthor: the person who created the work product being inspected. moderator: this is the leader of the inspection. the moderator plans the inspection and coordinates it. reader: the person reading through

16、the documents, one item at a time. the other inspectors then point out defects. recorder/scribe: the person that documents the defects that are found during the inspection. inspector: the person that examines the work product to identify possible defects. 第二十二頁，編輯于星期五：二十一點 三十分。第二十二頁，編輯于星期六：十二點 十八分。s

17、teps of a reviewthe team prepares for reviewthe team indicates it is ready for reviewthe review facilitator performs a cursory reviewthe review facilitator plans and organizes the reviewthe reviewers review the package prior to the reviewthe review takes placethe review results are acted on第二十三頁，編輯于

18、星期五：二十一點 三十分。第二十三頁，編輯于星期六：十二點 十八分。review guidelinesreview the product, not the producerset an agenda and maintain itlimit debate and rebuttal enunciate problem areas, but dont attempt to solve every problem notedtake written noteslimit the number of participants and insist upon advance preparationde

19、velop a checklist for each product that is likely to be reviewedallocate resources and schedule time for ftrsconduct meaningful training for all reviewersreview your early reviews第二十四頁，編輯于星期五：二十一點 三十分。第二十四頁，編輯于星期六：十二點 十八分。c/disciplines/quality/index.php#checklists第二十五

20、頁，編輯于星期五：二十一點 三十分。第二十五頁，編輯于星期六：十二點 十八分。設(shè)計評審checklist設(shè)計方案正確性、先進(jìn)性、可行性系統(tǒng)組成、系統(tǒng)要求及接口協(xié)調(diào)的合理性軟件實現(xiàn)的功能是否覆蓋了產(chǎn)品需求文檔中要求的功能功能的實現(xiàn)中，是否考慮到了所有可能的分支情況，以及這些分支情況的處理是否合理對于功能模塊的輸入?yún)?shù)、輸出參數(shù)的定義是否明確系統(tǒng)性能、可靠性、平安性要求是否合理文檔的描述是否清晰、明確第二十六頁，編輯于星期五：二十一點 三十分。第二十六頁，編輯于星期六：十二點 十八分。為什么要做集成測試方案集成測試完成的是對各模塊聯(lián)合工作的測試。集成測試可以分為兩個層次：一是系統(tǒng)模塊之間的集成；而

21、是模塊內(nèi)部多個元素之間的集成。而對模塊內(nèi)部元素的測試那么是單元測試的工作。集成測試方案是對集成測試活動的整體規(guī)劃和安排?？梢允沟孟嚓P(guān)聯(lián)系人盡早地明確相應(yīng)的職責(zé)，從而發(fā)揮整體團(tuán)隊的力量提高軟件質(zhì)量。設(shè)計完成之后，集成測試的內(nèi)容就定義好了。所以，雖然集成測試實施的時間是在代碼開發(fā)完畢，單元測試完成之后，但是集成測試的方案工作可以在設(shè)計完成之后開展。越早開展測試工作，帶來的收益就越大。第二十七頁，編輯于星期五：二十一點 三十分。第二十七頁，編輯于星期六：十二點 十八分。what is an integration test plan?this document typically describes

22、 one or more of the following: - how the tests will be carried out - the list of things to be tested - roles and responsibilities - prerequisites to begin testing - test environment - assumptions - what to do after a test is successfully carried out - what to do if test fails - glossary第二十八頁，編輯于星期五：

23、二十一點 三十分。第二十八頁，編輯于星期六：十二點 十八分。how to write an integration test case?simply put, a test case describes exactly how the test should be carried out. the integration test cases specifically focus on the flow of data/information/control from one component to the other.so the integration test cases should

24、 typically focus on scenarios where one component is being called from another. also the overall application functionality should be tested to make sure the app works when the different components are brought together.the various integration test cases clubbed together form an integration test suite .each suite may have a particular focus. in other words different test suites may be created to focus on different areas of t