Software Engineering 1



Similar documents
BCS HIGHER EDUCATION QUALIFICATIONS Level 6 Professional Graduate Diploma in IT. March 2013 EXAMINERS REPORT. Software Engineering 2

A. Waterfall Model - Requirement Analysis. System & Software Design. Implementation & Unit Testing. Integration & System Testing.

Karunya University Dept. of Information Technology

(Refer Slide Time: 01:52)

A Comparison between Five Models of Software Engineering

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

Managing TM1 Projects

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

What is a life cycle model?

Baseline Code Analysis Using McCabe IQ

Software Life Cycle Processes

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

IV. Software Lifecycles

ICS 121 Lecture Notes Spring Quarter 96

How To Model Software Development Life Cycle Models

Development Methodologies Compared

Lifecycle Models: Waterfall / Spiral / EVO

3F6 - Software Engineering and Design. Handout 15 Software Management I With Markup. Steve Young

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53

11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management?

CHAPTERS A NEW KNOT MODEL FOR COMPONENT BASED SOFTWARE DEVELOPMENT

Agile Development and Testing Practices highlighted by the case studies as being particularly valuable from a software quality perspective

Chapter 8 Approaches to System Development

Basic Trends of Modern Software Development

Software Development Life Cycle (SDLC)

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

Basic Unified Process: A Process for Small and Agile Projects

LECTURE 1. SYSTEMS DEVELOPMENT

Software Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution

Module 1. Introduction to Software Engineering. Version 2 CSE IIT, Kharagpur

COURSE CODE : 4072 COURSE CATEGORY : A PERIODS / WEEK : 4 PERIODS / SEMESTER : 72 CREDITS : 4

General Problem Solving Model. Software Development Methodology. Chapter 2A

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS. BCS Level 5 Diploma in IT APRIL 2013 IT PROJECT MANAGEMENT EXAMINERS REPORT

Software Engineering Question Bank

a new generation software test automation framework - CIVIM

SOFTWARE ENGINEERING INTERVIEW QUESTIONS

Software Engineering/Courses Description Introduction to Software Engineering Credit Hours: 3 Prerequisite: (Computer Programming 2).

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT. September 2013 EXAMINERS REPORT

COSC 3351 Software Design. Recap for the first quiz. Edgar Gabriel. Spring For the 1 st Quiz

Business Application Services Testing

Towards Collaborative Requirements Engineering Tool for ERP product customization

In this Lecture you will Learn: Development Process. Unified Software Development Process. Best Practice

An Assessment between Software Development Life Cycle Models of Software Engineering

Software Project Management

A Survey of Software Development Process Models in Software Engineering

Module 12. Software Project Monitoring and Control. Version 2 CSE IIT, Kharagpur

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology?

Netstar Strategic Solutions Practice Development Methodology

Benefits of Test Automation for Agile Testing

Automating Rich Internet Application Development for Enterprise Web 2.0 and SOA

System development lifecycle waterfall model


How To Understand Software Engineering

Software Project Management Part 2: Work Breakdown Structures

Elite: A New Component-Based Software Development Model

SOFTWARE ECONOMICS UNIT 15. Presented by. Stefano Street

Component Based Development in Software Engineering

"Testing in the DevOps World of Continuous Delivery"

Chapter 23 Software Cost Estimation

NAME: (Please PRINT) CEN Software Engineering

Agile Methodologies and Its Processes

MEASURES FOR EXCELLENCE SIZING AND CONTROLLING INCREMENTAL SOFTWARE DEVELOPMENT

Process Models and Metrics

JOURNAL OF OBJECT TECHNOLOGY

Engineering Process Software Qualities Software Architectural Design

CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective:

CS 1632 SOFTWARE QUALITY ASSURANCE. 2 Marks. Sample Questions and Answers

Chapter 9 Software Evolution

THE BCS PROFESSIONAL EXAMINATIONS Certificate in IT. October Examiners Report. Information Systems

Fundamentals of Measurements

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1

IT3205: Fundamentals of Software Engineering (Compulsory)

Key Benefits of Microsoft Visual Studio Team System

Advanced Software Engineering. Software Development Processes

Table of Contents. CHAPTER 1 Web-Based Systems 1. CHAPTER 2 Web Engineering 12. CHAPTER 3 A Web Engineering Process 24

