軟件工程復(fù)習(xí)提綱(精)

1、Chapter 1 An In troduct ion to Software Engin eeri ng*What is software?-Computer programs and associated docume ntati on and Data-Two fun dame ntal types of software product: gen eric products and customized products*What is software engin eeri ng?-Software engin eeri ng is an engin eeri ng discipli

2、 ne which is concerned with all aspects of software product ion*What is the differe nee betwee n software engin eeri ng and computer scie nee?-Computer scie nee is concerned with theory and fun dame ntals;-software engin eeri ng is concerned with the practicalities of develop ing and deliveri ng use

3、ful software*What is a software process?-A set of activities whose goal is the developme nt or evoluti on of software-Ge neric activities in all software processes are:?Specification、 Development、 V alidation 、 EvolutionChapter 4 Software Process*Software process-Software processes are the activitie

4、s invo Ived in produci ng and evo Iving a software system.-A structured set of activities required to develop a software system: specificati on; desig n and impleme ntati on; validati on; evoluti on.-Ge neral process activities are specificati on, desig n and impleme ntati on, validati on and evolut

5、io n.*Software process models-Software process models are abstract represe ntati ons of these processes.-Ge neric process models describe the orga ni sati on of software processes. Examples in clude the waterfall model, evoluti onary developme nt andcomp onen t-based software engin eeri ng.-waterfal

6、l model is only appropriate whe n the requireme nts are well-un derstood and changes-The waterfall model is mostly used for large systems engin eeri ng projects where a system is developed at several sites-There are two fun dame ntal types of evoluti onary developme nt: exploratory developme nt and

7、throw-away prototyp ing-Exploratory developme nt should start with well-un derstood requireme nts and add new features as proposed by the customer-Throw-away prototyp ing should start with poorly un derstood requireme nts to clarify what is really n eeded.-Evoluti onary developme nt is mostly used f

8、or small or medium-size in teractive systems and short-lifetime systems*Iterative process models describe the software process as a cycle of activitiesChapter 5 Project man ageme nt*Primary project man ageme nt activities:-Proposal writi ng.-Project pla nning and scheduli ng.-Project costi ng.-Proje

9、ct mon itori ng and reviews.-Pers onnel selectio n and evaluati on.-Report writing and presentations.*Project pla nning-Milest ones are the en d-po int of a process activity.-Deliverables are project results delivered to customers.*Project scheduli ng-Orga nize tasks con curre ntly to make optimal u

10、se of workforce.-Min imize task depe nden cies to avoid delays caused by one task wait ing for ano ther to complete.-Graphical no tatio ns used to illustrate the project schedule: bar charts and activity n etworks-Activity charts show task depe nden cies and the critical path.-Bar charts show schedu

