Development framework methods

COMP1648: Development framework methods

UOG No:
Academic Session: May 2015
Student Name:

UOG.REG.NO 1

Development framework methods

Acknowledgement

UOG.REG.NO 2

Development framework methods

Table of contents
1. Introduction
-------------------------------------------------------------------------------------4
2. Section A -------------------------------------------------------------------------------------------5
A. DSDM would be an appropriate method to use with in PE -----------------------------6
3. Section B ------------------------------------------------------------------------------------------9
B1.1 Non-high-level requirements --------------------------------------------------------------10
B1.2 High-level requirements -------------------------------------------------------------------10
B2.1 prioritizing requirements by MoSCoW -------------------------------------------------14
B2.2 Explanation of prioritizing -----------------------------------------------------------------14

4. Section C ------------------------------------------------------------------------------------------17
C1. Need of a data controller ---------------------------------------------------------------------18
C2. Purpose of BCS code of conduct -----------------------------------------------------------20
5. Conclusion
---------------------------------------------------------------------------------------22
6. Reference
-----------------------------------------------------------------------------------------23
7. Bibliography ------------------------------------------------------------------------------------- 24

UOG.REG.NO 3

Development framework methods

Introduction
According to the case study Paint everything (PE) is a medium sized company that manufactures
and sells paint. Two years ago managing director decide to improve sales by adding an online
store. So, companys IT team was appointed to the task. But year later the system was still not
completed and unfit for purpose and user requirements not being met. Three months ago newly
appointed managing director decide to start the project again. To complete the task company
requested the help of an external IT consultant, Sally flowers (SF) and also asked for her
assistance in recruiting an additional it team. Board meeting has been held and according to the
meeting the directors need to see a quick result, since the project has been running for long
period without any success and they need early justification. Most importantly they wanted a
basic system will be up running in 4 months time. New, MD hired an IT consultant to get help
on building a new system. This assignment is on the method that going to use to overcome the
PEs problem domain. (PE ltd case study).

UOG.REG.NO 4

Development framework methods

Section A

UOG.REG.NO 5

Development framework methods

A. DSDM would be an appropriate method to use with in PE

According to the above introduction SF (IT consultant) has decided to recommend Dynamic
Systems Development Method (DSDM) atern which is a Rapid Application Development (RAD)
framework. DSDM is not limited to specific tools and techniques, users must be actively
participate to the development process.
Source
AGILE
Methods
http://dsdmofagilemethodology.wikidot.com/

Fig
1
AGILE
Methods
http://dsdmofagilemethodology.wikidot.com/

UOG.REG.NO 6

of

of

Software

Software

Development

Development

Development framework methods

Overcoming PE problem according to 9 DSDM principles are as follow.

Active user involvement is imperative, which is all the parties in the development should
actively involve to the project. According to case study PE already failed on the project because
the end-user needs were not being met. Not enough attention to the problem domain from the
users and poor involvement of existing IT team had caused (Information systems development
review). So, by following this principal in PE problem will be help to get exactly the write
system PE need.
DSDM teams are empowered to make decisions. In normal developments, decisions are taking
by to an order from bottom it has to go to the upper positions and after the approval of senior
management the decision can be made. This makes accurate decisions but it cost more time. As
in the case study senior management of PE wanted a basic system will be up and running in 4
months time. So, the development team have save the time. By following this DSDM principle
in PE, the development teams given authority to make certain (not all) decisions, then they
always keep a track on time. (Appendix B facilitated work shop data/ introduction and terms of
reference)
Requirements are base lined at a high level. In the meeting each person was asked to list their
requirements by IT consultants (Sally Flowers, Richard Zimmer). As PE need a fast development
all the requirements must be prioritized. To do the fast development DSDM do not implement all
the requirements. There for it uses MoSCoW prioritization and separate the requirements into
priority levels. That makes a base lined for requirements so, the high priority requirements can be
done to complete the system fast.
Focus on frequent delivery. Each and every activity and output has clearly outlined in DSDM
methodology. So, in the meantime the development teams should fully attentive for outputs to
make sure that the outputs have not misses the user requirements. Focus on frequent delivery is a
must principle to have within the development of PEs system. Because the previously designed
system has not been met the user requirements in the end. To make sure to not happen it again it
is suitable to use DSDM methodology principles.
Fit for business. As mentioned in above paragraph the output of PE cannot be useless or unfit
for purpose. So, in the meantime outputs produced it is necessary to check whether the outputs
met the user requirements.
All the changes I development must be reversible. This DSDM methodology principle gives
an opportunity to make changes or correct any mistakes during the development. As PE needs a
fast development of the system, mistakes can be happen and changes will be need to do during
the development. Again this principle proves that, DSDM methodology is suitable for PEs
development.
UOG.REG.NO 7