PHASE 6: DEVELOPMENT PHASE

Assuming the Role of Systems Analyst & Analysis Alternatives

Name of pattern types 1 Process control patterns 2 Logic architectural patterns 3 Organizational patterns 4 Analytic patterns 5 Design patterns 6

2. Analysis, Design and Implementation

Unit Title: Personnel Information Systems Unit Reference Number: F/601/7510 Guided Learning Hours: 160 Level: Level 5 Number of Credits: 18

IT3203 Fundamentals of Software Engineering (Compulsory) BIT 2 nd YEAR SEMESTER 3

Custom Web Development Guidelines

Management. Project. Software. Ashfaque Ahmed. A Process-Driven Approach. CRC Press. Taylor Si Francis Group Boca Raton London New York

Appendix D Programme Stream 6 CRM Procurement. Programme Stream 6 Remodelling of Customer Services Programme CRM Procurement

A system is a set of integrated components interacting with each other to serve a common purpose.

Chapter 1: Introduction to Rapid Application Development (RAD) 1. Introductions

SWEBOK Certification Program. Software Engineering Management

The software process. Generic software process models. Waterfall model. Software Development Methods. Bayu Adhi Tama, ST., MTI.

Software Development Life Cycle

ASSESSMENT OF SOFTWARE PROCESS MODELS

Umbrella: A New Component-Based Software Development Model

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW

CUT COSTS, NOT PROJECTS

Transcription:

THE BCS PROFESSIONAL EXAMINATIONS Diploma April 2006 EXAMINERS REPORT Software Engineering 1 General Comments Most of the scripts produced by candidates this year were well structured and readable, showing advancing knowledge beyond the certificate level and a good grasp of higher essentials necessary for the Graduate Diploma examination. However, in some centres the general standard of the written work, and the level of comprehension (of the question set as well as the subject matter), needs particular attention. Above all, this is a technical paper about Software Engineering. Questions seek to test candidates knowledge and ability to apply that knowledge. It is a poor answer that simply describes recalled information. It is a good answer that can then show application of the recalled knowledge. Time management is an issue that still challenges many candidates. Questions are framed with an allocation of marks; an answer that provides 6 pages for 9 marks and two paragraphs for 16 marks makes poor use of time. Equally, answering more questions that required signals either lack of preparation or inability to count; both are issues of concern. In a few instances, the issue still persists in which some candidates attempt to recognise one or two keywords without regard for the context and scenario in which the question was presented. Candidates should make themselves familiar with the format of previous question papers, the better to recognise and be successful with the test paper. Finally, similar to the previous year, some candidates had not completed the front cover with the number of the question and part-questions attempted. This made it very difficult to find all the parts of an answer, then determine whether it was a continuation of a previous answer, and assess and record the mark for that answer as a whole. Question 1 1. a) Discuss at least FOUR key roles that must be undertaken by staff within a software engineering project team. (12 marks) b) Outline FOUR factors that can influence communication within a software engineering project team. (8 marks) c) In his book, The Mythical Man-Month, Fredrick P. Brooks, Jr. stated Brooks's Law: Adding manpower to a late project makes it later. Discuss the evidence for and against Brooks's Law. (5 marks) a) Expecting any four of the following project leader/project manager; software librarian, chief/lead software engineer, software tester, software architect, software toolsmith, and related discussion of role with the team. (4x3=12 Marks) b) Expecting any 4 of the following with suitable outline: size of group and subsequent communication overhead; number of modules under development and technical communication to support interfacing these; group structure - problems with rigid, hierarchical groups for technical working; (1 of 6)

