Practice

This document has some question, answer pairs and was used to gain further insight into how this topic was tested within the university.

Test 1 2017

Section 1 - Project Management</p> Question 1</p>

1. How do you set out to manage risks at the start of the project? (4)
2. List the 3M’s of risk management and explain what they entail (6)

1.1

1. Identify project specific risks 2. Analyze the risks 3. Rank them in a particular order 4. Plan for the monitoring, mitigation and management of these risks

1.2

* Mitigation - avoiding or reducing the risk by changing requirements or transferring the risk (by buying insurance, etc), or assume the risk and put in measures to control it * Monitoring - what factors can we track that will enable us to determine if the risk is becoming more or less likely * Management - what contingency plans do we have that will enable us to determine if the risk is becoming more or less likely.

Question 2</p>

1. Consider the following principles of Extreme Programming (XP) and briefly describe each principle (0.5 each)
   • Incremental Planning
   • Small Releases
   • Simple Design
   • Test-first Development
   • Refactoring
   • Pair Programming
   • Collective Ownership
   • Continuous Integration
   • Sustainable Pace
   • On-site customer
2. Describe test-driven development (4)
3. List some of the benefits of pair programming (3)

2.1

* Incremental Planning - requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development 'Tasks' * Small Releases - the minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the previous release. * Simple Design - enough design is carried out to meet the current requirements and no more. * Test-first Development - an automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. * Refactoring - all developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. Pair Programming: Developers work in pairs, checking each other’s work and providing the support to always do a good job. * Collective Ownership - the pairs of developers work on all areas of the system, so no islands of expertise develop and all the developers take responsibility for all of the code: anyone can change anything. * Continuous Integration - as soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. * Sustainable Pace - large amounts of overtime are not acceptable as the net effect is often to reduce code quality & medium term productivity * On-site Customer - a representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

2.2

* TDD can be described as * TDD = TFD + Refactoring * TDD turns traditional development around * Instead of writing functional code first and then your testing code an afterthought * You first write your test code before your functional code * Also you do so in very small steps * One test and a small bit of code at a time * With TDD a developer refuses to write a new function unless there is a test that fails because that function isn't present * Refuse to add even a single line of code until a test exists for it * Once the test is in place do the work required to ensure that the test suite now passes * Once your code works, refactor it to ensure that it remains of high quality

2.3

* Productivity is similar to that of two people working independently * Common ownership of code * Collective (team) responsibility for the system * Spreads knowledge across the team * Reduces risk if someone leaves * Motivates refactoring as the whole team will benefit from it

Section 2 - Architecture</p> Question 3</p>

1. Briefly describe the pipe and filter architecture and draw a diagram to illustrate it (6)
2. How can the pipe and filter architecture be generalized, what is it then called? (2)
3. We discussed several architecture patterns in the duration of this course. What is the key aim of these patterns? Define any new terms that you introduce during your explanation. (4)

3.1

A system is decomposed into a set of functional transformations that consume inputs and produce outputs. Data flows from one function to another (the pipeline) and is transformed as it passes through the sequence 

3.2

It can be generalized to have branching pipes connecting filters. It is then called the Data Flow Architecture

3.3

The key aim of architectural patterns is to minimize coupling while maximising cohesion. * Cohesion is the degree to which communication takes place within the module * Coupling is the degree to which communication takes place between modules You could also explain this in terms of the *separation of concerns and localization of impact*.

Question 4</p> Many personal computer applications are event processing systems

1. Why are they called event processing systems? (1)
2. What is the key characteristic of event processing systems that impacts the architecture (2)
3. Please describe a high-level view of data processing systems (3)

4.1

They respond to events in the environment of the system

4.2

Their key characteristic is that event timing is unpredictable so the architecture has to be organised to handle this

4.3

Data processing systems are data-driven and operate in batch mode and generally have an input-process-output structure. Records are inputted to the system, information is processed and outputs are generated

Test 1 2018

Section 1 - Project Management</p> Question 1</p>

1. You are a project manager (PM). An activity on the critical path is behind schedule. You hve no additional resource available. What do you do? (3)
2. You are the PM and have successfully determined your scope. In addition to your project plan, you have several supporting plans. One of them being a risk management plan. Name another appropriate supporting plan and the purpose of it? (3)

1.1

Two major options: * Move the project deadline to accommodate the delay * Reduce the scope of the project Both of these have to be discussed with the client

2.2

Human Resource plan. * Name key individuals and organisations: describe roles and responsibilities * Describe the number and type of people needed Communication and Management plan * Necessary for keeping requisite people informed about the project. * Clarify how they will receive this information * Frequency * Medium Marketing plan * Go to market strategy * Target market, releasing content freely or as paid DLC, promotion, etc

Question 2</p>

1. One of the few artefacts required in Scrum is the Burndown Chart. What is it and what does it provide? (3)
2. What is test driven development? Highlight how it differs from more traditional software development methods. (5)
3. Name a traditional software development method (1)

2.1

A burndown chart tracks the progress of a sprint. It is a graphical plot of work left to do in a sprint against time. It can be used to identify the rate that work is being completed - which is known as velocity. It can give indications that work is too slow, or that things are quicker than expected

2.2