Development framework methods

Iterative and incremental development. Not only in the PEs development process, its a risk
to all projects that to develop the whole system rather developing the system part by part. As
mentioned in the previous principles the mistakes can be happen and changes may need to be do
during the process. So, the iterative and incremental development is suitable for use within PE.
Otherwise it will cause more time to start over when a mistake has happen.
Testing is through the life cycle. Several techniques are using in the DSDM methodology, such
MoSCoW prioritization in a previous principle (requirements are base lined at a high level).
These techniques will clarify the work in DSDM development. So, in this principle time boxes,
at the end of each time box stake holders will have a common discussion to get the agreement for
the output. Not only the techniques also the framework of the life cycle will have number of
review stages to test whether has the development delivered the write output. As PE taking the
discussions with the stake holders (appendix B) its suitable to use DSDM methodology.
Communication and collaboration among all stake holders are essential. In order to follow
all above principles it is important to have regular communications and collaborations between
the stakeholders who involved to the development. As in the scenario PE works by facilitated
workshops. So, such activities going on PE it is suitable to have DSDM methodology to
overcome the solution of PE.
As explained DSDM methodology can be used to PEs development, because DSDMs
principles are most suitable for use within the development. Above explanation proves that and
DSDM is suitable for PE cause of such factors like PE needs fast development, need to meet the
exact user requirements and need early justification (DSDM uses prototypes).
In addition to the principles DSDM methodology use technique like Time boxing.

Fig 2 Time boxing - http://www.dsdm.org/content/13-timeboxing

In time boxing it separates the development work into parts and sets time periods. It is a welldefined technique and it will control the development of PE system in an iterative fashion, with
several specific review points to ensure the quality of the outcomes and the efficiency of the
delivery process. MoSCoW prioritization of the work within the Time box and re-assessment of
UOG.REG.NO 8

Development framework methods

what can be achieved in the agreed timeframe ensures that Time boxes finish on time. So, this
will be most needed to complete the system of PE in short time period.

Section B

UOG.REG.NO 9

Development framework methods

B1.1 Non-high-level requirements