the physical work environment - office layout and adequate meeting rooms; group composition - personality problems and balance of roles within the group; communication channels available especially if the group is distributed geographically. (4x2=8 Marks) c) Expecting the answers to highlight the problems of bringing new people up to speed before they can usefully contribute to the work in hand; the additional communication overhead that new people will bring; that adding new people to a poorly managed project if they are too low level will not address the problem of poor management, adding manpower and retaining a poor design, poor architect and module breakdown will not address the core problem. Also based on Brooks OS/360 experience and subsequently validated by other studies and also reflected in Boehm's COCOMO model where project duration is a non-linear function of effort. Against where the effort allocated is such that the project will never be finished, e.g. inadequately qualified staff, then adding effort with an appropriate skillset may be the only way to ensure progress towards completion. This question probes students' understanding of the work and working of a software engineering team by getting them to discuss what people actually do within a team. Communication is obviously key to ensuring that a group of people can work as team; and in software development communication amongst the various developers and the project leader/manager is critical to the success of the project. Brook s insights into the nature of teams and problems introduced by adding members to the team of a late project are often quoted; here students were given an opportunity to critically appraise Brooks's Law. Question 2 2. The outline of a project you have been asked to develop is given below: Enquiries and Orders Information Management System A manufacturing company, ABC Composites, is the client. The client wants development of a new management information system (MIS) to enable multi-user data entry and querying. It is expected that the system will encompass the following areas:! User-friendly interface! Data entry validation! Defined reports, especially job control sheets, which the client already uses on paper! Querying of data to produce reports The client has a SQLserver system that should be the database and will support intranet access from several desks. The development models suggested for this project are Incremental Development using a series of prototypes and Systematic, sequential Development with progression through analysis, design, coding, testing and maintenance. Compare the advantages and disadvantages of these two life cycle models for this project. Give at least THREE examples to support your analysis of each life cycle model. (25 marks) (2 of 6)

A good answer will be balanced, with arguments on both sides and a conclusion. Incremental development offers a way to determine unclear requirements, tackle complex developments and anticipate difficult interfaces. Incremental development suggests build as a series of prototyping developments, where each cycle might involve considerable reworking of previous developments at the cost of developer and client time, and client cost. This project is mildly undefined a user friendly interface and not really difficult, and pre-defined reports is, again, a matter of analysis not exploration. The extra time spent developing prototypes seems not valuable. (10 Marks) Sequential development, also called Waterfall development, reckons that the project can be achieved in a single pass. It requires firm and stable requirements, known tools and unexciting interfaces. This project has most of these characteristics. (10 Marks) On balance, with sample arguments as above, a sequential development would achieve this project in short time with good results. This question is set to test candidates powers of analysis and reasoning. The aim is to analyse the scenario and reason about its implications for life cycle management. Some answers gave very guarded conclusions, saying that both types of suggested lifecycles would be used. Some answers gave extensive descriptions of lifecycles but did not relate their features to any characteristic of the scenario given in the question. Good answers related aspects of the scenario to claimed benefits of each life cycle model, and came to a reasoned conclusion and a recommendation. Question 3 3. a) Give THREE reasons for the use of CASE tools to support the work in a large software project. (9 marks) b) Your company has agreed to develop a large software system using Object-Oriented methods. Choose and describe THREE capabilities or functionalities you would want in a CASE tool to support this O-O development. Give your reasons for each choice. (16 marks) A good answer covers the following points. a) The main reason for using CASE tools is Productivity, and this can be expressed in a variety of software-specific ways better communication (including database repository of work, requirements, tests, test results, configuration status, etc.) better work rate (including lower costs and fewer people), higher quality ( including fewer errors, easier user validation, and easier iteration to converge on requirements).9 MARKS b) Three capabilities/functionalities for O-O development: from - Diagramming capability Use cases, Object class/messaging diagrams. Repository functionality storing diagrams, code, test cases etc. in a recoverable and reusable way. Test case generation from object descriptions. Requirements tracing reporting from use-case descriptions Configuration control of build states. Metric analysis for project management Etc. Any three with supporting rationale at 5 marks each. Extra point for holistic answers. (16 Marks) (3 of 6)

