7/11/2011

Module Title: Software Engineering

1. Module Leader: Carolina Gomez 2. Course Description:
The module has been designed to provide the skills and knowledge necessary for systems modelling, design and analysis. It also aims to provide an in-depth understanding of basic principles of formal specifications of system requirements, and the skills and knowledge necessary to develop object-oriented specifications of computer-based systems. The module also aims to teach basic principles of (object-oriented) program specifications and their role in program verification. It illustrates how they relate to formal specifications of system requirements. It also provides skills and knowledge necessary to develop specifications of Java programs.

3. Learning Objectives
Upon successful completion of this module, students will be able to:

4.

Understand the fundamentals of software engineering. Understand the concept of socio-technical systems and to discuss the systems engineering process. Understand the concept of software processes and software process models. Comprehend the principal requirements of engineering activities and their relationships. Understand why it is important to establish the boundaries of a system and model its context. Understand the concepts of software architecture and architectural design. Identify the design goals of a system, design the initial subsystem decomposition and refine the subsystem decomposition to address the design goals. Understand software evolution and to describe a number of ways to modify software. Be aware of the concepts of validation and verification with a particular focus on static verification techniques. Indicative Content Software engineering System development process Socio-technical and Critical Systems Software Processes Integrated program planning Software Requirements Requirement engineering process System models Architectural Design System Design: Decomposing the system System Design: Addressing Design Goals Specifying interfaces Software Evolution and Legacy Systems
1

7/11/2011

System verification, validation and testing

7/11/2011

6. Core Text: Core text: Sommerville, I. (2007) Software Engineering (8th edn), Addison-Wesley. Recommended Reading: Bruegge, B. and Dutoit, A.H. (2009) Object Oriented Software Engineering (3rd edn), Prentice Hall. Pressman, R.S. (2009) Software Engineering: A Practitioner's Approach (7th edn), McGrawHill. George, J., Batra, D.,Valacich, J., Hoffer, J, (2007) Object-Oriented Systems Analysis and Design, (2nd edn) Prentice Hall 7. Delivery A variety of teaching approaches is used, including lectures, seminars, case analysis, teamwork and extensive use of the Internet for guided research. Notional Student Workload Lectures Seminars Directed Learning Independent Learning Formal Assessment Total 8. Assessment Three hour closed book examination. 30 hours 12 hours 36 hours 39 hours 3 hours 120 hours

7/11/2011

5. Lecture Sequence

Lecture Subject No 1. What is software engineering? 2. System development process 3. Global E-Business How Business Use Information Systems 4. Seminar-1 5. 6. 7. 8. 9.

Core Text Chapter 1, Sommerville Chapter 1, Sommerville Chapter 2, Laudon and Laudon Topic Revision 1-3

Refer to Sample Question(s) No Q10 Q4

Q8, Q9

Socio-technical and Critical Chapter 2 & 3, Sommerville Systems Software Processes Chapter 4, Sommerville Project Management Seminar-2 Software Requirements Chapter 5, Sommerville and Chapter 14, Bruegge and Dutoit Topic Revision 5-7 Chapter 6, Sommerville

Q3 Q5 Q1, Q7 Q12

10. Requirement engineering process 11. System models 12. Seminar-3 13. Architectural Design

Chapter 4, Bruegge and Dutoit and Q15 Chapter 7, Sommerville Chapter 8, Sommerville Topic Revision 9-11 Chapter 11, Sommerville Q17, Q14 Q18 Q16

14. System Design: Addressing Chapter 7, Bruegge and Dutoit Design Goals 15. User interface design Chapter 16, Sommerville 16. Seminar-4 17. Software Evolution and Legacy Systems 18. System verification and validation 19. Software testing 20. Seminar-5 Topic Revision 13-15 Chapter 21, Sommerville Chapter 22, Sommerville Chapter 23, Sommerville Topic Revision 17-19

Q19, Q20 Q11 Q2

Q6, Q13

7/11/2011

7/11/2011

Sample Question Software Engineering BSc 3 & 4

Question 1 System reliability and safety are related but have distinct dependability attributes. Describe the most important distinction between these attributes and explain why it is possible for a reliable to system to be unsafe and vice versa. Question 2 Discuss the difference between verification and validation, and explain why validation is a particularly difficult process. Question 3 Identify and briefly describe four types of requirements that may be defined for a computerbased system. Question 4 a. Identify and explain any 5 methods used in system development for efficient requirement communication. b. What are the incremental development advantages? c. What are the Spiral model sectors? Question 5 a. Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. Discuss the risk management process. b. List types of project plan (with a description of each). Question 6 Explain the system evolution process Question 7 Discuss the concept and characteristics of socio-technical systems. Question 8 What are the three main categories of information system that serve different organizational levels? How can a transaction processing system help an organization's strategic-level planning? Question 9 Discuss the benefits and challenges of enterprise systems and explain why a firm would want to build one. Question 10 Outline typical activities conducted at each stage of the system engineering process

7/11/2011

Question 11 a. Explain the four strategic options for evolving legacy systems b. What are the types of software maintenance? Question 12 a. What is the requirements engineering process? b. What are the Non- Functional classifications? Question 13 Explain why it is not necessary for a program to be completely free of defects before it is delivered to its customers. To what extent can testing be used to validate that the program is fit for its purpose? Question 14 What are the guideline points for writing requirements? Question 15 List the types of viewpoints. Question 16 Design goals are grouped into five categories: performance, dependability, cost, maintenance, and end user. Assign one or more categories to each of the following goals: a. Users must be given a feedback within 1 second after they issue any command. b. The TicketDistributor must be able to issue train tickets, even in the event of a network failure. c. The housing of the TicketDistributor must allow for new buttons to be installed in the event the number of different fares increases. d. The AutomatedTellerMachine must withstand dictionary attacks (i.e., users attempting to discover an identification number by systematic trial). e. The user interface of the system should prevent users from issuing commands in the wrong order. Question 17 What are the Mandatory requirements? Question 18 Explain why it is necessary to design the system architecture before the specifications are written Question 19 Decomposing a system into subsystems reduces the complexity developers have to deal with by simplifying the parts and increasing their coherence. Decomposing a system into simpler parts usually results into increasing a different kind of complexity: Simpler parts also means a larger number of parts and interfaces. If coherence is the guiding principle driving developers to decompose a system into small parts, which competing principle drives them to keep the total number of parts small?

7/11/2011

Question 20 Consider a legacy, fax-based, problem-reporting system for an aircraft manufacturer. You are part of a reengineering project replacing the core of the system by a computer-based system, which includes a database and a notification system. The client requires the fax to remain an entry point for problem reports. You propose an E-mail entry point. Describe with the aid of a diagram, a subsystem decomposition that would allow both interfaces. Note that such systems are used to process many problem reports per day (e.g. 2000 faxes per day)