Uploaded by Ahmi khan

pdf (4)

MEMO INF3705 Assignment 2 - semester 1 _2015
Unique number: 525519
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
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
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
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√
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]
The principles of agile methods include the following:
Customer involvement. √
Incremental delivery. √
People not process. √
Maintain simplicity. √
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?
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
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. √
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]
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? √
Development testing forms an integral aspect of system development. Explain the following, unit
testing, component testing and system testing. [10]
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
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√√