This question is designed to test candidates knowledge of CASE tools and their use. A good answer to Part (a) described why CASE tools are used, and a good answer to Part (b) related the O-O methods of the scenario to functions and features of a supportive tool. In each case, marks are given to answers that support their arguments with reasons. Some answers described what CASE tools were without identifying why they should be used. Some answers identified features of a CASE tool without relating these features to the O-O scenario in the question. Question 4 4. Some definitions of quality are given below: Quality means to make without any errors ; Quality means to make fit for the client s purpose ; Quality means to make each product statistically the same as the previous product. Which view, or views, of quality do you think best address the development of software? Give your reasons for accepting, rejecting or modifying each view. (25 marks) A good answer will give a discussion of each definition, along these lines. Absence of errors is an attractive goal for software engineers, but has never been achieved because of software complexity. (6 Marks) Fitness for a client s purpose is also attractive but it s not simply user requirements that determine purpose; other purposes introduced by software engineers are e.g. reliability and maintainability. (6 Marks) Statistical identity with other products is not useful for software projects, because the making of products involves digital cloning that ensures no statistical variation at all, or if the candidate interprets products to be separate projects where each is different from each other but yet addresses a similar requirement, this only makes commercial sense if for some sort of experiment (or the Space Shuttle or Airbus, where reliability is a primary requirement and dissimilar builds avoid common-mode failure). (6 Marks) Hence conclusion that most useful definition is Fitness for Purpose, with rider that this must include the several stakeholders with purposeful intentions; users, development engineers and maintainers. (7 Marks) A similar answer, balanced with a reasoned conclusion, is acceptable. This question is set to test the candidates understandings of software quality. In order to limit a possibly wide-ranging answer, three specific definitions are given. A good answer considers the relevance of each definition to software quality. Candidates are expected to factor the 25 points over the implied 7 parts of an answer; three sets of for-and-against; and one conclusion. Some answers decided the preferred definition and concentrated only on that one without giving reasons for discounting the others. (4 of 6)

Question 5 5. a) Define what is meant by black box testing and white box testing. (4 marks) b) Discuss TWO examples of a black box testing technique and TWO examples of a white box testing technique. (6 marks) c) How is software documentation used in the testing processes of unit testing, integration testing, system testing, and user acceptance testing? In each case, explain which software documents are most relevant. (10 marks) d) Explain the importance of the practice of regression testing during software maintenance. (5 marks) Black box testing is a test design method which focuses on the functional requirements of the software without regard to its internal logical structure. It treats the software under test as a black box whose contents are unknown. White box testing is a test case design method which uses the control structures of the software source code to derive test cases. It examines the logical paths through a program. (2x2 = 4 Marks) Discuss of any of the following examples: Black box techniques: equivalence partitioning, boundary value analysis, cause-effect graphing; comparison testing (2x3 = 6 Marks) Unit testing involves the testing individual units of source code, e.g. functions, procedures, classes, and it is primarily supported by the source code and detailed design documents. Integration testing involves the testing of two or more units which have a common linkage usually through a well defined interface; and it is primarily supported by design documentation. System testing involves testing of the software in combination with other system elements such as hardware, databases, people, etc and is supported by the system documentation including the initial customer requirements; it is often coupled with user acceptance testing which involves the final testing of software in the customer s installation before it is finally accepted and put into use. The most relevant documentation here is the customer requirements and any contracts made regarding the software to be delivered. (5x2 = 10 Marks) Regression testing is important during maintenance for the following reasons: Regression testing is the systematic re-testing of software after changes have been made. Its primary purpose is to ensure that after changes have been made to the software, no new errors have been introduced. Regression testing requires the systematic recording of previous testing and its practice ensures that structured maintenance is being carried. As the previous tests are re-used in regression testing, it saves the maintenance team the effort of recreating any tests. Question 6 6. An often quoted software design principle is "aim for low coupling and high cohesion". a) Define what is meant by software coupling and by software cohesion. (4 marks) b) Give examples of both of these with respect to the design of component-based software system. (6 marks) c) Explain the rationale for this principle and describe at least THREE benefits that follow from its practice. (10 marks) d) Explain how refactoring of software can be used to improve its cohesion. (5 marks) (5 of 6)

Examples of cohesion: functional (high), sequential, communicational, procedural, temporal, logical and coincidental Examples of coupling: data coupling, control coupling, common coupling via global data, content coupling (suitable examples of any of the above in the context of a component based software system). (2 x 3 = 6 Marks) Expecting a short essay type answer which covers the following: The rationale is that functional independence is a key to good design and design is a key to software quality. Benefits are that independent modules are easier to maintain, reusable, can be developed independently by individual engineers within a software team, result in improved program comprehension with supporting discussion. (10 Marks) Refactoring is a technique practised in Object Oriented software development, particularly amongst those following the extreme programming and agile methods of development. It involves examination of previously developed classes and the identification of any common aspects of these which can be factored out and implemented independently thus simplifying the original classes and making them more cohesive. This question aims to determine students' understanding of a key design principle by getting them to define the key concepts and provide illustrative examples. Students deeper understanding is probed by part c) of the question; and finally students are asked to relate a practice that is common in extreme and agile programming, refactoring, to the improvement of cohesion. (6 of 6)