B1.2 High-level requirements
Explaining of high level requirements those are the functional requirements that specifies
something the system should do. For example add student, record payment, search product
etc., these functional requirements includes the business rules, transaction processes,
administrative functions, authorizations, certification requirements etc. In the other hand nonhigh-level requirements specifies how the system should behave. Such like performance,
reliability, security, data integrity etc.
According to appendix B participants in the meeting were asked to list their requirements by
external IT consultants. So, Scott Hardy (managing director), Wendy Lucas (finance), Frederick
Davenport (central quality unit), Catherine Lee (head of operations) and William Bland (head of
IT) have list down their requirements and it is not appropriate as a set of requirements for build
the system. Because some of the requirements are not high level requirements. The review on the
inappropriate requirements are as follow.
In central quality unity Frederick Davenport has mentioned his requirements. But to build up the
system, only need the high-level requirements. As I identified, there are non-high-level
requirement such as A - data integrity and security is paramount. This is must thing to
consider about but it is not functional requirement. This is a behavior of the system that make
sure the quality of the system. B - Transparent about data collection, this also a non-high-level
requirement which was mentioned by Frederick Davenport. This makes security and
serviceability for customers also make the behaviors of a good system.
The main objective in scenario to build an online system to the PE which is currently having an
ongoing system. So, with regarding to that William Bland (head of IT) has mentioned his
requirements. He is telling, C - Development of the system must not impact on the job of
anyone not involved in the project. This is straightly an external behavior of the upcoming
system. This has nothing to with the functions of the system. But as he said this will make some
impact to the employees in the PE or maybe not. And that makes C a non-high-level
requirement. Also he is telling D - Development, testing and release of the new system cannot
cause downtime on the current system. As in C, D does not content the functions that the
upcoming system should do. It is a caution that can happen to the current system by the new
system which makes the behavior of the new system. So, D also a non-high-level requirement.
As final requirement he is strongly suggesting to E trash the current version of the system
and start over. As it is in the words it is a suggestion but not a function that the system should
do. That makes the E non-high-level requirement.
In above two paragraphs I have mentioned the non-high-level requirements. Below are the highlevel requirements as I identified according to the list of requirements submitted by the
participants of the meeting.
UOG.REG.NO 10

Development framework methods

Managing director
From requirements which are mentioned by Scott Hardy I got bellow high-level requirements.
R1 Track orders and shipping
R2 Differentiate customers who are artists and who are doing home renovations
R3 Placing order
R4 Clients may have facility to rate and give feedback on products
In here R1 gives the main functions that should be in the system. User should be able to track the
orders and track the shipping of the products. At it should be in the system, R1 is high-level
requirement. R2 It tells system should separate customers who are artists and who are doing
home renovations. As in the scenario those are target customers of PE. System should identify
the customers properly to provide a good service to them. So, this makes R2 high-level
requirement that should be on the system. R3 placing orders, is another main function which
should be on the system. When a customer accessing the online store he should be able to place
the order at the moment, if he feels it is the right product which he want. After he received the
product he would be able to give a feedback on the product lately in the system. That makes R4
high-level requirement.
Finance
Following are the high-level requirements from the Wendy Lucass requirements list.
R5 - Monitor sales
R6 - Compare the revenue of different product lines
R7 - Links with social media
R8 - Eliminate the tick boxes, in the terms and conditions field.
As it is in the scenario the main purpose of the new system is to improve sales. To do that PE
must have clear idea about the sales. So, R5 function is high-level requirement which should be
on the system. Also PE able to compare the earnings of different product lines so they can give
more attention on poor revenue products. So, R6 is a function too which should be in the system
as a high-level requirements. R7 links with the social media, to improve sales marketing is
much needed thing. The function R7 should be in the system to make marketing easier to PE.
Tick boxes in the terms and conditions also a function usually in the online systems. But PE have
different view on that to eliminate the tick boxes to not annoy customers. This function can be
ignored as in R8 when developing system.

UOG.REG.NO 11

Development framework methods

Central quality unit

High-level requirements from the Frederick Davenport are as below.
R9 - Making payments
R10 - Store card information
R11 - Return unsatisfied products
If it is an online store customers should be able to buy products online. And as in the other
systems system should store the card information of the customers for make future payments
easier. R9 and R10 functions should be on the system as high-level requirements to build the
system. A good company must satisfy the customers. So, to do that the R11 function should be
on the system. Customers could be able return the unsatisfied products to the PE through the
system.
Head of operations
As final high-level requirements below are from the requirements list of Catherine Lee ().
R12 - Search facility to find products
R13 - Produce sales reports in different product lines
R14 - Automatic marketing that aligns with a customers spending
R15 - Mobile app for ordering and tracking
R16 - Email confirmation for all orders
According to the case study of PE store is having lot of products, in that case through the online
system customer should be able find the particular product by search facility. Also producing
sales reports is a must need thing to have, because it will be helpful to get decisions when
considering of the improving sales. R12 and R13 functions should be in the system as they are
high-level requirements. As I previously mentioned marketing is important and R14 - Automatic
marketing that aligns with a customers spending will make that more achievable. In addition
to the main functions there are some functions that not essential but if need can be have within
the system. But after all those are also functions which makes them high-level requirements such
like R15 and R16.

