Chapter 1 An Introduction to Software Engineering *What is software?-Computer programs and associated documentation and Data-Two fundamental types of software product: generic products and customized products*What is software engineering?-Software engineering is an engineering discipline which is concerned with all aspects of software production*What is the difference between software engineering and computer science?-Computer science is concerned with theory and fundamentals;-software engineering is concerned with the practicalities of developing and delivering useful software *What is a software process?-A set of activities whose goal is the development or evolution of software-Generic activities in all software processes are:•Specification 、Development 、Validation 、EvolutionChapter 4 Software Process*Software process-Software processes are the activities involved in producing and evolving a software system.-A structured set of activities required to develop a software system:specification;designand implementation;validation;evolution.-General process activities are specification, design and implementation, validation and evolution.*Software process models-Software process models are abstract representations of these processes.-Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.-The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites-There are two fundamental types of evolutionary development: exploratory development and throw-away prototyping-Exploratory development should start with well-understood requirements and add new features as proposed by the customer-Throw-away prototyping should start with poorly understood requirements to clarify what is really needed.- Evolutionary development is mostly used for small or medium-size interactive systems and short-lifetime systems*Iterative process models describe the software process as a cycle of activitiesChapter 5 Project management*Primary project management activities:-Proposal writing.-Project planning and scheduling.-Project costing.-Project monitoring and reviews.-Personnel selection and evaluation.-Report writing and presentations.*Project planning-Milestones are the end-point of a process activity.-Deliverables are project results delivered to customers.*Project scheduling-Organize tasks concurrently to make optimal use of workforce.-Minimize task dependencies to avoid delays caused by one task waiting for another to complete.-Graphical notations used to illustrate the project schedule: bar charts and activity networks -Activity charts show task dependencies and the critical path.-Bar charts show schedule against calendar time.Task durations and dependenciesstartT2M3T6Fin ishT10M7T5T7M2T4M5T84/7/038 d ays 4/8/0315 d a ys 25/8/037 d ays 5/9/0310 d a ys19/9/0315 d a ys 11/8/0325 d ays 10 d ays 20 d ays 5 d ays 25/7/0315 d ays 25/7/0318/7/0310 d a ys T1M1T3T9M6T11M8T12M4Activity network4/711/718/725/71/88/815/822/829/85/912/919/9T 4T 1T 2M1T 7T 3M5T 8M3M2T 6T 5M4T 9M7T 10M6T 11M8T 12StartFin is hActivity bar chart(Gantt chart)Staff allocation vs. time chart chart*Risk management-Three related categories of risk:project risks, product risks, business risks-Project risks affect schedule or resources;-Product risks affect the quality or performance of the software being developed;-Business risks affect the organisation developing or procuring the software-The process of risk management involves several stages: Risk identification, Risk analysis, Risk planning, Risk monitoring.-Risk identification: Identify project, product and business risks;-Risk analysis: Assess the likelihood and consequences 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 management processChapter 6 Software Requirements-Functional and non-functional requirements-User requirements and system requirements*Functional and non-functional requirements-Functional requirements•Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.-Non-functional requirements•Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.-The types of non-functional requirement are: product requirements, organisational requirements, external requirements.-Functional requirements set out services the system should provide.-Non-functional requirements constrain the system being developed or the development process.*In principle, requirements should be both complete and consistent.-Complete•They should include descriptions of all facilities required.-Consistent•There should be no conflicts or contradictions in the descriptions of the system facilities.Chapter 7 Requirements Engineering Processes*The requirements engineering process includes- Feasibility study, requirements elicitation and analysis, requirements specification and requirements management.Chapter 8 System Model*Different models present the system from different perspectives•External perspective showing the system’s context or environment;•Behavioural perspective showing the behaviour of the system;•Structural perspective showing the system or data architecture.*Two types of behavioural model are:•Data flow models that show how data is processed as it moves through the system;•State machine models that show the systems response to events.Chapter 11 Architectural Design*Architecture and system characteristics-performance•Localise critical operations and minimise communications. Use large rather than fine-grain components.-security•Use a layered architecture with critical assets in the inner layers.-safety•Localise safety-critical features in a small number of sub-systems.-Availability•Include redundant components and mechanisms for fault tolerance.-Maintainability•Use fine-grain, replaceable components, avoid data shareChapter 12 Distributed Systems Architectures*Distributed systems architectures-Client-server architectures•Distributed services which are called on by clients. Servers that provide services are treated differently from clients that use services.-Distributed object architectures•No distinction between clients and servers. Any object on the system may provide and use services from other objects.*Middleware is usually off-the-shelf rather than specially written software.*Layered application architecture-Presentation layer•Concerned with presenting the results of a computation to system users and with collecting user inputs.-Application processing layer•Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc.-Data management layer•Concerned with managing the system databases.*Thin and fat clients-Thin-client model•In a thin-client model, all of the application processing and data management is carried out on the server. The client is simply responsible for running the presentation software.-Fat-client model•In this model, the server is only responsible for data management. The software on the client implements the application logic and the interactions with the system user.* Three-tier architecturesA 3-tier C/S architecture*P2P architectural models-Peer to peer architectures are decentralised architectures where there is no distinction between clients and servers.-The logical network architecture•Decentralised architectures;•Semi-centralised architectures.Decentralised p2p architectureSemi-centralised p2p architectureChapter 13 Application architectures*Important classes of application are data processing systems, transaction processing systems, event processing systems and language processing system.*Data processing systems operate in batch mode and have an input-process-output structure.Chapter 14 Object-oriented Design*Objects and object classes-Objects are entities in a software system which represent instances of real-world and system entities.-Objects are members of classes that define attribute types and operations.-Object 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 represent each interaction with the system.Chapter 16 User interface design*Human factors in interface design-Limited short-term memory•People can instantaneously remember about 7 items of information. If you present more than this, they are more liable to make mistakes.-People make mistakes•When people make mistakes and systems go wrong, inappropriate alarms and messages can increase stress and hence the likelihood of more mistakes.-People are different•People have a wide range of physical capabilities. Designers should not just design for their own capabilities.-People have different interaction preferences•Some like pictures, some like text.*User interface design principles*MVC approaches (Information presentation, pp.370)Figure: the MVC model of user interaction * How to design UI (Information presentation, pp. 375)Figure **.1 An input text box used by a nurseFigure **.2 system and user-oriented error messages*The UI design process-The 3 core activities in this process are:•User analysis. Understand what the users will do with the system;•System prototyping. Develop a series of prototypes for experiment;•Interface evaluation. Experiment with these prototypes with users.*Some evaluation of a user interface design should be carried out to assess its suitability.Attribute DescriptionLearnability How long does it take a new user to become producthe system?Speed of operation How well does the system response match the usepractice?Robustness How tolerant is the system of user error?Recoverability How good is the system at recovering from user erroAdaptability How closely is the system tied to a single model of w精品文档word文档可以编辑！谢谢下载！。