COMP1648.docx

Development framework methods

COMP1648: Development framework methods UOG No: Academic Session: May 2015 Student Name:

UOG.REG.NO 1


Acknowledgement

UOG.REG.NO 2


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


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, company’s 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 PE’s problem domain. (PE ltd case study).

UOG.REG.NO 4


Section A

UOG.REG.NO 5


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

-


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 PE’s 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 PE’s development. UOG.REG.NO 7


Iterative and incremental development. Not only in the PE’s development process, it’s 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) it’s 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 PE’s development, because DSDM’s 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


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


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


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 Lucas’s 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


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 customer’s 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 customer’s 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


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 customer’s spending R15 - Mobile app for ordering and tracking R16 - Email confirmation for all orders

UOG.REG.NO 13


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 customer’s 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


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 customer’s spending – R14

Would have 

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

UOG.REG.NO 15


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 can’t 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 won’t 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. Won’t 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


Section C

UOG.REG.NO 17


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 Commissioner’s 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 customer’s 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


Information must be retention which is to be kept no longer than necessary for stated purpose. To operate with the PE’s 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 PE’s 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


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 PE’s 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 system’s 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 PE’s 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


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


Conclusion In this assignment it includes the PE Company’s new system development. First I have mentioned DSDM method is an appropriate method to use within PE’s 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


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


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

UOG.REG.NO 24

COMP1648.docx

Recommend Documents