UOG.REG.NO 12

Development framework methods

Summarizing of high-level requirements

R1 Track orders and shipping

R2 Differentiate customers who are artists and who are doing home renovations
R3 Placing order
R4 Clients may have facility to rate and give feedback on products
R5 - Monitor sales
R06 - Compare the revenue of different product lines
R07 - Links with social media
R08 - Eliminate the tick boxes, in the terms and conditions field.
R09 - Making payments
R10 - Store card information
R11 - Return unsatisfied products
R12 - Search facility to find products
R13 - Produce sales reports in different product lines
R14 - Automatic marketing that aligns with a customers spending
R15 - Mobile app for ordering and tracking
R16 - Email confirmation for all orders

UOG.REG.NO 13

Development framework methods

B2.1 prioritizing requirements by MoSCoW

B2.2 Explanation of prioritizing

Finalized high-level requirements list is as below.

Requirement ID
R1
R2
R3
R4
R5
R6
R7
R8

Eliminate the tick boxes, in the terms and

conditions field.

R9
R10
R11
R12

Making payments
Store card information
Return unsatisfied products
Search facility to find products

R13

Produce sales reports in different product

lines
Automatic marketing that aligns with a
customers spending
Mobile app for ordering and tracking
Email confirmation for all orders

R14
R15
R16

UOG.REG.NO 14

Requirement
Track orders and shipping
Differentiate customers who are artists and
who are doing home renovations
Placing order
Clients may have facility to rate and give
feedback on products
Monitor sales
Compare the revenue of different product
lines
Links with social media

Development framework methods

According to MoSCoW prioritization, prioritized set of high-level of requirements are as below.

Must have

Track orders and shipping R1

Placing order R2
Monitor sales R5
Compare the revenue of different product lines R6
Making payments R9
Store card information R10
Return unsatisfied products R11
Search facility to find products R12
Produce sales reports in different product lines R13

Should have

Differentiate customers who are artists and who are doing home renovations R2
Clients may have facility to rate and give feedback on products R4
Links with social media - R7

Could have

Mobile app for ordering and tracking R15

Email confirmation for all orders R16
Automatic marketing that aligns with a customers spending R14

Would have

Eliminate the tick boxes, in the terms and conditions field. R8

UOG.REG.NO 15

Development framework methods

As we follow DSDM attren development method to develop the system, the time to complete the
project has been fixed. So, identifying the pri
orities will help to complete the project within the dead line. As it is tool of DSDM atrem
methodology here we used MoSCoW prioritization to identify the requirements. Above I have
clearly shown the requirements in the each field in MoSCoW.
Must have field includes the most needed requirements that project is responsible for deliver
within the exact time period. This is more likely, project cant be completed without fulfilling
these requirements. So, complete the project it is must to complete following requirements R1,
R3, R5, R6, R9, R10, R11, R12 and R13.
Should have field includes the requirements that much important compared to should have and
wont have. But still project can be completed only with the Must have requirements. As
identified R2, R4 and R7 are the Should have requirements.
Could have requirements are less important comparing to the should have requirements.
Considering the requirements mentioned in could have field R15, R16 and R14 are the
requirements that can have within the system but without it there will be no impact to the system.
Wont have includes the requirements that project will agreed to not deliver or not to deliver in
this time. As it is in the case study PE asking to R8 within the system. So, directly development
team can ignore this requirement.
Source - MoSCoW Prioritization, URL - http://www.dsdm.org/content/10-moscow-prioritisation

UOG.REG.NO 16

Development framework methods

Section C

UOG.REG.NO 17

Development framework methods

C1 Need of a data controller