11、le aga inst cale ndar time.ActivityDurntioai (days)DependenciesTl8T215T315Tl (J41)T410T510T2,T4(M2)T65T1tT2(M3>T720Tl (Ml)T825T4 (M5)T915T3,T6(MCT1015T5.T? (M7)TH7T9(MQT1210Til (MB)Task durations and dependenciesr.itlIkJ 2他網(wǎng)$Activity n etworkActivity bar chart (Ga ntt chart1 CJd亍11 d口邙即電1C flYSta

12、ff allocation vs. time chart chart*Risk man ageme nt-Three related categories of risk: project risks, product risks, bus in ess risks -Projectrisks affect schedule or resources;-Product risks affect the quality or performa nee of the software beingdeveloped;-Bus in ess risks affect the orga ni sati

13、on develop ing or procuri ng the software -The process of risk man ageme nt invo Ives several stages: Risk ide ntificati on. Risk an alysis, Risk pla nning. Risk mon itori ng.-Risk ide ntificatio n: Ide ntify project, product and bus in ess risks;-Risk an alysis: Assess the likelihood and con seque

14、nces of these risks;-Risk planning: Draw up plans to avoid or minimise the effects of the risk;-Risk monitoring: Monitor the risks throughout the project;The risk man ageme nt processChapter 6 Software Requireme nts*Types of requireme nt:-Functional and nonfunctional requireme nts-User requireme nts

15、 and system requireme nts*Functional and nonfunctional requireme nts-Functional requireme nts?Stateme nts of services the system should provide, how the systeshould react to particular in puts and how the system should behave inparticular situati ons.-Non-fun cti onal requireme nts?Con stra ints on

16、the services or fun cti ons offered by the system such as timi ng con stra in ts, con stra ints on the developme nt process, sta ndards,etc.-The types of non-fun cti onal requireme nt are: product requireme nts,orga ni satio nal requireme nts, exter nal requireme nts.-Functional requireme nts set ou

17、t services the system should provide.-Non-fun cti onal requireme nts con strain the system being developed or thedevelopme nt process.rci|UfIPcrl>"Kr nunorfrijcif 電HSCAlLili 口 fa:*reqilFrcqur 5恥Sccii4ijniL'ftjreqiiT cciul mt"、(Jtfljiiuiire qiiT ebOi|L ne rtidRfllsi bUyrcquir niEsPm

18、ti biiy nequr cnirrltnrqiiir eimritJnfr pper u bilriyLhturcqwSpu話EfflfJt eni-firlNOlj >uryituui emcnitirrquv 4*cnejiSblkiLlf ikL 年 K h h ii erequir in叱iinSilcftrcqur entiiv*ln prin ciple, requireme nts should be both complete and con siste nt.-Complete?They should include descriptions of all faci

19、lities required.-Co nsiste nt?There should be no con flicts or con tradicti ons in the desipti ons of the system facilities.Chapter 7 Requireme nts Engin eeri ng Processes*The requireme nts engin eeri ng process in cludes-Feasibility study, requirements elicitation and analysis, requirements specifi

20、cation and requireme nts man ageme nt.Chapter 8 System Model*Differe nt models prese nt the system from differe nt perspectives?Exter nal perspective show ing the system' s con text or en vir onment;?Behavioural perspective show ing the behaviour of the system;/Structural perspective show ing th

21、e system or datarchitecture.*Two types of behavioural model are:?Data flow models that show how data is processed as it moves through the system;?State machi ne models that show the systems resp onse to eve nts.Chapter 11 Architectural Desig n*Architecture and system characteristics-performa nee?Loc

22、alise critical operati ons and mini mise com muni cati ons. Use large rather tha nfin e-gra in comp onen ts.-security?Use a layered architecture with critical assets in the inner layers.-safety?Localise safetycritical features in a small nu mber of sub-systems.-Availability?ln clude red undant comp

23、onents and mecha ni sms for fault tolera nee.-Mai ntai nability?Use fin egra in replaceable comp onen ts, avoid data shareChapter 12 Distributed Systems Architectures*Distributed systems architectures-Clie nt-server architectures?Distributed services which are called on by clie nts. Servers that pro

24、vide services are treated differe ntly from clie nts that use services.-Distributed object architectures?No disti nction betwee n clie nts and server Any object on the system may provide and use services from other objects.*Middleware is usually off-the-shelf rather than specially written software.*

25、Layered applicati on architecture-Prese ntati on layer/Concerned with prese nting the results of a compatio n to system users and with collect ing user in puts.-Applicatio n process ing layer/Concerned with providing application specific functionality e.g., in a banking system, banking functions suc

26、h as ope n acco unt, close acco unt,etc.-Data man ageme nt layer/Concerned with managing the system databases.*Th in and fat clie nts-Thi n-clie nt model?ln a thin-clie nt model, all of the applicatio n process ing and data man ageme nt is carried out on the server. The clie nt is simplyresp on sibl

27、e for running the prese ntati on software.-Fat-clie nt model?In this model, the server is only responsible for data management. The software on the client implements the application logic and thein teractio ns with the system user.Three-tier architecturesPrcsoiilicnPrcsoiilicnClidit MCliditMSawSawEi

28、ua>uaiwiq;ciiviiiwiq;ciiviiA 3-tier C/S architecture*P2P architectural models-Peer to peer architectures are dece ntralised architectures where there is no disti ncti on betwee n clie nts and servers.-The logical n etwork architecture?Dece ntralised architectures;?Sem-ce ntralised architectures.D

29、ece ntralised p2p architectureSemi-ce ntralised p2p architectureChapter 13 Applicatio n architectures*Importa nt classes of applicatio n are data process ing systems, tran sact ion process ing systems, eve nt process ing systems and Ian guage process ing system.*Data process ing systems operate in b

30、atch mode and have an in put-process-output structure.Chapter 14 Object-orie nted Desig nObjects and object classes-Objects are entities in a software system which represent instances of real-world and system en tities.-Objects are members of classes that defi ne attribute types and operatio ns.-Obj

31、ect classes are templates for objects. They may be used to create objects.-Object classes may inherit attributes and services from other object classes.*Use-case models are used to represe nt each in teract ion with the system.Chapter 16 User in terface desig n *Huma n factors in in terface desig n

32、-Limited shortterm memory ? People can in sta ntan eously remember about 7 items of in formatio n. If you prese nt more tha n this, they are more liable to make mistakes. -People make mistakes ? When people make mistakes and systems go wrong, in appropriate alarms and messages can in crease stress a

33、nd hence the likelihood of more mistakes. eople are differe nt ? People have a wide range of physical capabilities. Desig ners should not just desig n for their own capabilities. -People have differe nt in teractio n prefere nces ? Some like pictures, some like text. *User in terface desig n prin ciples*MVC approaches (In formati on prese ntati on, pp.370 Figure: the MVC model ofuser in teracti on * How to desig n UI (I nformatio n prese ntatio n, pp. 375 Please type the patient ' s name in the box then click on OK Patient' s name MacDonaid, R. OK CancelFigure *.1 An in put text box u