MEMO INF3705 Assignment 2 - semester 1 _2015
Unique number: 525519
SECTION B
Q1.
You have been employed as a system developer in Q systems. Explain to your new
team members the following process activities; specification, validation and evolution
[10]
Answer:
Software specification
Software specification is the process of establishing what services are required
and the constraints on the system’s operation and development.√
Therefore, the requirements engineering process include the
following:
•
Feasibility study: Is it technically and financially feasible to build
the system? √
• Requirements elicitation and analysis: What do the system stakeholders
require or expect of the system? √
• Requirements specification: Defining the requirements
in detail√
• Requirements validation: Checking the validity of the
requirements√
Software validation
Verification and validation (V & V) is intended to show that a system conforms to its
specification and meets the requirements of the system customer. √
•
•
It Involves checking and reviewing processes and system testing. √
System testing involves executing the system with test cases that are derived
from the specification of the real data to be processed by the system. √
Software evolution
Software is inherently flexible and can change. As requirements change through changing
business circumstances, the software that supports the business must also evolve and
change√. Although there has been a demarcation between development and evolution
(maintenance), it is increasingly irrelevant as fewer and fewer systems are completely new√
Q2.
Members of your software development team think that agile methods should be
based on principles .Explain the principles of agile methods to the team. [10]
Answer
The principles of agile methods include the following:
Principle
Customer involvement. √
Incremental delivery. √
People not process. √
Maintain simplicity. √
Description
Customers should be closely involved throughout the development process. Their role is to
provide and prioritise new system requirements and to evaluate the iterations of the
system. √
The software is developed in increments with the customer specifying the requirements to
be included in each increment. √
The skills of the development team should be recognised and exploited. Team members should
be left to develop their own ways of working without perspective processes. √
Accept that the system requirements will change and design the system to accommodate
these changes. √
Focus on simplicity in both the software being developed and in the development
process. √ Wherever possible, actively work to eliminate complexity from the system. √
Q 3.
What are the fundamental concepts of user and system requirements and why must
these requirements be written in different ways?
[15]
Answer:
The concept “requirement” may range from a high-level abstract statement of a service or
of a system constraint to a detailed mathematical functional specification√. This is
inevitable
as
requirements
may
serve
a
dual
function√
•
•
•
It may be the basis for a bid for a contract and must, therefore, be open to interpretation √.
It may be the basis for the contract itself and must, therefore, be defined in detail√.
Both these statements may be called requirements√.
If a company wishes to let a contract for a large software development project, it must define
its needs in a sufficiently abstract way that a solution is not pre-defined√. The requirements
must be written so that several contractors can bid for the contract, offering, perhaps,
different ways of meeting the client organization’s needs√√. Once a contract has been
awarded, the contractor must write a system definition for the client in more detail so that the
client understands and can validate what the software will do√. Both of these documents may
be called the requirements document for the system (Sommerville, 2011) √.
There are two types of requirements:
User requirements: Statements in natural language plus diagrams of the services the system
provides; and its operational constraints – written for customers. √√
System requirements: A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. It define what should be
implemented, therefore, it may be part of a contract between client and contractor√√.
Add 1mark for any additional point from the student. √
Q4.
As a system developer, your organisation requires you to make a decision on system
architecture. Explain to your organization members what decisions have to be made
about the system during the architectural design process? [15]
Answer:
Architectural design is a creative process so the process differs depending on the type of
system being developed√√. However, a number of common decisions span all design
processes and these decisions affect the non-functional characteristics of the system√√.
•
•
•
•
•
•
•
•
Is there a generic application architecture that can be used? √√
How will the system be distributed? √√
What architectural styles are appropriate? √
What approach will be used to structure the system? √
How will the system be decomposed into modules? √√
What control strategy should be used? √
How will the architectural design be evaluated? √
How should the architecture be documented? √
Q5.
Development testing forms an integral aspect of system development. Explain the following, unit
testing, component testing and system testing. [10]
Answer:
Development testing includes all testing activities that are carried out by the team
developing the system√.
•
•
•
Unit testing– where individual program units or object classes are tested. Unit testing should
focus on testing the functionality of objects or methods. √√√
Component testing – where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces. √√√
System testing – where some or all of the components in a system are integrated and the system is
tested as a whole. System testing should focus on testing component interactions. √√√
Q6. Briefly describe the three main types of software maintenance. Why is it sometimes difficult
to distinguish between them?[10]
The three main types of software maintenance are:
1. Corrective maintenance or fault repair. The changes made to the system are
to repair reported faults which may be program bugs or specification errors
or omissions. √√
2. Adaptive maintenance or environmental adaptation. Changing the software
to adapt it to changes in its environment e.g. changes to other software
systems√√.
3. Perfective maintenance or functionality addition. This involves adding new functionality or
features to the system. √√
They are sometimes difficult to distinguish because the same set of changes may cover all three
types of maintenance. √ For example, a reported fault in the system may be repaired by
upgrading some other software and then adapting the system to use this new version (corrective
+ adaptive). √ The new software may have additional functionality and as part of the adaptive
maintenance, new features may be added to take advantage of this. √√
Q7. What are the strategic options for legacy system evolution? When would you normally
replace all or part of a system rather than continue maintenance of the software? (15)
The strategic options for legacy system evolution are:
1. Abandon maintenance of the system and replace it with a new system. √√
2. Continue maintaining the system as it is. √√
3. Perform some re-engineering (system improvement) that makes the system easier to
maintain and continue maintenance. √√
4. Encapsulate the existing functionality of the system in a wrapper and add new functionality
by writing new code which calls on the existing system as a component. √√
5. Decompose the system into separate units and wrap them as components.
This is similar to the solution above but gives more flexibility in how the system is used. √√
You would normally choose the replacement option in situations where the
hardware platform for the system is being replaced, √√where the company wishes to
standardize on some approach to development that is not consistent with the current
system, √√ where some major sub-system is being replaced (e.g. a database system) or
where the technical quality of the existing system is low and there are no current
tools for re-engineering√.
8 . Suggest two important types of application where you would not recommend the use of
service-oriented architecture.[15]
1. Embedded applications√√ in devices where a network connection cannot be
guaranteed√. These are unlikely to make use of services as there is no
guarantee that these services will be available when required. √√√
2. Real-time applications√√ with stringent deadlines, especially those with lots of
user interaction √√e.g. computer games√. In these applications, the performance
overhead in coding and decoding XML messages is likely to be unacceptable√√
Give 2 extra marks to any student who add additional point√√