According to the data protection act (1998) data controller is the body (companies,
Government Departments or voluntary organizations) or individuals (a person alone or jointly or
in common with other persons) determines the purposes and means of the processing of personal
data. Also this act protects all personal data which in electrical or manual file system. The act
mentioning, only the relevant authority can deal with the personal data such as household
records, finance records, public information on national security or information of crime, health,
education and social work held by relevant authority, sensitive personal data.
Considering PE they are going to deal with some personal data. As examples store card
information and online payment process. So, those are falling into finance records and public
records categories which have protect as personal data according to the data protection act
1998. As in the act relevant authority can only do process personal data who is data controller.
So, that makes PE to have data controller within the company. A data controller must have to
notify them self for the information commissioner before they start their work. The
Commissioners role is to ensure that data controller keep personal data according to the
provisions of the Acts. Information Commissioner has authority to assist him in ensuring that the
principles of data protection are being observed.
Every data controller must comply with the principles defined by data protection net which has
concerns legal, social, ethical and professional issues. Under this condition having a Data
controller within in PE will overcome the LSEPI that PE may be faced with. The principles are
as below.
Data must be obtain fairly and lawfully. When considering example I have given previously if
PE going to store their customers card information, it has to be done under these condition
according to right full laws and fairly. Because card information straightly involve the law
conditions. So, this can make PE to not involve with unwanted legal issues.
The information need to be held and process only for specific purpose. The other example
that I have given is online payment process. So, the stored information about the cards must be
used to this specific payment process only.
The information that use should be adequate which is relevant and not excessive for the
purpose. This make sure that the data controller must only obtain minimum personal data from
the user. When storing card information, the information must be gather with relevant to the
purpose of payment process.
The information should be accurate, complete and up to date. Basically, cards have time
period and after that they are inactive which is no longer in service. When PE handling the card
information, it has to accurate. Otherwise it will cause some systematically issues for PE and to
the customer both, when those card information on the action.
UOG.REG.NO 18

Development framework methods

Information must be retention which is to be kept no longer than necessary for stated
purpose. To operate with the PEs system customers have to be sign up. To proceed a complete
buying of a product he or she has to sign up and store card information. So, the gathered
information will be on the system until the customer completely sign off with the system, which
is no longer connect with the system. Purpose of the information of particular customer is no
longer necessary. So, the information can be archived.
Always processing information with respect to the rights of the data subject. The first
example that I have given was string Card information. Considering this, the owner of the
information profile may ask to see the data, what PE kept. Customer must have that right to gain
full confident about the company. Otherwise this will cause issues to the company.
The information must be safe and secure. PE must guarantee that necessary technical and
organizational measures has taken against loss, damage, disclosure and unlawful use. If
information about the customers are not secure it can be misuse and can cause lot of damage to
customers and that will make legal issues to PE. So, to overcome that the information must be
secure and safe.
The information should not be transferred outside European Union unless adequate level
of protection to the rights of the subject. Which means if the data is to be transfer it have to
fulfil some conditions and rights of the PEs customers.
As above data controller will comply with these principles and he will make PE to overcome the
legal, social, ethical and professional issues.
Source - A Guide for Data Controllers,
URL - https://www.dataprotection.ie/documents/forms/NewAGuideForDataControllers.pdf
Source - Guidance: Data Controllers responsibilities,
URL - https://www.justice.gov.uk/downloads/information-access-rights/data-sharing/annex-gguidance-data-controllers.pdf

UOG.REG.NO 19

Development framework methods

C2 Purpose of BCS code of conduct