Test Driven Development (TDD) can be described as test first development + refactoring. TDD turns traditional development around and instead of writing functional code first and then testing your code, you first write your test code before your functional code. In addition, the development occurs in very small steps: one test and a small bit of code at a time. Once the code passes the test it is refactored to ensure it remains of high quality. The radical point is that new code is only written when an automated test fails.

2.3

Waterfall method

Section 2 - Architecture</p> Question 3</p>

1. What is meant by software architecture? (2)
2. Indicate whether the following statements are True or False
   1. In agile development, architectures should be developed incrementally (1)
   2. When designing complex applications, a single architectural model is mostly used (1)
3. Briefly describe pipe and filter and draw a diagram to illustrate it (7)

3.1

Multiple answers, but here are three: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. Or IEEE: The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. Or outline: software architecture ≡ “the set of principal design decisions about the system”. It is about the BIG picture; the large scale: motivations, constraints, organization, patterns, responsibilities, connections of a system (or a system of systems)

3.2.1

False

3.2.2

False

3.3

A system is decomposed into a set of functional transformations that consume inputs and produce outputs. Data flows from one function to another (the pipeline) and is transformed as it passes through the sequence. 

Question 4</p>

1. Which kind of UML diagram is most commonly used for logical layered architectures? (1)
2. Name two layered reference architectures use in networking (2)
3. Which programming language constructs are used to implement the concept of type? (2)
4. Explain what is meant by high cohesion
5. What is a very commonly used run-time organization pattern for distributed systems, particularly over the internet?
6. Briefly explain the concept of low representational gap when designing classes and objects

4.1

Package Diagram

4.2

OSI & TCP/IP

4.3

Abstract Classes & Interface

4.4

Cohesion is a measure of how strongly related and focused the responsibilities of an element are. A class with low cohesion does many unrelated activities or does too much work. A class with high cohesion has a relatively low number of methods with highly related functionality and doesn’t do much work.

4.5

Client Server

4.6

Classes/objects should closely correspond to real world objects

Supplementary Examination, January 2017

Section 1 - Advanced Software Design</p> Question 1</p>

1. What problem is being solved by the Pipe and Filter design pattern and how? (6)
2. The key aim of many patterns is to minimize coupling, while maximizing cohesion. Explain what cohesion and coupling are. (4)

1.1

The problem that the Pipe and Filter design is solving is that data processing applications have inputs which are processed in separate stages to generate related outputs. The pipe and filter method allows the processing of the data in a system to be organized so that each processing component (filter) is discrete and carries out one type of data transformation. This data flows (as in a pipe) from one component to another for processing.

1.2

* Cohesion is the degree to which communication takes place within the module * Coupling is the degree to which communication takes place between the modules

Question 2</p>

1. How does test-driven development work and what does it achieve? (6)
2. How do iterative processes accommodate risk better than the waterfall approach? (6)

2.1

Test driven development is test first development with refactoring. You write test code before any functional code. One test and a small bit of code at a time. Once your code works, refactor it to ensure that it is high quality. This means, that the code is thoroughly unit tested, and the resulting tests provide a working specification for the code.

2.2

It reduces risks because it ensures that the team is developing small pieces of the system over a short timeframe. At the end of each development cycle, the software should be demonstrated to the users to obtain feedback on its functionality and suitability. An iterative approach will continuously reduce project risk from the outset. The reason why, is that it forces the team to address the most important aspects of functionality and to resolve high risk issues at an early stage. Whereas, with Waterfall the project will only receive feedback in the prototyping stage - after a considerable amount of time (and cost) has gone into the project, and it will be a lot harder to change the product. 

Question 3</p>

1. Rational Unified Process suggests a “4+1” view of architectures. List and briefly describe all elements of this view. (10)

3.1

Logical View: The logical view is concerned about the output(s) of the system and how it will affect the end users. The logical view splits the system into a set of abstractions, or modules. Can be displayed with a communication diagram Developmental View: This view describes the static organization of the software in its development environment. Can be displayed with a package diagram Process View:This view deals with concurrency and distribution, system integrity, and fault tolerance. Shows the dynamic interactions of the system and how things interact at run time. Can be displayed with a activity diagram Physical View:This view describes how the software maps onto the hardware. Can be displayed with a deployment diagram

Question 4</p>

1. Understanding and fostering culture is an important component of sustaining open source projects. Name some techniques and principles that should be considered in open source projects. (4)

4.1

* A community volunteers, so do need to get the culture and motivating forces right > People should feel that their connection to a project, and influence over it, is directly proportional to their contributions * A shared culture and etiquette for participation exists * Be aware of the issues and politics * Build trust and social capital and slowly establish merit by offering solutions and for various issues * Bossy, critical people won't be welcome All open source projects should have * A website for one way information * A mailing list for active communication and to be a medium of record * Version control to allow devs to manage changes and allow anyone to watch the code base * Realtime chat for quick and easy communication and Q/A * Bug tracking to allow devs to coordinate and keep track of bugs Some principles to follow are * Making the vision public * Gathering the requirements (computing environment) * Have an up to date development status * Have a convenient and standard way to download and install * Account for deficiencies since they will be found anyways All of these allow users to decide for themselves if the software works for them.