Basically a code of conduct is a set of rules which demonstrate the responsibilities to a person or
an organization. These code of conducts may be with in different fields. So, in computing filed
there are some codes such as BCS code of conduct, IMIS code of ethics, ACM/IEEE etc.
according to the case study PE needs to know purpose of the BCS code of conduct and how it
will work. Considering BCS code of conduct, it includes the set of professional standards for
members in BCS. The code rules the personal conduct as a member of BCS. Code do not rules
the nature of business ethics of the relevant authority.
BCS code of conduct includes four section. A professional who contracted to PE have to consider
those four sections if he going to work for PE with respect to the BCS code of conduct.
Public interest
The system developers have to proceed the work with due care (public health, privacy and
security) for PEs employees and the environment. Also they have to respect to the legitimate
rights of third parties who are the customers of PE. As an example customers of PE have rights
with regarding to the online system. Such as customer have the right to ask for the information of
him that the company keep of. There for system developers has to ensure data transparency when
gathering customer information. Because as a system requirement PE wants the systems to be
transparent about the data collection related to customers (From requirement list exercise).
Along with that the system developers must carry their activities without any discrimination
against the clients and colleagues.
Duty to relevant authority
According to the code of conduct between system developers and the authority of PE must have
a good bond. So, the developers shall avoid the situations that may give bribes. Also the
developers shall not leak the information for benefit the third party or use for personal gain.
Those confidential information lie only within the relevant authority. Another most important
thing is not to misrepresents or withhold information about the system or service for take
advantage of the lack of knowledge of PEs employees. As an example in information system
development review they have mentioned the current IT department exists low knowledge in
web development. So, in such situations the developers must deal honestly and shall not take any
advantage.
Duty to the profession
As for the PE the system developers must do his duty the profession. According to BCS, its
member shall uphold the reputation and good standing of the BCS and shall seek to improve the
BCS through participating its activities in their development. Also have to act with integrity in
relationships with all other members of other professions. As duty to the profession the
developers shall not make any public statements unless they properly qualifies and authorized to
UOG.REG.NO 20

Development framework methods

do so. As an example he shall not make statements to represent in the developing system on
behalf of the BCS unless authorized to do.
Professional Competence and integrity
According to the BCS code of conduct the system developers shall look to upgrade their
knowledge and shall maintain the awareness of technological development procedures which are
particular to their field. As to the code of conduct the developers shall not undertake any of work
or not agree to provide service that is not within their professional. As example PE needs to
develop online system, so the developers who undertaking the project should possess a web
development skills. Regarding to the example the developers shall observe the relevant BCS
code of practices which in his decisions are relevant.
As above the four section of BCS code of conduct show the professional issues that a system
developers contracted to PE may have to consider before he undertake the project.
Source - BCS the Chartered Institute for IT, Trustee Board Regulations - Schedule 3, Code of
Conduct for BCS Members
URL - http://www.bcs.org/upload/pdf/conduct.pdf

UOG.REG.NO 21

Development framework methods

Conclusion
In this assignment it includes the PE Companys new system development. First I have
mentioned DSDM method is an appropriate method to use within PEs development process.
Then I have done the requirement categorizing. There I have identified high-level and non-highlevel requirements and I prioritized the requirements according to MoSCoW. Next it includes the
need of a data controller to the company and how it will help to LSPE issues. Finally the purpose
of BCS code of conduct and explained about the four section of BCS code of conduct which may
the contractor who contracted to PE need to consider.

UOG.REG.NO 22

Development framework methods

Reference
AGILE Methods of Software Development - http://dsdmofagilemethodology.wikidot.com/
Fig 1 - AGILE Methods of Software Development http://dsdmofagilemethodology.wikidot.com/
Fig 2 Time boxing - http://www.dsdm.org/content/13-timeboxing
MoSCoW Prioritization, URL - http://www.dsdm.org/content/10-moscow-prioritisation
A Guide for Data Controllers,
URL - https://www.dataprotection.ie/documents/forms/NewAGuideForDataControllers.pdf
Guidance: Data Controllers responsibilities,
URL - https://www.justice.gov.uk/downloads/information-access-rights/data-sharing/annex-gguidance-data-controllers.pdf
BCS the Chartered Institute for IT, Trustee Board Regulations - Schedule 3, Code of Conduct for
BCS Members, URL - http://www.bcs.org/upload/pdf/conduct.pdf

UOG.REG.NO 23

Development framework methods

Bibliography
Functional vs. Non Functional Requirements - http://reqtest.com/requirements-blog/functionalvs-non-functional-requirements/#conversion-0

UOG.REG.NO 24