The software process as part of software engineering.............. 118 ...... through communication with a bank official, most often via Call center;. Depending on the ...
Assoc. Prof. PhD Silvia Parusheva Assoc. Prof. PhD Kolyo Nestorov Chief Assist. Prof. PhD Olga Marinova
Electronic Business 2 n d Part Software Development Management
2
Assoc. Prof. PhD Silvia Parusheva Assoc. Prof. PhD Kolyo Nestorov Chief Assist. Prof. PhD Olga Marinova
Electronic Business 2 nd Part Software Development Management
Editor Assoc. Prof. PhD Silvia Parusheva
2015 Publishing house „Science and Economics” University of Economics – Varna
3
This book or any part of it may not be copied or distributed electronically without the written permission of the Publishing House. Silvia Stoyanova Parusheva, Kolyo Canev Nestorov, Olga Vladimirova Marinova, authors, 2015. Editor Assoc. Prof. PhD Silvia Parusheva Reviewer: Prof. PhD Vladimir Sulov Publishing house „Science and Economics”, 2015. ISBN 978-954-21-0837-5
4
CONTENTS INTRODUCTION ....................................................................................................... 12 PART A. ELECTRONIC BUSINESS 2 n d Part ............................................. 14 MODULE E-FINANCE .............................................................................................. 15 Chapter 1. ONLINE TRADING ................................................................................ 15 1.1. Participants and functions of online trading ................................................15 1.2. Advantages of online brokerage ..................................................................17 1.3. Development and state of e-brokering .........................................................18 Literature ....................................................................................................21 Internet sources ...........................................................................................21 Self-study questions ....................................................................................22 Chapter 2. ELECTRONIC BANKING ..................................................................... 24 2.1. The essence of electronic banking ...............................................................24 2.2. Types of electronic banking .........................................................................26 2.2.1. Telephone banking ...........................................................................26 2.2.2. PC banking .......................................................................................28 2.2.3. Internet banking ................................................................................29 2.2.5. Mobile banking .................................................................................40 2.2.6. TV banking .......................................................................................43 Literature ....................................................................................................45 Internet sources ...........................................................................................45 Self-study questions ....................................................................................46 Chapter 3. SECURITY AND PROTECTION OF INTERNET BANKING ......... 47 3.1. Potential threats for Internet banking users .................................................47 3.1.1. Phishing ............................................................................................48 3.1.2. Vishing..............................................................................................49 3.1.3. Pharming ...........................................................................................49 3.1.4. Trojan horses (Trojans) ....................................................................50 3.1.5. Spyware ............................................................................................52 3.1.6. Keystroke logging (Кeyloggers).......................................................52
3.2. Identity theft .................................................................................................53 3.3. Methods for protection and authentication of users .....................................55 3.3.1. Something the user knows ................................................................56 3.3.2. Something the user has .....................................................................56 3.3.3. Something the user is ........................................................................59 3.3.4. Different channel authentication ......................................................59 3.3.5. Double factor and multi factor user authentication ..........................60 Literature ....................................................................................................61 Internet sources ...........................................................................................61 Self-study questions ....................................................................................62 Chapter 4. ONLINE INSURANCE ........................................................................... 63 4.1. Nature and purpose of online insurance.......................................................63 4.2. Peculiarities of insurance business that complicate online insurance..........64 4.3. E-business models for Internet distribution of insurance products ..............65 4.3.1. Insurance companies websites ..........................................................65 4.3.2. Financial portals ...............................................................................67 4.3.3. Point-of-sale portals ..........................................................................68 4.3.4. Aggregators ......................................................................................68 4.4. Applicability of online insurance and its reception by consumers ..............69 Literature ....................................................................................................70 Internet sources ...........................................................................................71 Self-study questions ....................................................................................71 MODULE E-GOVERNMENT .................................................................................. 73 Chapter 5. ADMINISTRATIVE PROCESSES ....................................................... 73 5.1. Nature of the administrative process ............................................................73 5.2. Structure of the process ................................................................................77 5.3. Information process......................................................................................83 Literature ....................................................................................................87 Internet sources ...........................................................................................87 Self-study questions ....................................................................................87
6
Chapter 6. ADMINISTRATING AN ELECTRONIC GOVERNMENT WEBSITE ..................................................................................................................... 88 6.1. Institutional site ............................................................................................88 6.2. Unified portal – the “one stop” principle .....................................................91 Literature ....................................................................................................98 Internet sources ...........................................................................................98 Self-study questions ....................................................................................98 Chapter 7. E-DOCUMENT MANAGEMENT .......................................................100 7.1. Structure and elements of an e- Document ................................................100 7.2. Electronic digital signature ........................................................................103 Literature ..................................................................................................107 Internet sources .........................................................................................107 Self-study questions ..................................................................................108 PART B. SOFTWARE DEVELOPMENT MANAGEMENT ..................109 Chapter 1. MAIN CONCEPTS, SOFTWARE PROPERTIES, SOFTWARE ENGINEERING ........................................................................................................110 1.1. Programmes and software products .................................................................110 1.1.1. History ...........................................................................................110 1.1.2. Problems ........................................................................................112 1.1.3. Definitions......................................................................................112 1.2. Properties of software ..............................................................................113 1.3. Software engineering ...............................................................................116 1.3.1. Terminology ..................................................................................116 1.3.2. Definitions......................................................................................116 1.3.3. Objectives ......................................................................................117 1.3.4. The software process as part of software engineering ..............118 References and Internet sources ...........................................................120 Self-study questions ................................................................................120 Chapter 2. SOFTWARE BUSINESS – UNIQUENESS AND REGIONAL CHARACTERISTICS. MAIN STRATEGIC ISSUES..........................................121 2.1. Uniqueness of the software business ......................................................121 7
2.2. Regional aspects of software business ....................................................123 2.2.1. Europe............................................................................................123 2.2.2. Japan ..............................................................................................124 2.2.3. USA ................................................................................................124 2.3. Software business – 6 strategic questions ..............................................125 2.3.1. Products or services ......................................................................126 2.3.2. Target market ...............................................................................127 2.3.3. Horizontal or vertical market segmentation ..............................128 2.3.4. Continuous flow of income ..........................................................129 2.3.5. Company orientation – leader, follower or a complementing company ..............................................................................................................131 2.3.6. Characteristics of the relations with other stakeholders ..........131 References and Internet sources ...........................................................132 Self-study questions ................................................................................132 Chapter 3. AGILE METHODOLOGIES FOR SOFTWARE DEVELOPMENT – GENERAL PRINCIPLES AND PRACTICES. DIFFERENCES BETWEEN CLASSICAL AND AGILE METHODOLOGIES .................................................134 3.1. Origin and concept of agile methodologies ...................................134 3.2. Comparison between agile and classical methodologies ..............137 References and Internet sources ...........................................................139 Self-study questions ................................................................................140 Chapter 4. NATURE, PROCESS AND APPLICATION OF THE XP, SCRUM, FDD, DSDM, ASD METHODOLOGIES ...............................................................141 4.1. Extreme Programming - XP ...........................................................141 4.2. SCRUM methodology .....................................................................142 4.3. Adaptive Software Development - ASD ........................................146 4.4. Dynamic System Development Method - DSDM..........................147 4.5. Feature Driven Development (FDD) ..............................................149 References and Internet sources ...........................................................150 Self-study questions ................................................................................151
8
Chapter 5. SCRUM – CONCEPT, CHARACTERISTICS, PROCESS, PRINCIPLES, ROLES. APPLICATION OF SCRUM - HISTORY, PRODUCT BACKLOG, SPRINT BACKLOG, BURNDOWN CHART .................................152 5.1. Introduction ..............................................................................................152 5.2. Main concepts ...........................................................................................152 5.2.1. Sprint .............................................................................................152 5.2.2. User stories ....................................................................................153 5.2.3. Roles ...............................................................................................154 5.2.4. Product Backlog ............................................................................155 5.2.5. Sprint Backlog...............................................................................156 5.2.6. Burndown chart ............................................................................156 5.2.7. Meetings .........................................................................................157 References and Internet sources ...........................................................159 Self-study questions ................................................................................159 Chapter 6. CREATING A PRODUCT BACKLOG. PLANNING A SPRINT IN SCRUM ......................................................................................................................160 6.1. Creating the Product Backlog .................................................................160 6.2. Sprint Planning in Scrum ........................................................................161 References and Internet sources ...........................................................165 Self-study questions ................................................................................166 Chapter 7. EXTREME PROGRAMMING (XP) – CONCEPT, DIFFERENCES FROM OTHER SOFTWARE METHODOLOGIES. THE FOUR CONTROL VARIABLES ..............................................................................................................167 7.1. The concept of XP ....................................................................................167 7.2. Main problems in software engineering and how XP deals with them ..........................................................................................................................169 7.3. The four control variables .......................................................................170 References and Internet sources ...........................................................173 Self-study questions ................................................................................173 Chapter 8. THE FOUR FUNDAMENTAL VALUES OF XP. BASIC AND LESS CENTRAL PRINCIPLES IN XP ............................................................................174 9
8.1. The four fundamental values ..................................................................174 8.2. Basic principles .........................................................................................176 8.3. Less central principles .............................................................................177 References and Internet sources ...........................................................179 Self-study questions ................................................................................180 Chapter 9. 12 PRACTICES IN XP ..........................................................................181 9.1. Concept of the 12 practices .....................................................................181 9.1.1. Planning Game ..............................................................................181 9.1.2. Small releases ................................................................................182 9.1.3. Metaphor .......................................................................................183 9.1.4. Simple design.................................................................................183 9.1.5. Testing............................................................................................184 9.1.6. Refactoring ....................................................................................184 9.1.7. Pair programming ........................................................................184 9.1.8. Collective ownership ....................................................................185 9.1.9. Continuous integration ................................................................185 9.1.10. 40-hour week ...............................................................................186 9.1.11. On-site customer .........................................................................186 9.1.12. Coding standards ........................................................................187 Self-study questions ..................................................................................188 References and Internet sources ...............................................................188 Chapter 10. PLANNING IN XP. DEFINITION OF REQUIREMENTS. RELEASE PLANNING ............................................................................................189 10.1. Planning in XP ........................................................................................189 10.2. Definition of requirements ....................................................................189 10.2.1. Main concepts .............................................................................189 10.2.2. Types of requirements ................................................................191 10.2.3. Tips for defining the requirements ...........................................192 10.3. Release planning .....................................................................................192 10.3.1. Exploration ..................................................................................193 10.3.2. Commitment................................................................................193 10
10.3.3. Steering ........................................................................................194 References and Internet sources ...........................................................195 Self-study questions ................................................................................195
11
INTRODUCTION E-finance and e-government are two of the main directions in the field of ebusiness that are fundamental to modern business processes of the companies, and end users. Electronic finance is closely linked with the application of modern information and communication technologies in the financial area. The advantages of Internetbased technologies significantly change the nature and structure of the financial services and allow both traditional and new providers to offer users an effective way of working with them. Issues related to e-government, cover theoretical and practical aspects of communication Consumer electronic means with state and municipal administration. The course Electronic Business 2 Part (part A) consists of two modules: Module “E-finance” and Module “E-government”. The material is structurally divided into chapters and subchapters, at the end of each chapter there are literature and Internet sources, as well as self-study questions. Module „Е-finance“ aims to provide knowledge about the theoretical and practical aspects of electronic financial services throughout their range covering online trading with securities and currencies, electronic banking, online insurance, security and protection of Internet banking. Module “E-government” provides scientific and practical knowledge in the field of Web-technologies and their application in public administration. It aims for acquiring knowledge about the opportunities for management, development and administration of projects in public administration. The Software Development Management course (part B) aims to present the specifics of the software business and some of the most popular agile methodologies for software development. The emphasis is on agile methodologies for software development and in particular on the most commonly used among them - SCRUM and XP. Basic thematic units refer to the examination of major principles, practices, actions and management strategies as well as practical guidelines for their application in software development process. Other discussed issues are related to develop a 12
common understanding of the requirements definition, priorities and constraints relevant to a software system. The acquired knowledge and skills in the area of software development management improve and enrich the students’ opportunities for being excellent developers and managers. The book consists of two parts written by: Assoc. Prof. PhD Silvia Parusheva – part A. Electronic Business 2nd Part, Module E-finance; Assoc. Prof. PhD Kolyo Nestorov – part A. Electronic Business 2nd Part, Module E-government; Chief Assist. Prof. PhD Olga Marinova – part B. Software Development Management. Editor of the book is Assoc. Prof. PhD Silvia Parusheva.
13
PART A. ELECTRONIC BUSINESS 2 nd Part
Authors: Assoc. Prof. PhD Silvia Parusheva – part A. Electronic Business 2nd Part, Module E-finance; Assoc. Prof. PhD Kolyo Nestorov – part A. Electronic Business 2nd Part, Module E-government
MODULE E-FINANCE Chapter 1. ONLINE TRADING By online trading we mean online trade in securities and currencies, i.e. placing orders and closing transactions for buying and selling securities or currency using Internet-based platforms that have been provided to consumers by intermediaries – traditional or electronic brokers (e-brokers). 1.1. Participants and functions of online trading Participation of consumers in the trade of securities and currencies in the global capital markets is carried out through the intermediacy of brokers, which according to the terminology adopted by Bulgarian market are called investment intermediaries. Banks can also act as intermediaries in this market. In order to place an order for buying or selling securities or currencies, clients make use of brokers over the counter, in their branch network, or through web-based platforms available on their sites – an opportunity that is the result of the advance of innovative electronic business in the financial sphere. Traditional brokerage companies with physically existing branch network (brick branches) can be related to two categories of broker: Classical brokers, called “full service brokers” – they provide the full range
of services: consulting clients in making investment decisions and legal service, maintaining a client trading account, accepting and executing orders for buying and selling securities, perhaps investment portfolio management, etc. discount brokers – their major activity is intermediacy in executing
individual investors’orders, whereby they mainly serve those clients, who make their own investment decisions (self directed). Discount brokers provide a limited range of consultancy. Their market presence is relatively high because of the lower commission rate they charge. In the days before the Internet investors had to communicate with their stockbroker from traditional brokerage companies mostly over the telephone. The brokerage company entered the order in their system, which was connected to the stock trading systems. In 1994 К. Aufhauser & Company, Inc (later acquired by what
is today the second biggest US online broker TD Ameritrade) became the first brokerage company to provide online trading1. Since then, investing online has been manifesting continuous growth. Investors can already enter orders for direct buying and selling securities online, with these orders passing through brokers and allowing them to monitor or approve the transactions. Thus the client and the brokerage company are protected against illegal or incorrectly executed transactions, which could unfavorably impact the client’s portfolio or the broker’s license. When using the intermediacy of an online broker clients use its e-trading platform. One of the most important characteristics of the intermediacy of online brokers is the huge reduction of expenses that clients pay for brokers’ services – their commissions fall dozens of times compared to those of traditional brokers. Functions of online brokerage2 comprise providing information about security prices and the financial state of the companies, whose securities are being traded; management of trading accounts; providing tools for real-time tracking and monitoring of security quotations and indexes for the purposes of portfolio management; providing the latest news, in-depth analyses and reports; execution of orders for security buying and selling; settlement of securities at the stock exchange and other. For its services the online broker earns a commission or a fee that is considerably lower than that of traditional brokers. Online trading in various types of securities (shares, bonds, options, mutual funds, etc.) and currencies is offered to investors on the Internet by two basic types of broker3: traditional brokers (classical and discount ones) and banks, in the past
offering intermediacy only offline, through their branch network and at present marked as brick and click brokers. Examples of such brokers include Merrill Lynch4, Charles Schwab, Ferri, Dubus, Financière Warny, BNP-Paribas, Bred and other, including derivatives of traditional investment companies (Fidelity).
1
Source: https://www.tdameritrade.com/about-us.page (18.04.2013) The English term for the provision of electronic brokerage services is online- or e-brokerage and e-broking. 3 Sahut, Jean-Michel, “On-line Brokerage in Europe: Actors & Strategies.”, JIBC, June 2003, vol. 8, no. 1. 4 Since 2008 is a subsidiary of Bank of America. 2
16
New electronic brokers, also known as online or e-brokers, that emerged especially for the purpose, and exist online, as well as some of the direct Internet banks, offering investment services. Representatives of this type of broker are the US E*TRADE, Scottrade, TD Ameritrade; Cortal Consors (Germany); Avanza (Sweden); the Dutch online bank BinckBank N.V. and other. The place of electronic brokers from the viewpoint of the above mentioned traditional categorization of brokerage companies is predominantly in the discount brokers segment. Consumers’ participation in online trading definitely depends on their possession of certain financial knowledge in view of the need for making investment decisions. Unlike Internet banking, which does not pose any requirement whatsoever for the client using interactive banking services, participation in stock exchange trade is based on the respective financial literacy necessary to do that. To a certain extent this fact is an obstacle for growing penetration of online investing among consumers. Depending on their behavior in stock trading and their attitude to the use of Internet in stock trading, consumers are divided into three groups according to a publication of JP Morgan5: participating on their own (self directed), who manage their finances themselves and are focused on application of the global network; partially participating, who seek the advice of consultants on certain issues, delegate some decisions to consultants and do not fully use Internet solutions, and those fully delegating their financial affairs to professional advisors and consultants, with no particular attitude towards the opportunities of online trading. 1.2. Advantages of online brokerage Online brokerage brings participants – both clients and brokers, the advantages mainly associated with prices and the conveniences provided. There is considerable cost-cutting for every transaction performed. While in the past small investors gained access to trading in the capital markets mainly through the intermediacy of large investment banks for considerable commission, owing to online broking, they now have a substantially cheaper access: comparisons show that costs per transaction per consumer in conventional intermediacy, for example that of Merrill Lynch as a broker, 5
J.P. Morgan Securities Ltd. “Online Finance Europe.”, 2000, p. 26. 17
amount to around $373 and only $8 when using the services of the online broker Ameritrade6, while online brokerage services of Consorsbank, owned by BNP Pariba, charge a commission for new clients of €4.95 per transaction for volumes above €10 0007. Costs per unit of transaction performed on the Internet are 25 times as low as those for an over- the- counter transaction in an office8. These days trading demands less participation on the part of employees who service it; marginal costs for closing additional transactions are low; the new electronic brokers entering the market results in increased competition with traditional brokerage firms, which leads to greater effectiveness of their activity. Another advantage of online trading is improving the speed of the transaction closing and settlement, as there is no need for paper-based documents to be digitized, processed and archived. Electronic brokering facilitates the wider scope of development of the so called “day trading”, a specialized type of investing, where investors make a profit by buying or selling securities or currency pairs, that is, they open and close short-term market positions – mostly within a day (a session). This trading is usually speculative in character and is typical mainly for US capital markets. According to an analysis of the ECB's made in 2001, the day trading is not a significant phenomenon in Europe as it is in the US, where in the middle of 2001 there were 10 000 active investors of this type9. 1.3. Development and state of e-brokering In the evolution of e-brokering we observe an extensive period of development during the mid-1990s (1996-2000), which reaches a peak in 1999-2000. Throughout this period masses of clients turned to using online brokerage services. Consequently, traditional brokers and banks successfully joined the online market in basically two ways – by creating their own e-business model or by merging with an existing electronic broker10. Owing to the global network this period reports a boom in the Coorey, M., “Internet broking: Europe's turn to get wired.” Global Finance, Nov.1999. https://www.consorsbank.de/ev/Wertpapierhandel/Depot-Software/Trader-Konto (22.03.2015) 8 Sahut, Jean-Michel, “On-line Brokerage in Europe: Actors & Strategies.”, JIBC, June 2003, vol. 8, no. 1. 9 European Central Bank, The Euro Equity Markets, Aug 2001, p. 43. 10 Sahut, Jean-Michel, “On-line Brokerage in Europe: Actors & Strategies.” Journal of Internet Banking and Commerce, June 2003, vol. 8, no. 1. 18 6
7
number of new players on the market for intermediaries – in the USA, companies offering brokerage services grew to over 100 from 35 in 1997.11 Despite the initial resistance, nearly every major investment intermediary offers consumers online trading from the home or office. According to JP Morgan’s estimates within 4 years (1997-2000 ) the number of clients using electronic brokering services in the Eurozone rose ten times to reach 3m people12. A suitable indicator for assessing the development of online trading is also the number of security trading accounts opened. In the middle of 2001, in Germany there were 2 141 000 online accounts or about 50% of all trading accounts in Europe, and, according to statistics, the German market holds the leading position in this field, followed by the Swedish one with 11% market share 13. In the same year 13.2 m. Americans bought or sold securities online, and 43% of American households that have trading accounts, trade online14. A survey on the use of Internet for researching capital market and buying shares was carried out in 2006 by the leading German bank Deutsche Bank among consumers from 7 European countries15. Data shows that the Swedish manifest the strongest interest in getting information online about stock market quotations and financial news about companies (slightly less than 10% of consumers), then the Dutch and the Germans (about 6%), followed by the British (about 3.8%) and the French. Again Swedish consumers (by about 4%) are the respective leaders regarding purchase of shares, followed by the Germans with less than 2%. Potential users of the online distribution channel are the owners of stocks, whose average share for the 7 countries researched is slightly over 20% of the population according to data from 2006. This share varies for particular countries, with Swedish and British investors scoring the highest: 35% and 30% respectively, and the shares of stockholders from Germany, Italy and Spain is below the average. In 11
Coorey, Madeleine, Internet broking: Europe's turn to get wired, Global Finance, Nov. 1999 European Central Bank, The Euro Equity Markets, Aug. 2001, p. 43. 13 Sahut, J., “On-line Brokerage in Europe: Actors & Strategies.” Journal of Internet Banking and Commerce, June 2003, vol. 8, no. 1. 14 eMarketer, “Online Investing: Brokers, Investors, Statistics, and Market Trends“ 15 Meyer, Th., “The worst is over for online brokerage.” Deutsche Bank Research, E-Banking Snapshot 17, 2006. 19 12
comparison: according to J.P. Morgan’s data, at the end of 1998 only 12% of the adult population of Europe owned stocks, that is, the trend is for a growth of investors in securities, and consequently, the consumers of online trading. The main motives for participation in online trading include convenience, speed of getting information and closing transactions, lower fees. Research shows that the probability of users participating in online trading grows along with the number of other financial products sold online, including use of Internet banking. According to a survey from 2007 among the clients of the leading British brokerage company for retail investors Barclays Stockbrokers16 62% of them bought securities online, with 44% of them regularly investing this way. In order to overcome one of the substantial obstacles before online investing – the consumers difficulty in making investment decisions, Barclays Stockbrokers developed the so called “Investment Selector”17. This is a web-based software module that helps investors choose those investments that best match the level of risk they are ready to take. More recent data from the research company Aite Group illustrate Americans’ investment activity towards the end of 2010. They show that 19% of the value of all retail investments are managed with the help of online brokerage firms, with this share being 12% higher than the pre-crisis levels of the years before 2007-2008. Actual data on the users’ perception of online trading and the number of online investors is presented in a study (BMO InvestorLine Study)18 performed by one of Canada’s leading bank groups, Bank of Montreal, published in May 2013, point that at the moment 20% of Canadians invest online and this percentage is expected to reach 65% over the next five years, reaching 80% for the clients aged 18 – 34 in 2018. The development of e-brokering is directly dependent on the development of the capital markets themselves, one of whose distinguishing characteristics is volatility and instability. The decline in the investment activity of the population has a negative impact on the number of consumers using e-brokering services. The above dependency 16
Barclays Stockbrokers is a subsidiary of Barclays Wealth and currently manages securities for £1 billion. In his order at the beginning of 2007 was made a survey of its customers by the company YouGov. Source: http://www.24-7pressrelease.com/pdf/2007/04/13/press_release_26929.pdf (18.02.2015) 17
https://www.stockbrokers.barclays.co.uk/AccountOpening/InvestmentSelector.aspx?category=registration&usec ase=IST&host=Barclays&&QS= 18 http://forexmagnates.com/signs-of-prosperity-for-online-investing-in-canada/ (23.01.2015) 20
is supported by the consequences of the capital markets crisis from the end of 2001 till the beginning of 2003, when the demand for online brokerage also fell. A major segment of online trading is trade in foreign currencies, or the so called currency pairs. This fact corresponds with the principle that the currency market – FOREX (foreign exchange or FX) is the biggest financial market. The daily volume of world currency trade varies between 4-5 trillion dollars on average (in April 2013 this volume reached the maximum value of 5.3 trillion USD19). Retail trade at the FX market accounts for about 4% of the total turnover, with the highest volumes in absolute value realized in the USA and Japan20. Electronic trade dominates the FX market – statistics show that over 50% of individual investors trade through an online channel.
Literature 1.
Banks, E. „e-Finance: The Electronic Revolution”, John Wiley and Sons
Ltd, 2001. 2.
Varbanov, R., S. Parusheva, et al. „Information Technologies in
Business”, Faber, V. Tarnovo, 2009.
Internet sources 1.
Barclays Stockbrokers
2.
Bulgarian stock exchange,
3.
Coorey, M. “Internet broking: Europe's turn to get wired.” Global
Finance, Nov.1999 4.
Consors bank
5.
eMarketer “Online Investing: Brokers, Investors, Statistics, and Market
Trends.” Rime, D., Schrimpf, A. „The anatomy of the global FX market through the lens of the 2013 Triennial Survey“, BIS Quarterly Review, December 2013, p. 1. 20 Again there, p. 39. 21 19
European Central Bank, “The Euro Equity Markets.” Aug. 2001.
6.
7.
Hakman,
W.,
Electronic
Financial
Services:
Technology
and
Management. Oxford, Chandos Publishing Ltd, 2006. J.P. Morgan Securities Ltd. “Online Finance Europe.”, 2 June 2000.
8.
Meyer, Th. “The worst is over for online brokerage.” Deutsche Bank
9. Research,
E-Banking
Snapshot
17,
May
2006.
10. Open Doors: Foreign Participation in Financial Systems in Developing Countries. Edited by Robert E. Litan, Paul Masson, and Michael Pomerleano, Washington: Brookings Institution Press, 2001. 11. Sahut, Jean-Michel “On-line Brokerage in Europe: Actors & Strategies.” Journal of Internet Banking and Commerce, June 2003, vol. 8, no. 1. (02.06.2013) 12. Swiss Re “The impact of e-business on the insurance industry: Pressure to
adapt
–
chance
to
reinvent.”
Sigma
No.
5/2000.
http://www.swissre.com/pws/research%20publications/sigma%20ins.%20research/ebusiness%20in%20the%20insurance%20industry.html 13. TD Ameritrade
Self-study questions 1. What does the concept of online trading mean? 2. How are the traditional brokers with physical branch network categorized? 3. What are the functions of online brokerage? 4. What are the main types of brokers offering online trading in securities and currencies? 22
5. How can the users be distinguished according to their behavior in stock trading and also their attitude towards online trading? 6. What are the main advantages that online brokerage provides for users? 7. Name key stages in the development of e-brokerage in the world and also name the leading countries with most users in Europe. 8. What are the correlation levels between the development of capital markets and e-brokerage?
23
Chapter 2. ELECTRONIC BANKING The financial sphere and banking, in particular, is one of the areas where the use of modern information technologies has been traditionally strong ever since their intensive development started. Owing to the use of bank information technologies the quantitative and qualitative expansion of the market for products and services is now possible, as well as increasing competition between banks, gaining a larger market share, not least by using various distribution channels. Traditional serving the client over the counter in the branch network of banks (“bricks and mortar” branches) is complemented both by physically existing channels (Point-of-Sale /POS/ terminals, Automated Teller Machines (ATMs), multifunctional devices /kiosks/), and by new electronic channels, whose variety is comprised in the general term electronic banking or e-banking. The need for applying new information technologies in banking results from the following reasons: the constant growth of the number of banking operations suggests the use of new instruments and methods for information processing; growing requirements regarding the quality, accuracy, reliability and security of collecting and processing information; increased competition between banks causes a fight for attracting clients, which in turn drives the constant improvement of the quality of bank services; growing requirements on the part of consumers for gaining remote access to bank products and services in a way that is convenient for them, without limitations relating to time or place, i.e. in a 24x7 mode. Apart fro serving clients over the counter, based on operations of the main banking system, over the last few years banks have been exceptionally active in offering services through systems and instruments for remote bank servicing known as remote or direct banking, which includes providing electronic bank services through various distribution channels. 2.1. The essence of electronic banking Electronic banking is a general term for the process, whereby consumers use 24
bank services electronically, without visiting bank offices. E-banking is defined as an automated delivery of traditional and new bank products and services directly to the clients through electronic and interactive communication channels21. It includes systems which allow the clients of financial institutions, individuals or companies access to various kinds of financial transactions or getting information about financial products and services over public or private networks, including the Internet. Electronic delivery channels are able to transmit and distribute information in a digital format. After information on banking transactions is distributed digitally, it can be rapidly and easily stored, analyzed and used by other systems. Consumers have access to e-banking services by means of intelligent electronic devices, such as a personal computer (PC), Personal Digital Assistant (PDA), tablet, an automated teller machine (ATM), a multifunctional device (kiosk), mobile or fixedphone with tone dialing and other. From the point of view of the costs related to its offering, electronic banking is relatively inexpensive; therefore the barriers for its marketing are low. As a result, offering e-banking is not limited to large and well- established banks. In view of the huge competition, e- banking is turning into a staple service, which clients necessarily expect to receive from financial institutions. Electronic distribution channels can be used for providing three types of service: information, transactional and for performing sales. This differentiation prevails in literature, including that of European Central Bank (ECB)22. According to it, information services, also called passive operations include checking the account balance and account turnover for various kinds of accounts, including deposits made for the purpose of trade in securities; printing out account statements; getting information on exchange rates, interest rates, fund indexes, etc. Transactional services include money transfers, paying bills and other. Sales include purchase of/ or applying for the purchase of financial products, for example savings deposits, personal loans and mortgages, bank cards, securities and other, that is, more complex and complicated products and services.
21 22
Joshi, V. „E-finance: the future is here“, 2nd ed., New Delhi: SAGE Publications India Pvt Ltd., 2010, p. 37. European Central Bank, “EU Banking Structures.”, p. 42. 25
Other authors (V. Joshi) classify e-banking services in two groups - Basic and additional (Premium) products23. The first group covers: check on account balance; money transfers; paying utilities bills. The second one includes all basic products plus opening a new account; cash management; confidential services; bills presentment; insurance. Out of the two classifications it is the first one that is much more established in both the theory of banking and e-finances and in practice, hence it is this classification that we shall adhere to in the following presentation. Initially the term electronic banking was mostly applied in the context of automation of transactional services, but since then it has been used for buying and selling financial products and instruments. 2.2. Types of electronic banking Electronic distribution channels, through which electronic banking is implemented, comprise: fixed telephone; the Internet; mobile communication channel with use of mobile devices, incl. mobile phone, smart phone, tablets, PDA devices, etc; fax, interactive digital television (iTV). Depending on channel, the following five types of e-banking can be differentiated: telephone banking; PC banking; Internet banking; mobile banking; TV banking. A certain chronology can be observed in the development of the types of electronic banking – initially it was telephone banking that won recognition, later on PC, Internet and in the end – the new forms: TV and mobile banking. 2.2.1. Telephone banking As the oldest form of remote banking, telephone banking has been offered by western banks since the late 1970s. It is the first major electronic distribution channel. It suggests telephone contact between the client and the bank and access is provided for:
Joshi, V. „E-finance: the future is here“, 2nd ed., New Delhi: SAGE Publications India Pvt Ltd., 2010, p. 4647. 26
23
information and inquiry services – the client gets information on balance and account movement, interest rates, exchange rates, etc either by voice messages or automatically by fax or e-mail. transactional services – it is possible to perform money transfers, transfers of funds, pay utility bills, currency exchange and other. Telephone banking is implemented in two variants: through communication with a bank official, most often via Call center; Depending on the coverage of service and equipment, the client can get in contact with an official or a bank assistant, respectively. Two types of calls are distinguished - Inbound Calls (the client phones the Call center) and Outbound Calls (Call center phones the client, for example, at a time that has been agreed on in advance)24. through Interactive Voice Response (IVR). In this case the client’s access to the bank information system is realized without an intermediary, but with the telephone keypad instead, and a voice menu, whereby there is no requirement concerning the type of telephone line – digital or analog, fixed or mobile. When fixed analog connection is used, the set must allow for tone dialing. Some systems for telephone banking allow the clients to switch from one variant to the other, depending on the service that is requested. Protection from unauthorized access is performed by means of a personal identification code and a password. Consumers’ access to telephone banking is usually graded depending on whether they need general bank information (i.e. access to it is free – information on exchange rates and interest rates on current accounts and a variety of deposits) or they wish personalized information (i.e. access is limited by the requirement for entering client number and a password) such as information about balance and accounts movement. The client may obtain the resulting information by choice – over the telephone or by e-mail/fax. Telephone banking is available at nearly all large banks in the EU, including those in Bulgaria.
24
Locarek-Junge, Banken im Wandel - Direktbanken und Direct Banking. Berlin, Berlin Verl. A. Spitz, 2000, pp. 90-91. 27
2.2.2. PC banking PC banking, also known as online computer banking or “home banking”, is a form of electronic banking prior to Internet banking. Applications for PC banking have a server side and a client side. Their interaction is based on a telephone line and a modem or, less often, through a hired line. It is necessary for the bank to install and support the client’s side, that is, special banking software on the client’s computer. Through this computer the client has access to nearly all bank services, both inquiry and transactional ones. It allows the clients of the bank, predominantly corporate clients, to manage their company finances quickly and conveniently from their office, day and night. Some PC banking applications support facilities for export (import) of data from clients’ accounting programs. This entails more costs for the clients compared to the Internet, as banks typically charge fees for installing and support of the specialized banking software. The client’s side of the system for PC banking can work in an online or offline mode. In the latter, changes in the client’s accounts are recorded in the bank’s database not in real time, but during session connection with the bank. The latest variants of PC banking systems, such as the system MultiCash of the German firm Omikron GmbH, are based on thin-client model, that is optimized software components (plug-in, Java applets) communicate with the bank system through a standard browser at a guaranteed level of security25. A plug-in is integrated in the browser, which is activated automatically and exercises control in the defined field on the page where the client enters information. All the dialogs between the bank and the client are managed by a separate Secure-Bank-Server in the bank’s system. From the point of view of the client, the system Browser, Plug-In and Secure-BankServer represent a whole. Security of PC banking is guaranteed by the use of electronic digital certificates and cryptographic methods for encryption of information.
Ursheva, J. “E-banking is becoming part of everyday life of the Bulgarians”, Computerworld, Sofia, N: 3, 2004. 28 25
2.2.3. Internet banking Internet banking refers to the provision of bank products and services through electronic channels for delivery on the basis of computer networks and Internet technologies, including landlines, cell and wireless networks, web based applications and mobile devices26. The basic requirement is for clients to have a web browser, with which, after being registered for the service, they log on the bank’s site and gain access to bank products and services. The software implementation of the system for electronic banking has two sides – bank side and client side. Bank side carries out users registration, authorization, organizing access to clients’ accounts and processing queries, transmission of information to the client over the Internet, and ensuring security. Client side realizes logging in the Internet, transmission of information about authorization (registration number, client password), forming a query, interpretation of data received from the bank’s system. Different banks have different technical, technological and financial capacity for real exploitation of potential Internet solutions. Different types of Internet banking can be differentiated and these are presented in the next chapter “Internet banking – a key element of financial Internet-based services”. Basic business models for offering Internet banking There are two basic business models through which Internet banking is provided. In the first one traditional banks combine offering bank products and services in brick and mortar branch network and offices and their offering on the Internet. In this way they realize the so called multichannel distribution strategy, hence their designation as multichannel banks (Fig. 1.1.).
Monetary Authority of Singapore, „Internet Banking nd Technology Risk Management Guidelines“, June 2008, p. 2. 29 26
Customer
Channel
Connection type
Mail Phone
Fax E-mail
Distance personal contact
Branch Agents
ATM Phone Web IP TV
Direct personal contact
Self-service
Fig. 1.1. Customer service through different channels with different connection type
The other business model is connected to Internet banks or virtual banks. Possibilities within this business model vary from: (1) Pure Internet banks/Internet-only banks – independent banks, individually licensed by bank regulators. Typically they don’t have branch network, but offer their services only, or mainly, through electronic delivery channels. Withdrawal and depositing of funds in these banks is carried out either through their own or hired from other banks ATMs or kiosks27/). In the years of the dot.com boom (1998-2001) this model considerably expanded its market presence, but later a large number of these banks went out of business. Examples of such banks are: American First Internet Bank of Indiana, Bank of Internet USA and NetBank; Japanese Japan Net Bank and SBI Sumishin Net Bank; Egg Banking (a former British Internet bank, at present owned by Yorkshire Building Society); Skandiabanken (Sweden) and other. (2) Traditional bank creating its own Internet brand and a dedicated website, leading to the impression that there is a separate entity behind the brand28. Examples for that are: the British “bank” First Direct, a division of HSBC Group, and not a separate legal entity; Smile, a division of the UK-based Co-operative Bank; the Polish mBank, a division of BRE Bank and other. (3) The Internet bank being declared a subsidiary or a branch, including a foreign one, of the conventional bank. An example for such a bank is Openbank, a division of Banco Santander in Spain; RaboDirect, part of Rabobank and other. 27
Kiosk is typically multifunctional and allow customers to serve themselves and perform more complex and long transactions, compared to the services available at the ATM. 28 European Central Bank, “EU Banking Structures”, Oct. 2007, p. 44. 30
Over the last few years most countries adopt the first business model of combined offering traditional and electronic delivery channels which is known in literature as ”brick and click banks”29. Multichannel strategy remains the preferred distribution model for most European banks. Use of Internet banking is expanding its scope with the number of users constantly growing. Data published by the official statistical institution of the European Union - Eurostat for the period 2003-2014 show that by the end of 2014 the percentage of Internet banking used in EU 27 averages 44% (Table 2.1.) and over a period of 10years, use has grown by 175%30. In individual countries this share varies widely – from 5% in Bulgaria and 4% in Romania to 89% in Norway, 86% in Finland (from 43% in 2003), 84% in the Netherlands, 83% in Denmark, 82% in Sweden (from 38% for both countries in 2003), 77% in Estonia, etc. Based on these figures, we can make the conclusion that the proportion of population who use web banking is rapidly growing. This trend is the strongest in Scandinavian countries and the Netherlands, There is a marked correlation between households’ access to and use of the global network and using Internet banking, as according to Eurostat data, it is exactly in these countries that Internet penetration has the largest share (according to data for 2014 households‘ access to the Internet is as follows: in the Netherlands – 95%, Finland – 89%, Norway – 88%, Sweden - 87%31. There is a wide variety of reasons for the positive development of the use of Internet banking. The basic ones are, on the one hand, associated with the maximum convenience for the consumers and the affordable service, and on the other – with the preferential interest rates and service fees.
Schaechter, A. “Issues in Electronic Banking: An Overview” IMF Policy Discussion Paper, 2002, p. 4. Data refer to persons aged between 16 and 74 who used the Internet banking at least once in the last 3 months. 31 Eurostat, http://ec.europa.eu/eurostat/tgm/table.do?tab=table&init=1&language=en&pcode=tin00073&plugin=1 (15.03.2015) 31 29
30
Table 2.1. Individuals using the Internet for Internet banking (percent of individuals aged 16 to 74) (Source: Eurostat) Country\Year 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 Iceland Norway Finland Netherlands Denmark Sweden Estonia Luxembourg Belgium France United Kingdom Latvia Germany Austria Lithuania Ireland Euro area Malta EU (27 countries)
48 49 43 : 38 38 : 23 : : 22 : 21 13 3 8 : :
54 55 50 : 45 40 35 35 : : 22 12 26 18 7 10 : :
61 62 56 50 49 51 45 37 23 : 27 16 : 22 10 13 20 16
67 67 63 59 57 57 48 41 28 18 28 22 32 27 15 21 22 16
72 71 66 65 57 57 53 46 35 34 32 28 35 30 21 25 28 22
68 75 72 69 61 65 55 48 39 40 38 39 38 34 27 28 31 25
72 77 72 73 66 71 62 54 46 43 45 42 41 35 32 30 34 32
77 83 76 77 71 75 65 56 51 50 45 47 43 38 37 34 37 38
80 85 79 79 75 78 68 59 54 51 : 53 45 44 41 33 39 42
86 86 82 80 79 79 68 63 56 54 52 47 45 45 44 43 41 41
87 87 84 82 82 82 72 63 58 58 54 55 46 47 49 46 43 43
91 89 86 84 83 82 77 67 61 58 57 57 54 49 48 48 45 45
:
16
19
21
25
29
33
36
37
40
42
44
...
...
...
...
...
...
...
...
...
...
...
...
...
1
1
1
2
4
5
5
6
9
9
11
13
:
1
:
1
2
2
2
2
3
4
5
5
:
0
:
1
2
2
2
3
4
3
4
4
Greece Bulgaria я
The first advantage means that via the Internet banks offer a service which consumers use in their home or office 24 hours a day and, in addition, without any special software. The second advantage is achieved owing to the fact that web services operational maintenance costs are several times lower, as they do not require numerous staff members, costly offices and equipment. All that allows banks, via the Internet distribution channel, to realize services with competitive advantages that are out of reach for classic banking. Quite logically, the Internet has become the bank channel characterized by the highest degree of customer satisfaction (57% “very 32
satisfied” against 35% for bank branches and 29% for telephone banking)32, according to results from the survey of European Financial Management & Marketing Association (EFMA) and partners, published in 2004. The high degree of satisfaction is associated in particular with ease of access (69% ‘very satisfied” against only 9% for the bank branch) As regards the offering of Internet banking it can be summarized that nearly all banks offer Internet banking, at least as a channel for information and transactional services. Worldwide, providing online banking services to consumers is rapidly increasing. Banks’ costs per standard transaction via the Internet are considerably lower than those of brick branches, so banks have a long-term stimulus to develop this channel in future. This fact is substantial grounds for the banks to conduct an active marketing policy of directing clients to using the online channel. Banks provide various incentives for the users, such as the same products and services as those offered in branches, but at lower fees and commissions, or at better interest rates, including some online bonus; offering certain products only via Internet banking and not in their branch network and other. Compared to branches, for the time being the Internet is of limited importance as a sales channel. Over the last few years a growing number of banks offer their clients the opportunity to buy products like: saving accounts, personal loans, bank cards, mortgages and other, but their sales are still minor, particularly in the new EU member states. Scandinavian countries and the Netherlands are an exception, as there the Internet has solid positions as a substantial sales channel. Banks make considerable efforts to firmly establish Internet banking as a sales channel and to this end they undertake various activities like: developing special Internet offers; services with fewer fees; improving the systems for online banking, incl. paying special attention to their security and safety; better integration with the other distribution channels.
32
The survey was conducted among 1016 European users of Internet banking services and results were published in a study entitled “Internet banking, a new wave?”. 33
Types of Internet banking systems Three types of systems for Internet banking can be differentiated depending on the interaction and communication with consumers33: In the information type only one-way communication is available and the
bank uses the Internet for the sole purpose of advertising and presenting its products and services, that is, the website performs the role of a marketing tool. Such a website may allow the bank to collect visitor data in order to better specify its marketing and placement efforts. Typically the bank supports marketing information about its products and services on a dedicated server. This level of Internet banking can be provided by the bank itself or by an outside contractor through outsourcing. With respect to the risk involved, this can be defined as relatively low, as information systems usually are not based on the connection between the server and the bank’s internal network. Communication type systems for Internet banking allow two-way
communication between the client and the bank’s systems. Interaction can include electronic mail, inquiries about an account, downloading documents from the site and sending files and other. Internet banking servers can be communication-linked to the bank’s internal networks, therefore the respective risk is higher than with the previous type of banking. For this reason, suitable controls are necessary for preventing, monitoring and managing signals concerning attempts at unauthorized access to internal bank networks and computer systems. Corresponding controls and malware applications are necessary. Transactional type systems are the most complex ones; with them after
the client has been identified, it is possible to connect him/her to the operational systems of the bank and perform financial transaction in real time mode. There is usually communication between the server for Internet banking and the bank’s internal system, or in case of outsourcing – with the network of the outside contractor and consequently, the corresponding risk with this type of banking is the highest and the most powerful controls should be envisaged.
Comptroller of the Currency Administrator of National Banks „Internet Banking. Comptroller’s Handbook“, October 1999, p. 4. 34
33
Because of the fact that the technology for delivery of banking services via transactional type Internet banking is inexpensive and reliable, at present most banking systems, including those in Bulgaria, belong to these type of systems. There are other classifications of the systems for Internet banking suggested by certain authors and institutions which are not substantially different from the one discussed above. The central bank of India - Reserve Bank of India (RBI) for example, divides the systems into 3 types34: Information providing system – this type of system offers on the bank’s
website only general-purpose information, for example interest rates, branch location, bank products and their characteristics, loan and deposit calculators and other. There are possibilities for downloading various application forms (for example, for bank cards, loans, etc.), and communication is usually carried out by electronic mail. There is no interaction between the client and the internal systems of the bank. Client is not identified and it is impossible for an unauthorized person to gain access, via the Internet, to the bank’s internal systems. Information exchanging system – this system provides client-specific
information – balances and account statements, transactional data, etc. Information is in a “read only” mode and is retrieved by applied banking systems in batch mode or offline. Client’s identification and authentication is carried out by means of a user name and password. Applied systems cannot be directly accessed via the Internet. Transactional system – this system allows two-way interaction with
users, i.e. they can initiate online transactions, and perform routine operations. The server of the Internet banking systems is linked via secure infrastructure with the bank’s applied systems. Technology and organization of the Internet banking systems It is possible for Internet banking systems to differ considerably in their scope depending on a number of factors. Financial institutions choose the scope of an Internet banking system, including their relationships with other firms regarding
34
Vinayagamoorthy, A., K. Senthilkumar „Role of reach of Internet Banking in India“, p. 5. 35
outsourcing of activities and services, by taking into consideration four factors35: Strategic objectives of Internet banking; Scope, scale and complexity of equipment, systems and activities; Technological expertise; Security and internal control requirements.
Organization and support of Internet banking systems Banks have two basic options for supporting their Internet banking services. The first option is to support services internally, with their own capacity and efforts. The other option is to outsource certain aspects of their Internet banking systems to third parties – outside contractors. Banks can use the services of the following organizations, which provide or host (i.e. allow applications to reside on their servers) various activities36: Another financial institution; Internet service provider (ISP); Internet banking software vendor or processor; Core banking system vendor or processor; Security system provider; Utility bill payment provider; Credit bureau37; Credit scoring company.
Components and processes in Internet banking systems Internet banking systems include a number of common components and processes. The typical list may include: Web design and hosting; Firewalls configuration and management; Intrusion detection system (IDS) (network and host-based), tracking network or 35
FFIEC, IT Examination Handbook InfoBase, http://ithandbook.ffiec.gov/it-booklets/e-banking/introduction/ebanking-components.aspx (20.01.2015) 36 Same source (20.01.2015) 37 Credit bureaus collect and provide information on users’ loans and debts and exchange data between banking and non-banking institutions. 36
systems activities for malicious activities or intrusion; Network administration; Security management; Internet banking server; Certain relatively independent applications, for example bill paying; loans; -
brokering and other; Internal network servers; Core processing system; Automated decision support systems and other.
These components work together to deliver e-banking services.
Advantages of Internet banking The various direct distribution channels for bank products and services, and particularly the Internet, provide a number of advantages for both its users and the bank institutions. For this reason advantages should be considered from the view point of the two parties that participate in the process: 1. From the banks view point the advantages provided by Internet banking can be summarized in the following directions:
Access to a wider client audience;
Cost-saving on expansion of the branch network and equipment of costly
offices; Cost-cutting on marketing, advertising and placement of bank products; Reduced time for new products and services to reach the bank’s clients; Possibility for the bank to free customer service employees from
performing routine operations clients can now perform on their own. These specialists could be directed to providing clients with high quality and comprehensive services, which are increasingly required by more sophisticated bank products like granting various loans – personal or mortgage; issuing credit cards, and other. 2. From the point of view of the consumers the advantages provided by Internet banking can be systematized in the following directions: There is a possibility for a much wider choice of bank (access to a wider 37
range of banks, including foreign ones) – nearly all banks are virtually presented through their own website; There are no geographical limitations – Internet banking allows extended
access to clients by expanding geographical reach and lowering costs of distribution channels. In fact certain banks do business exclusively via the Internet – they do not have the traditional bank offices and reach their clients only online. Other financial institutions use the Internet as an alternative delivery channel in order to reach existing clients and attract new ones. There are no time limitations for the consumers’ access to bank products
and services – with Internet banking they are able to initiate bank transactions 7 days a week and 24 hours a day (7/24);
Timesaving and convenient access to banking services;
Access to Internet banking is usually free for individual users and banks
often offer products and services at more advantageous prices – with lower fees and commission than those over the counter in the bank branch. Corporate clients are typically charged inexpensive fees for Internet banking. Internet banking places banks in a highly competitive environment,
which brings about lowering the prices of the bank products and services provided, while their quality and variety are improving. One of the basic advantages of the remote distribution of bank products and services, predominantly via the Internet, consists in the lower costs involved in their realization. A number of valuations of these costs have been made by various authors, companies and analysts, who have published them in 1their research. Table 2.2 presents some of them. A standard bank transaction could be, for example, interbank money transfer. Data in the table show that according to the various research and sources banks costs for such a transaction via the Internet are from 23 to 70 and even 100 times as low as those involved in conducting the transaction in a traditional bank branch. According to a survey of Bainbridge at al., cited in the same source (Heffernan), transactional costs via the Internet, including those for the IT systems necessary, amount to 10% of the costs incurred by the traditional bank branch. 38
Table 2.2. Costs for frequent banking transaction according to various sources
Distribution channel Bank Teller Phone (IVR41)
Sources Booz, Allen and Hamilton38 $1.07
Wood39 $1.00
$0.54
Fiserv40 $4.00 $1.25
Contact center
$3.80
ATM
$0.27
Internet
$0.015
$0.90 $0.01
$0.17
According to valuations made by Fiserv company, the biggest information service provider for the financial sphere worldwide, it is exceptionally effective for banks to reorientate their customers to conducting transactions through the online channel - the following calculations prove that: a financial institution performing 1000 operations a day in a traditional branch spends $1 m a year on processing these transactions. By encouraging clients to conduct only 30% of their transactions online, the bank will cut nearly $290 000 in processing costs every year. Internet banking also has certain disadvantages, such as, for example, security issues, growing costs for ensuring/safeguarding a higher degree of protection for Internet banking systems, limited possibilities for Cross-Selling.(Cross-Selling is a notion referring to the complex (package) offering, on the part of banks, bank products for fuller satisfaction of customer needs). It should be pointed out that with Internet banking, as well as the other electronic channels, there is no personal contact with a bank official, and such a contact is indispensable for complicated bank services. Relying on the new technological solutions, banks make serious IT investments
Heffernan, Sh. „Modern Banking“. John Wiley & Sons Ltd, Chichester, 2005, p. 92. Heffernan, Sh. „Modern Banking“. John Wiley & Sons Ltd, Chichester, 2005, p. 92. 40 http://premier.fiserv.com/redesignyouronline/roi.html (20.02.2014) 41 IVR (Interactive Voice Response) System 38
39
39
in order to enhance Internet banking applications and expand their functions, including by adding facilities to compensate the lack of physical contact between the client and a bank official. Some banking solutions already provide interactive advice, chat function on the bank website or conversations with a personal consultant by means of a webcam (video channel). 2.2.5. Mobile banking Mobile banking (m-banking) is defined as a channel where clients interact with their bank via a mobile device (mobile phone, smart phone, PDA42), tablets and other smart portable devices which usually come with Internet access. It is defined as a subcategory or an improvement on Internet banking. Mobile banking solutions are based on 3 approaches which comprise:
Access to the bank website via mobile device web browser – essentially
there is no difference in online banking with a browser via a mobile device (tablet, smart phone, etc.) or a desktop PC;
Using dedicated banking software, that has to be installed on the mobile
device – the so called Mobile Banking Applications (Mobile Banking Apps) or Smart client solutions, which are essentially software solutions, enabling bank clients to prepare their transactions offline, and then only the data transfer is online. Clients find it more convenient to do their banking via such a suitable application installed on the device. Many banks already provide mobile banking applications to their clients for free; Text messages (SMS-banking). At the moment m-banking is mainly used for informational services and sometimes for transactional services, but rarely as a sales channel. Message based services are also considered as m-banking. In this case a client may get SMS or MMS with bank information, for example, about the balance on his/her account, the last few transactions, overdraft on the account, etc. Mobile banking was introduced by a number of banks in the US and Europe in the late 1990s. Initially it was based on Wireless Application Protocol (WAP) and its 42
Personal Digital Assistant - portable computer, usually without keyboard, which is used for various purposes. PDA is also known as pocket computer or palmtop computer. 40
use required that clients’ cell phones should have WAP-browser. This stage was characterized by a number of technical imperfections with respect to mobile networks and devices: data transfer limitations because of insufficient speed of 2. and 2.5 generation networks (GSM, GPRS, EDGE43) and the costly communication, small screen mobile phones interface not convenient enough, lack of QWERTY keyboard, difficulty in visualizing and entering long text, etc. They prevent the quick and efficient remote service of clients. Many banks are abandoning this service, as mbanking failed to earn a recognition as a successful distribution channel. After a standstill of about 5 years, banks are again turning their attention to mobile banking. The reasons for that can be grouped in several aspects. Mobile communications develop rapidly; 3. and 3.5 generation (3G and 3.5G) networks like UMTS, HSDPA, HSUPA44 and other are entering mobile communications and they have much higher speed and expanded capacity of data transfer; they allow access to broadband Internet; they reduce mobile services price; mobile devices (incl. smartphones, PDA) are getting considerably more sophisticated and intelligent and support protocols like HTML, XTML, SOAP45, XML. Regarding the level of standardization, there has been some progress recently, but so far, it is still unsatisfactory. There are many aspects to problems – on the one hand, the various mobile devices possess a wide range of facilities depending on their class and technical characteristics; some support Java2 Micro Edition (J2ME), others support WAP browsers or only SMS. On the other hand, there are no common technological standards for mobile banking. Different protocols are used (HTML, SOAP, XML), and consequently banking applications have to support a large number of protocols or use a set of widely recognized protocols for data exchange. Over the last few years a number of large US banks, incl. Bank of America, Citibank, Wachovia
Wells Fargo, have been implementing mobile banking solutions
of a new generation and report a considerable rise in clients. An example of the boom in the use of mobile financial services and m-banking are countries like South Africa,
GPRS (General Packet Radio Service) EDGE (Enhanced Data Rates for GSM Evolution) UMTS (Universal Mobile Telecommunications System), HSDPA (High Speed Downlink Packet Access), HSUPA (High-Speed Uplink Packet Access) 45 XTML (eXtensible Telephony Markup Language, SOAP (Simple Object Access Protocol) 41
43 44
Kenya and other African countries; the Philippines, where it is applied by banks in order to reach poor people who had never used banking services before ( the so called unbanked population), as well as in countries like Japan, South Korea, etc. A number of analyst companies (TowerGroup, Frost&Sullivan, Aite Group) predict huge growth potential for mobile banking. According to the findings of one of the latest studies, a report published by the US Federal Reserve on the use of mobile banking as of the beginning of 2012, 87% of US population own a mobile phone, 44% of mobile phones are smart phones (supporting Internet), and 21% of mobile phone owners have used mobile banking in the last 12 months. Another 11% declare it is likely they can start using it over the next 12 months. In addition, 17% of those claiming they are unlikely to use mobile banking services over the next 12 months believe that they will “definitely” warm up to mobile banking at some point in time. These results point to the huge potential of mobile banking in the future. As an obstacle for the adoption of mobile banking services by consumers one points out the dangers involved in security; potential scams; fears of losing a phone containing personal financial data; the prices of mobile financial service and other. Offering mobile financial services is also complicated by the requirement that banks should establish certain business relationships with the operators of mobile networks. We believe that despite the hurdles, prospects are bright for m-banking, because of the growing penetration of mobile phones and 3generation services among users, which facilitates the use of bank services through this distribution channel. Forecast is also positive for Bulgaria, where by the end of 2011 the number of smartphone users is over 1 million or more than 12% of all consumers46. Besides, at the beginning of 2011 their number was around 700 thousands, which constitutes a major growth of about 42%. Respectively, it is expected that the number of mobile banking users will grow in Bulgaria.
According to data from research analyzes agency „Mobile Review“ Source: http://www.vesti.bg/index.phtml?tid=40&oid=4485451 (02.03.2015) 46
42
2.2.6. TV banking Television banking is based on the use of Interactive Digital TV (iDTV). A necessary requirement for the user is to have access to such television ,with the only additional device plugged in the TV set is an external MPEG-447 decoder (set-top box /STB/), in case the TV receiver does not have built-in digital tuner and the above decoder. The client uses the services by means of the TV remote control and menus, navigation achieved with the help of arrows, numbers and color teletext buttons. In order to provide TV banking to their consumers, banks need to cooperate with cable or satellite providers of interactive television. Thus clients get access to both informational and transactional services: information on account balance, transfer of funds between accounts, initiating payments to pre-defined third parties and other. Among the favorable conditions for the development of TV banking is the high rate of TV set ownership (nearly 100%), as well as the growing penetration of digital televisions. Some bank analysts believe that in the developed geographical regions of the world TV banking is not competitive against Internet and PC banking48. It is also considered that its target markets are predominantly Asian countries like India, China and other, not least because their population is more disposed to watching video. As a rule, banks view elderly clients as potential users of TV banking, since these people do not have a computer and Internet access or feel apprehensive regarding the use of the global network for banking operations. As with mobile banking, there are two periods to be outlined in the development of television banking: The first one, in the late 1990s, when TV banking emerged and rather slowly showed its potential, causing many banks to start, and later stop offering TV banking. In Europe the pioneers of offering TV banking are a number of banks in the UK (HSBC, Abbey National, Lloyds TSB Group, Egg, Woolwich and other) and France (Credit Agricole and other), some of which later stop the service. According to research done by Forrester Research and published in 2001, leading financial 47 48
Moving Picture Experts Group (MPEG) http://www.thehindubusinessline.com/todays-paper/your-tv-as-your-bank/article1679948.ece (13.03.2015) 43
institutions in the UK initiated offering IdTV but weak consumer interest and technology limitations prevented the short-term return on banking investments in the development of this distribution channel. At the time around 7% of the 11 million interactive users in the United Kingdom used TV banking49.
The second period, after 2006-2008, associated with the application of
newer technologies like Internet Protocol Television (IPTV), i.e. digital television delivered through Internet protocol. Later some banks start digital interactive TV banking or TV banking based on smart televisions. At present they are offering it as a component of their various distribution electronic channels. Examples of banks offering TV banking include: Brazilian bank Banco do Brasil offers its clients TV banking as a result of a signed agreement for partnership with LG Electronics for their product line of Smart TV50. Scotiabank of Peru, together with Samsung, have launched an application enabling users to conduct banking operations via the Smart televisions of the Korean manufacturer. It is considered that the possibilities for using TV banking are aimed mainly at countries where there is a marked preference for TV and video consumption like India, China and countries in Latin America. Overall, this channel is not considered by ECB to be an insignificant distribution channel for EU banks51. Expectations are for a huge potential for future development with the growing penetration of IPTV. As a summary of the reviewed remote channels for remote delivery of bank products and services, it can be pointed out that ITs have drastically changed, and will continue to substantially impact bank strategies and business models. Banks will develop and enhance their multi-channel management in order to offer their consumers the fastest and most convenient for them access to bank services at any time and any place (anytime, anywhere’ approach).
Centeno, Cl. „Adoption of Internet Services in the Enlarged European Union“, p. 24. Banco do Brasil, Annual Report 2011, p. 95. 51 European Central Bank, “EU Banking Structures”, Oct. 2007, p. 42. 49
50
44
Literature 1. Joshi, V. „E-finance: the future is here“, 2nd ed., New Delhi: SAGE Publications India Pvt Ltd., 2010. 2. Locarek-Junge, H., B. Walter “Banken im Wandel - Direktbanken und Direct Banking”, Berlin, Berlin Verl. A. Spitz, 2000. 3. Ursheva, J. “E-banking is becoming part of everyday life of the Bulgarians”, Computerworld, Sofia, N: 3, 2004. 4. Varbanov, R., S. Parusheva, et al. „Information Technologies in Business”, Faber, V. Tarnovo, 2009.
Internet sources 1. Centeno, Cl. „Adoption of Internet Services in the Enlarged European Union“, Avalable at http://bookshop.europa.eu/en (05.05.2013) 2. Comptroller of the Currency Administrator of National Banks „Internet Banking. Comptroller’s Handbook“, October 1999. (19.02.2015) 3. Couch, K., D. L. Parker “Banking On the Internet.” http://www.forecastcenter.com/ public/guest/banking_on_internet.htm (13.02.2013) 4. European Central Bank, “EU Banking Structures”, Oct. 2007. Avalable at http://www.ecb.europa.eu/ 5. European Central Bank, “Structural analysis of the EU banking sector.”, Nov. 2002. Avalable at http://www.ecb.europa.eu/ 6. European Financial Management & Marketing Association and partners, “Internet
banking,
a
new
wave?”.
July,
2004
7. Eurostat,< http://epp.eurostat.ec.europa.eu/portal/page/portal/eurostat/home> 8. ICICI Bank, India, < http://www.icicibank.com>
45
9. Monetary Authority of Singapore „Internet Banking nd Technology Risk Management
Guidelines“,Version
3.0,
June
2008,
10. Raiffaisen Bank (Bulgaria), 11. Schaechter, Andrea “Issues in Electronic Banking: An Overview”. IMF Policy
Discussion
Paper,
March
2002.
http://www.imf.org/external/pubs/ft/pdp/2002/pdp06.pdf (13.01.2015) 12. Vinayagamoorthy, A., K. Senthilkumar „Role of reach of Internet Banking
in
India“,
(18.03.2015) Self-study questions 1. What is electronic banking? 2. Telephone banking can be offered in different variants, please name them. 3. What are the elements of the apps for PC banking and what are the requirements for user access to PC banking? 4. Name the differences, and then the similarities between the use of PC and Internet banking? 5. Which are the parts included in a software implementation of Internet banking system and what are their functions? 6. What are the key business models for offering Internet banking? 7. Name the different options for mobile banking. 8. Do you think there is interconnectedness between the development of information and communication technologies and mobile banking and how much so? 9. What are the requirements for enabling the use of TV banking? 10. What are the stages in TV banking offering?
46
Chapter 3. SECURITY AND PROTECTION OF INTERNET BANKING Banking via electronic distribution channels increases the banks’ dependence on IT and brings security issues to the foreground. Hazards occur mostly in online banking based on the use of the global network the Internet. Internet banking has numerous advantages for both consumers and banks, but at the same time it is also associated with inadequate protection in some cases of web based systems, possibility for unauthorized access to client accounts and funds and online fraud. To protect the transfer of information between client computer and bank servers and for access control, banks use predominantly standard digital certificates, issued by the bank itself or by an official certifying organization - an entity that issues digital certificates or so called certificate authority or certification authority (CA). With the use of SSL protocol and the associated with it 128 bits encryption, respectively TLS52 protocol, a reliable protection is achieved for the transfer of data between the client computer and bank servers. Banks’ biggest difficulties are associated with the secure confirmation of a user’s identity, i.e. the issue of reliable authentication comes to the fore – how the bank can reliably and securely verify the genuine identity of the client. Entering just the user name, a static password and a choice of client certificate imported in the computer browser turns out to be a technology that is insufficient for a secure authentication of bank clients. 3.1. Potential threats for Internet banking users Internet banking is associated with a number of potential threats for its users. These dangers result from technologies like phishing, pharming, the effects of various viruses, programs of the type “keylogger”, trojans and other kinds of malware. They are used to commit a theft of confidential financial information – user names, passwords, codes, credit card details, etc. Unknowingly to users fraudulent financial operations are performed resulting in theft of money from client accounts, as well as a negative effect on clients’ attitudes and a likely refusal to use electronic channels 52
SSL protocol - Secure Sockets Layer protocol; TLS protocol - Transport Layer Security protocol 47
because of their inadequate security. 3.1.1. Phishing Phishing is designed to steal confidential (sensitive) data. Via bogus e-mails and bogus internet sites, gullible users are being lured to enter and reveal personal information as User ID and passwords, bank account numbers, credit card numbers, PIN codes and other. Typically, bogus e-mails imitate those sent by the banks themselves and, via a link, cause forwarding to counterfeit sites, identical to those of the banks and with a similar URL address.
Misleading domain names - URL confusion One of the most common methods of confusion that scammers use is by intentional registration and using misleading domain names. For instance, for the financial institution MyBank with a registered domain mybank.com
and
the
client-connected
transaction
site
http://privatebanking.mybank.com, it is possible for hackers to create a server by using some of the following names, for the purpose of facilitation confusion with the real host:
http://privatebanking.mybank.com.de;
http://mybank.privatebanking.com;
http://privatebanking.mybonk.com; http://privatebanking.mybánk.com. The counterfeit site,for instance, that of the Bulgarian First Investment Bank has the following address www.finv-b.com, instead of the real one www.fibank.bg. Confusion
may
arise
through
organizations
for
registration
of
domains,
internationalization of domain activity and registration of domain names in foreign languages. For example, a Cyrillic “o” looks identical to the standard ASCII “o”, but can be used for different purposes in domain registration ( as, for example, a company that several years ago registrated microsoft.com in Russia). Other possibilities suggested by the fraudulent technology of Phishing are connected with the following: an e-mail may insistently demand that a phone call is made to a telephone number provided and the number is a bogus one. It is possible to attach to the e-mail a form which has to be filled. With the help of software it is possible to modify an e-mail header – sender, 48
title, etc. Thus in the sender field the scammer enters an e-mail address that commands users’ trust. Distinctive features for recognizing a bogus e-mail are: a much too general salutation (the attacker cannot possibly know the victim’s name; he sends a lot of such attacks and waits for someone to “swallow the bait”); often the e-mail contains spelling or grammatical mistakes, figures are replaced by letters, letter index is inadequate or changeable (so that the spam filter is bypassed) and other. 3.1.2. Vishing Vishing is defined as voice or VoIP phishing and is a fraudulent technology that acts by phishing but is not always realized via the Internet; instead it is most often carried out by using IP telephony (VoIP). A vishing attack may occur via voice message, VoIP, fixed or mobile phone. Scammers use this technology to mislead users into revealing personal financial information over the telephone. While some users have learned to be suspicious to phishing scams, demanding disclosing sensitive financial information directly via the Internet, they are still easily persuaded to reveal such information, when called directly or via an e-mail, instructing them to call a certain phone number. Typically, contact with the user is made by either the telephone or electronic mail. The potential victim gets a message, often by voice synthesis, which informs the user that in his/her credit card account or the Internet banking account a suspicious transaction has been conducted. The user is required to call a particular number and provide information in order to “verify his/her identity” or to “make sure the scam will not take place”. If the attack is performed over the telephone, scammers make sure that the call appears to come from a legitimate source like the bank. 3.1.3. Pharming When users enter a valid URL address in the address bar of the browser, instead of valid sites, they are directed to criminal websites. Readdressing to scam sites is achieved by infecting the local Domain Name Server (DNS). This includes an alteration to the specific record for the domain, which results in the user being sent to a site that is different from the desired (expected) one. DNS server converts the website addresses the user writes in the address bar of 49
the web browser into
IP addresses. For example, when the user writes the address of
the site of Societe Generale Expressbank - www.sgeb.bg, the computer refers to the DNS server of its internet provider in order to learn the site’s IP address and open it. If this address is replaced with another, on writing down www.sgeb.bg the request will be redirected to a server, containing an exact copy of the site. As the user wrote the address him/herself, he/she is not aware of the scam. Another way is for cybercriminals to change the hosts file in the victim’s computer. This file also contains information about IP addresses corresponding to website hosting names. 3.1.4. Trojan horses (Trojans) Trojan horses are malicious programs masked as useful software, i.e. as legitimate software of the type: utilities, files attached to e-mails, games, etc. In most cases users are duped into executing the malicious file in their computer systems themselves. Once open, Trojan horses act in a way very different from what is expected. They cause various problems to the infected system – from consumer annoyance (because of unwanted pop ups, changing the desktop wallpaper, sending emails to everybody in the user’s address books and other) to inflicting serious damage (erasing files, theft of confidential data and propagating other malware). A frequently used function of Trojan horses is the ability to create backdo rs, through which access to the system is allowed to evil-minded users. Active Trojans are an enhanced type of Trojan horses. They use unprotected ports to open communication lines with the user’s computer and eventually provide to hackers control over the client machine. They are also called Remote Access Trojans. Unlike viruses, Trojans do not propagate by infecting other files or replicating themselves in the network. Trojans are propagated by the users themselves, through users’ actions: opening an attached file in an electronic letter, downloading and executing an Internet file and other. A number of examples can be listed of Trojans whose basic function is to collect user banking data – among them being Zeus, the most popular banking Trojan (first identified in July 2007; in 2010 FBI announced they found out a large international cyberspace criminal network, whose members used Zeus in order to 50
break into US computers and steal about $70 million); the Symantec-detected Trojan Neloweg53; Clampi (copying user names and passwords from banking sites and other financial websites and sending them to cyber scammers) and other. Experts from anti-virus software company Kaspersky Lab view Brazil as the major source of the so called banking Trojans. The prerequisites include wide use of Internet banking and the associated criminal activity, the country’s lack of effective legislation to fight cybercrime and other. The biggest Brazilian banks have millions of online banking clients - Banco do Brasil serves 7.9 million online clients, Bradesco 6.9 million, Itaú - 4.2 million and Caixa - 3.69 million and consequently, the predominant amount of malware worldwide (over 40%) steal from the bank accounts of Brazilian banks clients.54
3.11% 9.96%
Trojans 5.82%
Viruses 12.37%
68.54%
Worms Adware/Spyware Others
Fig. 3.1. Types of new malware created in 2014 according to PandaLabs statistics55 An important peculiarity of the various types of malicious code since 2000 has
53
http://www.symantec.com/security_response/writeup.jsp?docid=2012-020609-4221-99 Bestuzhev, D. “Brazil: a country rich in banking Trojans”, http://www.securelist.com/en/analysis/204792084/Brazil_a_country_rich_in_banking_Trojans?print_mode=1 (05.06.2013) 55 PandaLabs Annual Report 2014, p. 8.
54
51
been the growth in the relative share of Trojans and a significant decline in that of viruses. This observation is confirmed by PandaLabs statistics on new malware threats that appeared in 2014 worldwide, which states that Trojans take the leading positions with a share of 68.84% (Fig. 3.1)56. 3.1.5. Spyware One of the serious Internet banking hazards is associated with the software for espionage or Spyware. This is a type of computer programs that secretly, without the user knowledge or permission, collect user information or information about the user’s computer and send it to the spyware author. A spyware program can follow and collect information on Internet use, the webpages visited, downloaded files, personal information such as user name and address; it can generate advertising pop ups, direct user to advertising sites or sometimes copy information the user enters via his/her computer keyboard, for example, sensitive financial information. Spyware programs use the consumer’s Internet connection to send information from the user’s computer to another one without the user’s knowledge and consent. The different sub-types of spyware applications have different features. A common type of spyware is the one that follows browser activity, which is also known as Browser Hijacking. Here, for example, the browser search settings are changed. This allows the hackers to spy on sensitive information such as credit card details or log-in data for online banking, as well as e-mail and Internet addresses. With such data surfing profiles are created and offered for sale to spam sending services. An example for that is the spyware “CoolWebSearch“. Programs of the keylogger type can also be integrated in spyware. 3.1.6. Keystroke logging (Кeyloggers) This hazard is associated with activities involving recording, unknowingly to the user, of the keyboard’s keys he/she presses. Кeyloggers programs can be viewed as spyware. There are various methods for such unauthorized activity, both software and hardware ones. Software keyloggers are a type of program that interferes between the keyboard 56
PandaLabs Annual Report 2014, p. 8. 52
and the operating system, records and stores the pressed keys and then sends them to the operating system. Some keyloggers save the records on the hard disk of the computer that is being monitored, and others send them imperceptibly via the Internet to criminal servers. These data are filtered by the hackers for user names and passwords of Internet banking clients, credit card numbers and other personal and financial data. Hardware keyloggers require direct physical access to the infected computer. They are used in cases when the installation of software keylogger is either impossible or too complicated. Hardware keyloggers are switched directly between the keyboard and the computer and can be installed within seconds. Devices that record data in integrated memory (RAM, EPROM etc.) are later removed and read on another computer. For mass users of Internet banking, predominant dangers are related to software keyloggers for intercepting pressed keys. As a means of protection against hardware keyloggers a virtual keyboard can be used. The symbols entered on this keyboard cannot be intercepted and it is therefore recommended as a measure of protection. It is not, however, effective against software keyloggers. To protect against software keyloggers Anti-Spyware programs need to be installed and regularly updated. 3.2. Identity theft Bank information systems, including Internet banking systems in their bank side, are seriously protected and as a result, it is the client side of the systems that are an object of cybercrime attacks. Users are subjected to criminal attacks by evilminded persons who possess the wide range of malware and technologies outlined above. Through phishing, vishing, pharming, spyware, keylogger programs and other types of malicious code hackers illegally gain confidential information like user names, passwords, credit card details and other, and thus Identity theft occurs. Illegally collected client identity data are afterwards subject to a sale at a secondary black market. For example, around 10 thousand credit card details are sold, including on the Internet, for between 1000 and 5000 US dollars, with huge packets of data changing 53
hands. After acquiring data for online access to client bank accounts, cyber criminals use the stolen user credentials for logging in the Internet banking systems and draining funds from accounts. The technology of scam involves unauthorized access to the user account by means of a stolen identity and transfer of funds to other accounts belonging to intermediaries, known as “money mules”. These people are typically hired abroad, usually in Eastern Europe (Russia, Ukraine and other), and their task is to open a bank account using false names or their own names and documents (Fig. 3.2)57.
Fig. 3.2. Technology of fraud with money mules58
57 58
http://www.banksafeonline.org.uk/node/77 (10.06.2013) http://www.banksafeonline.org.uk/node/77 (10.06.2013) 54
Funds from the compromised consumer accounts are transferred by the scammers into “mules” accounts and afterward “mules” send them to the criminals by means of systems for money transfer like Money Gramm and Western Union (operating without bank accounts), earning a commission for their work. Thus investigators of cybercrime can only get to the “mules” but not to the real perpetrators of financial fraud. 3.3. Methods for protection and authentication of users Checking the client identity (authentication) and allowing the execution of electronic banking transactions (authorization) are a significant inseparable component of Internet banking. As traditional paper-based methods and verifying client identity face-to-face reduce the speed and effectiveness of electronic transactions, financial institutions have adopted alternative authentication methods, including the use of: Passwords and personal identification numbers (PIN); Digital certificates using public key infrastructure (PKI); Based on Microchip devices such as smart cards or other devices – tokens; Database comparisons (e.g. fraud screening tools and programs); Biometric identifiers. The authentication methods listed above differ in the degree of security and reliability provided, as well as in the costs and complexity involved in their basic infrastructures. From this perspective, choice of the used methods should correspond to the risks for the product and service the access to which is controlled by them. Authentication is a process of checking and confirming user identity. Users provide valid identification data, followed by one or more credentials (factors) for having their identity checked. Authorization is a process of permitting someone to act or obtain something. Existing methods of authentication include three basic “factors”59: 1) Something the user knows (knowledge) - such as PIN, password or passphrase. 2) Something the user has (ownership) - such as smartcard or token. 59
Federal Financial Institutions Examination Council: Guidance on Authentication in an Internet Banking Environment – October 2005. 55
3) Something the user is (inherence) - such as fingerprints or voice characteristics. 3.3.1. Something the user knows To this group of methods belongs the “Shared Secrets” method. Shared secrets are elements of information which are known or shared by both sides – that of the client and that of the authenticating institution. The most common examples of the shared secrets method are passwords, passphrase, and PIN codes. A number of studies show that users choose poor quality passwords and are easily persuaded to reveal them. More recent representatives of the shared secrets technique cover: ●questions requiring specific user knowledge as an answer or ●user-selected image, chosen from a series of images provided. Shared secrets security can be increased through requiring a periodical change, since with “static secrets” (ones that never change) the risk of compromising grows with time. Using several shared secrets also provides growing security. 3.3.2. Something the user has Hardware tokens fall in this group of authentication methods. Tokens are physical devices that can be: USB token device – Typically it is as big as a house key; it is inserted directly in the computer’s USB port and does not require the installation of special hardware on the user’s computer. When the token is recognized, the client enters a password (a second authentication factor) in order to get access to the computer system. USB tokens are not easy to duplicate and are not subject to counterfeiting, so they are a relatively secure tool for storing sensitive data. The device can store digital certificates that can be used in public key infrastructures (PKI environment). Smart card – has the appearance and size of a credit/debit card; contains an embedded computer chip. The chip contains a processor, an operating system as well as a read-only-memory (ROM) and random access memory (RAM). The microprocessor allows the smart card to store and process data; it enables software developers to use more reliable verification schemes. In order for the smart card to be used, it has to be placed in a compatible reader connected to the client’s computer. In 56
the process of authentication, if the smart card is recognized as valid (first factor), the user is invited to enter his/her password (second factor), so that the process of verification is completed. The smart card is difficult to double and counterfeit and is therefore a relatively secure instrument for storing sensitive or identification data.
Fig. 3.3. Smart card, that generates one-time passwords (Source: http://www.surepassauth.com/default.aspx) Smart cards can be used in two variants - first, they can generate one-time passwords (for example: when the button is pressed, the card displays on the screen a 6-digit password /one-time password – OTP/, which the user enters in the system and which is later checked by the authentication server of the bank /Fig. 3.3./) or, second, the cards can store cryptographic keys. In the second case, during the execution of a transaction, the user puts a chip card with a cryptographic key in the reader and enters a PIN code. The key encrypts transaction data and they are next sent to the bank. The bank decodes data and checks the electronic signature. Only after data are confirmed is the transaction executed. A major shortcoming of the second variant is that it requires the installation of hardware reader and its corresponding software driver on the user’s computer. A token device that generates passwords – this produces unique 6- or 8-digit access code, also known as one-time password (OTP), every time it is used. The token itself is not switched into the computer, but the one-time password appears on the device’s small display. The client first enters his/her user name and the habitual password (first factor), followed by token-generated OTP (second factor). Client is authenticated if habitual password matches and the token-generated OTP matches the password of the bank’s authentication server. A new password is usually generated 57
every 60 or 30 seconds, i.e. its lifecycle is very short. OTP token can work for about 4 or 5 years (it is battery powered) and has to be replaced afterwards. Token devices are secure because verification is time- sensitive and synchronized. The random character, unpredictability and uniqueness of OTP passwords make it considerably more difficult for cyber criminals to intercept and use the passwords, obtained with, for example, keylogger type programs. There is also a combination between a USB token device and a token device generating passwords. Non-hardware-based scratch card with OTP – scratch cards are a cheaper “low-technology” version of OTP-generating token devices. Like a bingo card, this card usually contains figures and letters arranged in rows and columns, i.e. like a grid. The size of the card determines the number of cells in the grid. During the process of authentication the client first enters with his/her user name and password in the established manner. If they match, the client has to enter, by way of a second factor for verification, the symbols contained in the randomly selected cells of the grid, i.e. the client gets the coordinates of cells in the grid and he/she has to enter the symbols contained in them. (Fig. 3.4.).
Fig. 3.4. Use of scratch card 58
Hardware token devices are electronics-based, they can be damaged or develop a fault. Placing a grid of symbols on a wallet-size plastic card makes it durable and easy to carry around. This type of verification does not require special training and if the card is lost, it can be easily and relatively cheaply replaced. 3.3.3. Something the user is Methods belonging to this group are based on user biometric characteristics and are defined as the best and most effective way to manage user verification. With the help of biometrics user identification and authentication is carried out on the basis of physiological characteristic like fingerprint recognition, iris and retina scan, face structure recognition, hand and finger geometry, voice or hand writing recognition. The most frequently applied biometric techniques are finger print recognition and face recognition. Unfortunately, the biometric method is expensive and is perceived by users as too annoying to use. 3.3.4. Different channel authentication This method of authentication uses a channel that is different from the one the consumer uses to start the transaction. The separate channel certainly provides additional level of security, as a potential hacker has to cover both channels, which is impossible. The different channel is usually used as a second factor for OTP authentication. The different channel for authentication can be: SMS (Short Message Service) to a mobile phone; e-mail; phone call; fax. Banks most often send one-time passwords via SMS text. After the institution receives a transaction request, details of transaction, including a one-time password, are sent back to the user via an SMS and the user has to enter the password in order to confirm transaction (Fig. 3.5.)60.
60
http://www.crypt.gen.nz/papers/asb_netcode.html (10.02.2015) 59
Fig. 3.5. Authentication with one-time code received via SMS 61
3.3.5. Double factor and multi factor user authentication The login process and work in the Internet banking system consists of several steps. In order to access the system the user needs to identify him/herself. Identification is achieved by presenting user’s credentials. The next step – authentication, checks user identity. After that is authenticated, authorization defines what the user can see and execute in the application, i.e. authorization is the process of granting permission for performing particular activities, transactions, etc. Difficulties for banks are associated mainly with the process of the secure confirmation of user identity, i.e. it is difficult for banks to define whether the banking transactions are performed by the real users or by malicious entities, who have stolen a user’s personal data by means of malicious software. To respond to these problems banks and Internet banking systems developers increase the number of factors with which user identity is verified, i.e. they apply the so called multi-factor authentication based on several authentication signs (factors). According to a 2007 survey commissioned by the European Commission 62 the
61
http://www.crypt.gen.nz/papers/asb_netcode.html (10.02.2015) European Commission - DG Internal Market, “Study on user identification methods in card payments, epayments and mobile payments.”, Nov. 2007, pp 3-4. 60 62
necessary minimal level of security demands that web banking should apply two-factor authentication of the type “something that you know” (for example, a password) and “something that you have”, as an additional factor. The mechanisms applied for enhancing security on the part of banks encompass the use of hardware token devices that generate one-time transactional codes of short-tie validity (from one to several minutes); electronic digital certificates based on chip cards; one-time codes that are sent to the user via SMS text and other. One of the conclusions of the survey, however, is that for the time being not all banks have raised the level of security of their web banking application to that of a two-factor authentication scheme. Such a scheme has not yet been generalized, i.e. regulatory bodies have not yet required its mandatory application by banks. Expectations are for the ECB to initiate legislative changes to impose such requirements pertaining to banking institutions within the EU and offering electronic channels based on Internet use.
Literature 1. European Commission - DG Internal Market, “Study on user identification methods in card payments, e-payments and mobile payments.”, Nov. 2007. 2. Parusheva, S. “Cyber attacks on Internet banking - challenges to financial institutions”, “Modern methods and technologies in research”, Publishing house „Science and Economics”, University of Economics - Varna, 2013. 3. Parusheva, S. “Identity Theft and Internet Banking Protection”, “Economic Alternaves”, UNWE, Sofia, 2009, issue 1, pp.44-55. 4. Varbanov, R., S. Parusheva, et al. „Information Technologies in Business”, Faber, V. Tarnovo, 2009.
Internet sources 1. Bank safe Online (10.06.2013) 2. Bestuzhev,
D.
“Brazil:
a
country
rich
in
banking
Trojans”,
http://www.securelist.com/en/analysis/204792084/Brazil_a_country_rich_in_banking_ Trojans?print_mode=1 (05.06.2013) 61
3. Federal Financial Institutions Examination Council: Guidance on Authentication in an Internet Banking Environment – October 2005. http://www.ffiec.gov 4. PandaLabs, PandaLabs Annual Report 2014.
Self-study questions 1. What does the fraudulent phishing technology mean? 2. How is vishing implemented? К
я
? 3. How is pharming different from phishing? 4. What are the effects of malicious programs as Trojan horses? 5. What is the spyware “Browser Hijacking”? 6. How do the Keylogger programs work? 7. Please, give a definition of user authentication and authorization. 8. What is the group of authentication methods “Something the user knows” like? Please provide examples for them. 9. What are the methods of authentication that belong to the group methods "Something the user has"? 10. What is authentication like when using a different channel?
62
Chapter 4. ONLINE INSURANCE Over the last few years the major trend in the use of information and communication technologies in the insurance business has been the application of Internet-based solutions and remote channels for the sale of insurance products and services. Owing to the advance of online insurance, also known as e-insurance, clients are provided with multi-channel access to insurance products and services. 4.1. Nature and purpose of online insurance E-insurance can be broadly defined as an application of the Internet and the information technologies related to the global network for offering and distribution of insurance products and services. In a more narrow sense E-insurance can be viewed as offering and negotiating insurance and respectively taking out insurance policies online63. Its scope covers payment and delivery of policies, claiming and processing damage, but, in some cases for technical reasons, and in some countries because of regulatory restrictions, these elements of the insurance process cannot be covered. Specifically, online insurance is defined as an interaction between an insurance company and its client that takes place during the sale of an insurance product, its service and payment of indemnity (in case an insured event occurs) when the interaction is performed entirely or mostly using the Internet64. Generally, in insurance theory there are two basic ways of placement insurance products: direct and indirect65. With the direct one provision of insurance products suggests a direct contact between the insurance company and the user of the insurance service. Indirect placement means including intermediaries in the channels for sale of insurance and these are called insurance brokers. They come as intermediary entities – firms that function as an individual business, but work for one, or, in most cases, more than one insurance company. The intermediary role of brokers is performed two ways – on the one hand they act as consultant, a proxy for the would-be insured, and on the other, they sell services, developed by insurers, and get paid a commission. Following Joshi, V. C. „E-finance - the future is here”. 2. ed., Los Angeles, Calif., 2010, p. 59. Parusheva, S. “Internet Insurance - Opportunities and Prospects for Development.” - Information Technologies, Scientific centre “Documentless information systems ”, University of Economics - Varna, N: 4, 2008. 65 Iotov, I.; Boyan Iliev. “Basics of Insurance”.- Svishtov: Academic Publishing “Tsenov”, 2004, p. 81. 63
63
64
the division of placement into direct and indirect, online insurance falls under the direct placement category. Here one finds the basic advantage for consumers – by selling insurance directly to clients, insurance companies save on the commission they habitually pay brokers, for example from 10% to 15% in sales and conservation in the field of general insurance and between 35% to 100% in life assurance. When online insurance is at its broadest and fullest scope it includes: calculating the insurance premium and defining the terms and conditions for its payment; filling in an electronic application form to request insurance; payment of insurance premium – as a one-time payment or periodical payments (deferred insurance premiums); delivery of policy, verified by the insurer’s electronic signature to the client, directly via the Internet; service of the insurance contract throughout its duration (information exchange between an insurer and the insured client – producing reports upon the client’s request, incl. statement of condition and the history of amendments of contracts, payments and compensations); exchange of information between the insurer and the insured when the insured event occurs (claiming damage, etc); payment of insurance compensation by the insurer via the Internet when the insurance event occurs; insurer’s provision of other services and information to the client – consultancy, explanation of insurance terms and other. As we mentioned above, for various reasons it is impossible to cover all these business processes in online insurance. 4.2. Peculiarities of insurance business that complicate online insurance According to financial theory insurance business is much more conservative than banking. For this reason, there are factors and prerequisites in online insurance that further complicate the use of web technologies in insurance unlike electronic banking or Internet trading. 64
What comes first among these factors is the fact that insurance products are less standardized, are difficult to typify and respectively digitize. Second, a number of insurance products are characterized by considerable complexity, which requires additional explanations and consultations with the respective insurance professionals. We should also add to the complications potential hurdles on the part of the regulatory bodies that supervise insurance business. An important specific feature of insurance, and particularly property insurance, is that, as a rule, insurers have to perform an inspection of the insured property, no matter what it is – flats, villas, houses, vehicles or other property. Without an inspection, there is considerable likelihood of fraud and bad faith66. Remote sales of insurance products largely depend on how much consultation consumers will need. Insurance products that are suitable for online distribution channel are those that can be standardized within a framework and be described and assessed by means of fewer parameters, as well as the ones whose choice does not require considerable consultation. Research done by the leading Swiss reinsurance company Swiss Re has established the following: the more complicated the product is and the higher the value of the contract, the more willing the client is to pay for consultancy. Respectively, the product’s larger consultancy component renders it less applicable for Internet distribution67.
4.3. E-business models for Internet distribution of insurance products E-insurance is based on the intensive application of Internet-based technologies, facilitating the building of new business models. These can be differentiated in several directions, the major ones being shown in Table 4.1.68 4.3.1. Insurance companies websites Remote sales of insurance products through insurance companies’ websites are for the time being the most common e-business model in insurance. Shishmanov, Kr. “Information systems and expertise assessments in insurance company.”, 2007, p. 42, 44. Swiss Re, “The impact of e-business on the insurance industry: Pressure to adapt – chance to reinvent.” Sigma No. 5/2000, p. 11. 68 Swiss Re, “The impact of e-business on the insurance industry: Pressure to adapt – chance to reinvent.” Sigma No. 5/2000, p. 14. 65
66
67
Table 4.1. Business models for Internet distribution Type of model
Business model
Sites of insurance companies
Online sale of traditional products
Financial portals
Portals for financial services and / or insurance
Portals - points of sales Aggregators
Web sites related to specific events Independent price comparisons
Example www.ineas.com www.progressive.com www.aviva.co.uk www.renins.com www.bankrate.com www.tescobank.com www.money.co.uk www.autobytel.com www.insure.com www.insweb.com www.insureme.com www.comparisonmarket.com www.ehealthinsurance.com
Source: Swiss Re Economic Research&Consulting and adapted by the author At present all insurance companies have websites through which they realize 2 levels of using the global network: providing information services, which can be defined as offline or passive insurance, and Offering and a certain degree of selling an insurance product (online insurance). Over the last few years insurance companies have realized through their websites a minimum of the first level of Internet use – information to present the company and its products: information on the company, its profile and specialization (general insurance and/or life assurance), comprehensive information and description of products and services, possibilities for contact, office network and at best, possible calculation via electronic insurance calculator of the insurance premium concerning a particular subject (for example, Motor-Car Casco insurance). Some authors call this 66
first level “an electronic business card”69. On the next, higher level are transactional sites, through which one can purchase, and afterwards service insurance products online – calculating the insurance premium (i.e. creating a particular offer /quote/), its payment, eventually making a damage claim and its processing, maintenance of the insurance contract and other. Some of the mentioned facilities are available on various insurers’ websites or they are available to a varying degree. Though not very common, there are websites that cover all the stages of signing and executing the insurance contract (the so called Full Service Websites) – from getting an offer quoting a concrete premium to claiming damage and being paid indemnity and making amendments on the contract. By way of example we can examine the website of the US company Kemper Direct (a division of Kemper Corporation), specialized in car insurance and housing insurance70. In addition, on their websites some insurers provide up-to-date information about a similar product of competitive companies. 4.3.2. Financial portals Another major e-business model is associated with financial portals offering quick standardized insurance products to Internet users under exceptionally competitive conditions. Within the context of various electronic financial services, as a distribution channel the Internet may not be attractive enough, should consumers need to familiarize themselves with different separate websites in case they need several financial products.The major advantage of financial portals consists of the fact that while using other services financial portals provide, consumers may also take advantage of the insurance offered. A financial portal relies on its established brand name, which attracts a constant stream of visitors, and offers a wide range of financial products and services, including insurance ones. Regularly using a financial service of a different kind, a consumer happily goes for buying insurance online, too. In table 6.1. examples are given of several portals, like www.bankrate.com, www.money.co.uk 69 70
Shishmanov, Kr. “Information systems and expertise assessments in insurance company.”, 2007, p. 38. https://direct.kemper.com/home.aspx 67
and other. 4.3.3. Point-of-sale portals Point-of-sale portals are connected with purchasing insurance as a result of another event that involves additionally buying such a service. Point-of-sale portals are the Internet locations where it is possible to buy an insurance product because of another event that demands that such service be added. Point-of-sale portals carry out product marketing of a certain insurance according to a definite thematic trend of a site’s online sales, for example real estate, cars, etc. In these cases the initiative for taking out an insurance comes from the seller and not from the client him/herself71. Sites with suitable thematic specialization for initiating selling insurance are associated with themes like Retirement, Career Change, Wedding and other. 4.3.4. Aggregators Aggregators work on the basis of an electronic business model, by means of which they offer clients the possibility to compare online insurance offers by various insurance companies. The model is applied mostly in specialized insurance sites, as well as in insurance brokers’ websites. Usually apart from the chance to compare various insurers’ offers, aggregators also provide general information about the insurance product, which brings about greater knowledge on the part of consumers and a rise of their insurance culture. Aggregates often provide educating tools, such as a glossary, learning center (for example Learning Center in InsWeb and other sites) etc. Some of the insurance portals are narrowly specialized in a particular insurance segment, such as www.ehealthinsurance.com, which provides medical insurance offers based on the leading companies in this field72. Giving consumers the opportunity to compare in one place, in one window, the peculiarities of offers by a multitude of insurers and choose the most advantageous one, aggregator sites enjoy exponential growth, according to assessment made by Infosys company. Its surveys reveal that aggregator-generated sales account for over Swiss Re, “The impact of e-business on the insurance industry: Pressure to adapt – chance to reinvent.” Sigma No. 5/2000, p. 15. 72 https://www.ehealthinsurance.com/health-insurance-companies (20.02.2015) 68
71
50% of the total of online insurance sales. 4.4. Applicability of online insurance and its reception by consumers Depending on its object, insurance is divided into two great fields – general insurance and personal or life insurance. For remote sales it is better to offer general insurance policies, in particular the division of car insurance – of motor vehicles: Third Party Motor Liability Insurance, Casco Insurance, Green Card Insurance to be taken out before driving abroad; property insurance - housing (apartments, houses, villas and other), various personal liabilities (for example, Professional Indemnity Insurance for persons providing particular professional services and other). From the personal insurance category what is suitable to offer is Accident Insurance, Travel Insurance, Health Insurance, Term Life Insurance and other. Car insurance and in particular Third Party Motor Liability Insurance account for the largest share of online insurance. According to experts, 85% of all insurance bought on the global network worldwide are Third Party Motor Liability Insurance. According to the result of a recent study of Vienna University, performed in cooperation with the consultancy companies Mount Onyx and TCI Consult, published in mid-2012, a conclusion is made for a rise in online insurance companies in Europe73. Online distribution channels in Europe were analyzed and a survey was carried out in over 30 countries and of over 200 insurance companies. It is reported that direct insurance sold via the Internet and over the telephone accounts for a turnover of 80 billion EUR (gross premium income) in general and life assurance in Europe. Data on the direct channels in European insurance reveal significant differences regarding consumer reception. The authors of the study divide countries into three groups according to the market share of online insurance within general insurance: mature countries with a market share of over 10%, like UK; developing countries with a market share of between 1.1%
10%, like Spain; emerging countries with a market
share of 1.0% and less, like Russia. Finsinger, Jörg, Johannes Ospald „Best Practice Report. Direct & Low-cost Insurance in Europe.“ MOUNT ONYX, University of Vienna, TCI Consult, Vienna, 2012. 69
73
Over a 10- year period (from 2000 to 2010) direct channels in Europe demonstrated a much higher growth rate compared to that of the traditional market for general insurance (26% against 7% respectively). The UK can be mentioned as an example of the serious presence and significance of direct channels in insurance. The country is in the mature market category and there the share of clients buying Third Party Motor Liability Insurance remotely is over 25%. Other sources (Google’s Consumer Barometer74) also provide considerably higher ratings for British consumers’ perception of online insurance – the percentage of consumers buying online car insurance is estimated at 58%, and with housing insurance – at 52%, i.e. considerably higher shares.
Literature 1. Financial Supervision Commission, “Annual Report for activities 2012” 2. Finsinger, Jörg, Johannes Ospald „Best Practice Report. Direct & Low-cost Insurance in Europe.“ MOUNT ONYX, University of Vienna, TCI Consult, Vienna, 2012. 3. Integrated Information Systems, CRM and Internet solutions - key areas of IT investment in the insurance business. - CIO (Chief Information Officer), Sofia, ICT/IDG, Issue 12, 2006. 4. Joshi, V. C. „E-finance - the future is here”. 2. ed., Los Angeles, Calif., 2010. 5. Parusheva, S. “Internet insurance – opportunities and prospects for development” – Information technologies, Research Center “Papesless Information Systems”, UE-Varna, Issue 4, 2008. 6. Rahman, Hakikur „Cases on Progressions and Challenges in ICT Utilization for Citizen-Centric Governance“, IGI Global, 2012. 7. Shishmanov, Kr, L. Krastev. “Information systems and expertise in insurance company”, Abagar, V. Tarnovo, 2007.
74
http://www.consumerbarometer.com 70
8. Shishmanov, Kr. “Internet- representation of insurance companies.”
.
“Innovation and transformation of organized markets in Bulgaria ”, 23-25 Oct 2002, Publishing house „Science and Economics”, Varna, 2003. 9. Varbanov, R., S. Parusheva, et al. „Information Technologies in Business”, Faber, V. Tarnovo, 2009. 10. Yotov, Y., B. Iliev. “Fundamentals of Insurance”, Academic Publishing house “Cenov”, Svishtov, 2004.
Internet sources 1. Avira, 2. eHealthInsurance Services, 3. Financial Supervision Commission, 4. Google’s Consumer Barometer 5. INSURANCE.BG, 6. Kemper Direct < https://direct.kemper.com/home.aspx> 7. Moite pari, 8. Progressive Insurance Group, 9. SDI Group Ltd, 10. Swiss Re “The impact of e-business on the insurance industry: Pressure to adapt – chance to reinvent.” Sigma No. 5/2000. http://www.swissre.com/pws/research%20publications/sigma%20ins.%20research/e-business%20in%20the%20insurance%20industry.html 11. Unitrin Direct Auto Insurance, 12. zastrahovatel.com,
Self-study questions 1. Please, give a definition of Internet insurance. 2. What does Internet insurance include in its most complete coverage? 3. What are the characteristics and specifics of the insurance business that complicate the Internet insurance? 71
4. Which insurance products are suitable for sale via the Internet insurance? 5. What are the levels through which insurance companies use their websites? 6. What is the difference between online and offline insurance? 7. What are the benefits of financial portals compared to other e-business models for insurances? 8. What is the role of aggregators in online insurance? 9. How can countries be divided in terms of their market share in online insurance? 10. How can the state of Internet insurance in Bulgaria be assessed? К я
И
я?
72
MODULE E-GOVERNMENT Chapter 5. ADMINISTRATIVE PROCESSES 5.1. Nature of the administrative process Administrative processes are a sequence of the actions of specialists and employees of the public administration, who perform functions of the state authority and the local government. These actions have to be formally regulated, so that preliminary fixing, creating and using administrative information is possible. Every administrative process requires the provision of established administrative regulations together with rules to define the roles of executors. The exchange of official information within the administrative apparatus practically results from the specialized information sectors, including the systems of various departments. Here we should also include the exchange between the various levels of administrative government (national, regional, local) as well as between the information systems of departments, citizens and organizations. Administrative processes need a “formalized”language that is clear to both people and computer systems and is meant to describe the sequence of actions and the documenting of their implementation. This allows for describing as specifications (scripts) the long chains of service passing through the various departments and levels of administrative and state government. The already described interdepartmental processes should not be included. Specifications allow for organizing discussions between various offices, as well as for improving operativeness and developing the shortest and most effective administrative processes possible. It is also necessary to foresee the responsibility of various departments for documenting the activities (operations) participating in the administrative process. Unlike functional description, the formal description of administrative processes allows for the identification and elimination of contradictions (conflict of interest) which impact the transparency and accountability of the process. Naturally, when there is conflict of interest it is impossible to show objectivity in management decision making. With process description operativenesss can grow manifold if electronic documenting is used in the administrative process. Administrative processes 73
during the execution of which the official information is documented using the instruments of information-and-communication technology are called electronic administrative processes and the regulations defining them – electronic administrative regulations. The rules for electronic execution of administrative processes are, to a substantial degree, defined by the computer applications that implement administrative logics. This is an additional argument in favour of the inclusion of results or computer applications into the regulatory base along with the traditional specifications and instructions. For electronic administrative processes electronic administrative regulations encompass not only regulatory enactments but also the software tools designed for their implementation. In the electronic administrative processes not only means of informatization are used but complex information-and–communication instruments, as data resulting from documenting are subject to being passed electronically among citizens and administration and from one administrator to another. Thus one of the effects of the reforms carried out is reducing the complexity of participation in administrative processes for the state authorities, the citizens and the business alike. This, however, cannot occur automatically with the conversion to electronic instruments of documenting.There seems to arise a strive for increasing the scope and complexity of documenting procedures.Therefore, the transition to electronic administrative processe does not translate as an automatic reduction of the administrative burden for citizens and organizations.The complexity of the processes which citizens and organizations also have to take part in, may grow even further. What is necessary is a set of political decisions to guarantee reducing the administrative burden during the transition to electronic administrative processes. Administrative processes will be transparent, provided there are regulations and unambiguous descriptions in a formalized language. It is mandatory that administrative processes be controlled when official (documented) information is useed. Operativeness is provided on the basis of electronic transfer of official information and also through rationalizing the sequence of activities of administrative specialists.
74
New institutions (already in the electronic and not in the paper-based public administration) have been provided with electronic documenting, electronic access for citizens and organizations to state information. Electronic administrative processes will possibly be sabotaged by bureaucracy, so it is necessary to act in order to ensure exceptional control. It is a matter of conformity of administrative regulations to the principles and requirements set in the regulatory basis. Regulations should refer to the administrative document turnover so that they ensure access for the government, for citizens checking official information. Regulations are used in the course of administrative processes, as well as in the very sequence of actions connected with government decision-making. Such control, complementing the state authorities’ internal control and the control on the part of representative authorities, should be exercised by independent external audit. Then it will not be necessary for the number of state-employed examiners to grow and it will be fully possible to follow the principal rule of citizens assuming control over their state. The external (private) auditor is unlikely to zealously defend “solidarity” as is often the case with the state-employed examiner. Already there are similar precedents in banks, organizations, enterprises and other, which are checked by private auditors. It is fully possible for this practice to spread across all typ es of administrative activity. This audit should be funded by the state budget, but auditors should be selected according to the principle of open competitions. Naturally, an audit, as a measure of control (aimed at finding out inconsistencies between requirements and enactments), should be tied up with actual sanctions in case irregularities are disclosed. The presence of an external audit substantially raises responsibility and also helps to ensure the necessary transparency and review efficiency. It is exactly the existence of an independent audit (and one that is external to the state apparatus) that makes the other basic institutes of government efficient. In order to create a transparent and effective electronic government, there have to be transformed the administrative processes citizens face on a daily basis and which are not easily controllable because of the proliferation of sectors such as:
“Personal filing” sector for the population and the duties that entail,
“Registration” sector, “Targeted public benefits” sector, “Social services” sector,etc. 75
Sectors for Reporting Entities and their liabilities to the state;
Sectors for Cadastral Filing and Reporting of Vehicles;
Regulatory basis, including various types of projects;
Filing of court rulings and administrative procedures of citizens and legal
entities in courts;
Relations in the course of the budget process, etc
For each of these sectors what is needed above all is analysis of and amendments in the legislative initiative in order to:
precisely define the object of filing;
remove the current restrictions generated by the mandatory paper-
document flow and paper-based information exchange in the course of administrative processes;
prescribe requirements for the new administrative processes, already
taking into account the electronic form of information exchange;
to further define information regulations about what to present as
information available to the public,as well as defining other specifics of using official information;
define the necessary budget funding and assessment of the regulatory
burden that results from the need to implement information-and-communication technologies to support electronic filing, administrative processes, access to information and audit. The electronic provision of these administrative process and the remaining ones, inevitably calls for administrative re-engineering, combined with planning the resources necessary. The need for re-engineering is based on the substantial problems associated with the impossibility of pilot implementation without preliminary amendments in the legislation and the impossibility of new legislative initiatives without
preliminary
being
clear
about
the
information-and-communication
technological solutions. Forms of administrative re-engineering that have performed very well in developed countries contain the following mode of action: 1. Administrative re-engineering is carried out in the functional institutions of the government (condition, licensing, registration, etc) by creating: 76
-
a package of legislative amendments – on the respective functions of
government, taking into consideration the transition to an institution of the electronic government; -
technical standards defining the use of metadata and prototypes;
-
a filing system prototypes which confirm the efficiency of technical
standards and their conformity to the project for legislative amendments; -
evaluation of the resources necessary for the transition to the new
administrative processes all over the country; -
methodological materials providing the conversion to new procedures.
2. The package of legislative initiatives takes effect while simultaneously provisions are set aside for the implementation of the new electronic administrative processes of institutions and dedlines are fixed for the following to be carried out:
creation and/or change of the necessary software provision;
adapting procedures
(according to regulations) connected
with
administrative processes;
transferring the current document turnover in the required formats
(where necessary);
combining the interaction between the infrastructure organizations of the
electronic government;
training for the civil servants in charge of particular operations within
the administrative processes and coordination of their execution;
Explaining and clarifying the nature of the upcoming transformations to
citizens and organizations. These exactly should be the procedures of the upcoming administrative reengineering, and not just local changes in administrative processes by introducing certain software provision in the course of informatization. 5.2. Structure of the process The major problem in the building of electronic government consists in the fact that territorial and sectoral information systems and resources are not integrated, and their corresponding departmental networks do not form a unified communication structure in the Internet, nor do they communicate with one another. As a result of 77
disintegration there is duplication, patchy automation, closed information resources, isolated information flows, unestablished horizontal links,etc. Building departmental networks at the cost of huge budgetary funds and their closed usage do not create a unified environment for electronic exchange of documents. The same holds true for sectoral databases. Eventually, what happens is a frequent need for additional work on these networks’ technical components and as a result, the aggregate cost of the information systems and resources used rises considerably. Existing models for creation of information systems in the bodies of state governance and the local government, in particular sectors and spheres are predominantly used as automation of functions based on organization of specialized jobs. Such automation, however, as is the case with the processes of processing document flow of the previous kind, sometimes results in another, and even less effective, type of work. The senior management overload of current decision-making (due to multi –departmentalization /multi-linkedness) on the issues of document turnover that only administrative specialists worry about, merely results in worsening the quality of service. What is more, the need arises for a double amount of work on the screen and paper-based forms, more time is spent on scanning and printing correspondence. Meanwhile, however, the very efficient instrument for information systems integration, analysis and management-decision making - the service-oriented systems – are predominantly used for data presentation and preparation of prototypes. No substantial effect is achieved by the implementation of local information systems from the viewpoint of ensuring the socio-economic development of one or another division of public administration or for improving the living standards of the population. It is necessary to develop a quality model for creating electroning governance which should create real conditions for integrated use of information systems and resources in public administration. The building of such a model passes through the following stages: During the first stage of the model implementation it is necessary to solve the problems with servicing the processes of the strategic management of administrative territories, with the tasks including certain parameters of effective management of business processes. In order to achieve a result, one has to analyse the functions of 78
each division of administration, internal and external interactions, criteria for effectiveness of divisions, and above all, the services resulting from their activities. This stage allows for the definition of external objects and for the development of technical requirements before information systems. During the second stage it is necessary to create target modules through which to form and analyse in a real time mode the databases for the management report, along with balanced scorecard for the activity of the center of responsibility. Modules could be as follows: Module for control by objects – in the housing and communal services, in the territorial planning, in the social, legal and other spheres. The module comprises distributed databases for budget financial management. It is also designed to monitor the budget resources used, as well as for analysis of the activity of budget organizations and enterprises with state and municipal participation. The organizational structure of this module corresponds to the economic and financial management, to accounting and operational reporting. Module for analysis of activity – it is based on reliable data entered. It provides cluster document analysis and employs interactive methods for gatherinf statistical data. It allows for the implementation of monitoring and analysis of socio-economic processes by territories. It defines the efficiency of the budget funds used. It is feasible that the module integrates a system for document turnover with information-search, information-advice, and geo information systems (whereby leading technologies can be used, such as push-to-talk – press for a conversation, WiFi – Wireless Fidelity – a wireless technology for data transfer, GPS - Global Positioning System and other). Module for business processes optimization – it provides the intellectual routing of queries and electronic document flow, includes contact centres, interactive reference system and voice fax-servers.Within the structure of the module there should be unified processes from the IT sector, management of strategic development, accounting, human resources, finance management and economics. Module for personnel motivation – contains a system for staff planning and allows for the organization of interactive inquiries to the population and the specialists,
79
for testing and training civil servants and municipal employees. As an organizational structure it corresponds to Human Resources. Module for knowledge management – it provides the implementation of electronic document turnover by accumulating documents in an electronic library in the mode of burst capture documents, use of systems for stream scanning and barcode identification of documents, applying full-text search, aggregating report data from lower levels of government and sectoral spheres, subswitching to external databases. The module includes a system for integrated document management and record management. The system allows for the organization of synchronized report on paperbased and electronic copies of documents. Automated tools for withdrawal and retrieval of procedures are applied. Module for preparation of decisions – for developing a strategy and management of changes. It integrates databases of typical procedures and expert systems models. As an organizational structure it corresponds to economic management and strategic management. Module for implementation of decisions and control – it serves the automated complexes of electronic document turnover, corporate software provision, team work and it also provides automatic answers brought together in the Web portal. As an organizational structure it corresponds to the secretariat and head office. During the third stage of the creation of the model for electronic government the formation of necessary information resources and infrastructure takes place. The study of the functions of territorial government makes it possible to differentiate four basic (primary) information blocks of the unified information spave of the region. These are “Territory”( electronic maps, schemes and plans, including engineering communications, transport and other networks), “Real estate” ( buildings, facilities, residential and non-residential premises), “Population” and “Legal entities”. In order to rule out any duplication of information, to prevent mistakes and reduce costs involved in checking data, it is necessary to dedicate a single credible source of basic information – a nod for registration of individuals and legal entities and real estate. All the remining informational databases are constituted using those three blocks. Such databases are created to solve consumer tasks within the separate sectors and they 80
constitute the middle-tier of databases. Accuracy and the degree of detailization should be enough to execute the task set (payments of rent and housing and communal services, subsidies and grants, measuring plots during preparations for construction, etc). At the highest level (Head administration and deputies) a system is built for facilitating decision-making and an expert information system ,both operating with complexes of data aggregated at a lower level by means of specialized gateway filters. Thus, in accordance with the tasks solved, one raises the degree of aggregating, the complex character of information and the resulting indicators while information moves to the top of management hierarchy. Here it is necessary to define a circle of officers to work with particular indicators at the level of head of sector, management levels, head administration and deputies. During the fourth stage there is performed the building of a unified information portal – a resource of power that is “spread”over the Internet and departmental networks. The process of creating the portal can be crried out on a large scale or with the help of individual pilot projects in various spheres. While developing the portal, one has to take into consideration the possibility for organizing access via portable devices. For instance, with an SMS message taxpayers can confirm the correctness of their income tax returns or vote in elections. The major tools for the protection of the confidentiality of information in the course of inter-departmental exchange via the open communication channels and accepting citizens’ electronic documents through the portal, are systems for data encryption. Smart cards can be used as an instrument of integration in the portal. Besides, a basis function is integration with external systems, which includes a system for accounts of budget transfers, a system for base changes in tax and budget legislation, and other. For the complex solution of the tasks of integration, increase in the functional facilities of the systems and their scaling, it is necessary to set up speciaizedl enterprises – developers of information projects. They should be commissioned to achieve software provision and specialized basic functions of the electronic government. One of the functions of such an organization should be the management of automated work stations (Thin Client) for the organs of executive power and budget 81
organizations, which should replace the current practice of buying hardware that is bound to quickly become outdated. Such a form of realization of the process (based on outsourcing or leasing) of building an information system has been implemented in the developed countries and it has a number of advantages. Above all, it eliminates the time lag between changing the software provision requirements and the time necessary for updating the hardware tools. Developers collect and analyse the solutions offered on the IT market, carry out a “stock count” of existing information systems and resources, suggest projects for informatization, obtain offers and requests for the general system part of information systems and administrative subjects, by municipal organizations, territorial divisions of sectoral complexes, by coordinating councils and expert councils of head administrations, ministries and departments. They sum up, analyse circumstances and, if necessary, refer to expert organizations. When they complete the development of the system, developers organize the reception and delivery of an information system and resources in test, trial and commercial exploitation. Existing information systems, built on budget funds, can be registered as core capital. The systems that developers create are designed for integration and ensuring control over the existing ones and for the implementation of a unified strategy in the field of informatization. The current financing of developers is provided through paid services offered to the public and to organizations (broad band television, digital telephony, Internet access and other), as well as by the authorities ( for developing technical assignments, projects, expert reports, organization of competitions and other), as well as from the commerci l use of infrastructural elements. As a whole, such organization helps to integrate territorial and sectoral information systems, to avoid duplication of data and the corresponding budget costs, to ensure reliable exploitation and the necessary level of security of the information-and-communication infrastructure of the electronic government. The fifth and sixth stages related to the building of electronic government is the management of queries, changes and results. A flexible import of corrections is envisaged in the developed administrative processes, software complexes and return to a previous stage. During those two stages a transition is achieved to process methods 82
of management. Methods are oriented to effective coordination of the management systems – along horizontal and vertical links, between the subdivisions of authorities as well as with external organizations. The management of changes allows organizations to constantly progress. It allows them to systematically refute their doubts in their own efficiency through the usable technologies and the models for decision-making. These organizations can get rid of superfluous bureaucratic procedures by adopting, adapting and implementing new ideas and technologies. The model of realization of the electronic government via developers is the foundation of software and and the concept of specialized enterprises which create the affiliate structures of service-oriented architecture. 5.3. Information process Information process is the process that functions by means of regulated operations (actions) performed on data in the course of which the composition, content or form of data can be preserved or transformed and presented in their finished form – as information. Processes involved in information are ubiquitous, i.e. they exist and act everywhere: in human relationships, in Nature, in the technical environment, and in public administration alike. A human perceives information through his/her senses, he/she stores and processes it using the brain and the cenral nervous system. The essence of the human mental activity is concentrated in the ways of processing information. A human thinks, calculates, talks, listens, reads, writes, draws, etc., whereby the individual always interacts with information. Technical devices perform the role of an intermediary in the communication with information that takes place between people, institutions and the surrounding environment. Without the help of technical devices it is impossible to obtain certain types of information that are inaccessible for direct reception by a human. A human is unable to quickly process huge arrays of data, to transmit information over long distances or store it for the future generations. A number of examples of information processes can be listed, but among the multitude, the following can be distinguished as the essential ones: receiving, processing, transmitting, storing. The above mentioned processes are basic processes. Their execution generates other information processes and sub-processes. Thus, for 83
example, receiving information can be associated with its occurrence, its search, accumulation, systematization, etc. While information is transmitted, it is necessary to ensure its protection from destructive impacts. All processes require a certain form of representation of information, which is defined by a process called encryption. This process accompanies all the remaining ones and is the link between them. Information processes are not isolated, but they run in cycles, in unity and interconnection with one another. Receiving information. In receiving information the leading role is played by the method of perception and the form in which information is presented. Very often these information procedures are defined by the recipient and, more exactly, by his/her abilities to receive it. It is useless, for example, to transmit information in the form of sounds, to n individual who is unable to hear. Information is necessary to humans not per se, but in the right time, so that a human can get orientation in the surrounding environment and make decisions for further actions. Here an important role is played by the properties of information. A human creates instruments and technical devices which allow him/her to receive information that is inaccessible to his/her senses and processing capacity. Technically, an analogue of the human senses are the respective sensor devices, detectors, microprocessor systems and other. Information received is input information, and, as it is known in computer technology, special devices are used for inputting information, such as a keyboard, scanner, radio, microphone, mouse and other. Processing information. Processing is the transformation of information – alteration of its content or form of presentation. Usually the changes in the contents of information are expressed as editing, mathematical calculations, logical inferences and other actions. Arranging, encryption and translating into another language are considered to be changes in the form of information. Encryption is also one of the variants of information processing. Processing of information can be performed formally, according to rules prescribed in advance or according to a set algorythm. It is also possible to apply euristc approaches, whereby a new syste of actions is created or a new, so far unknown, law is discovered in the object that is being studied.
84
Transmitting information. Information is transmitted along communication channels and it is directed from the source to the recipient as a sequence of signals making up a communication message. The physical meaning of the signal may not coincide with the meaning of the transmitted information. Source information is converted into a type and form that is accessible to the communication channel, and after that is decoded into a type and form that is understandable for the recipient. To achieve reciprocity, a preliminary agreement on the meaning of symbols must be reached. During the process of transmission, information may be damaged or lost as a result of various impacts. The reasons for them can be both technical (overload, vibrations, electric and magnetic field, a drop in temperature, aggressive environment) and resulting from human interference/intrusion. Storing information. Information cannot exist without its carrier – an environment that directly stores information. Therefore the term ‘carrier’ should be interpreted as ‘having the inherent quality’, that is, containing in itself and not transferring information. What could a carrier be? Any object (but for electronic processing it is a more specific one – electromagnetic, light, sound) or a different state of a substance. Information can be in the object itself, or recorded on an external carrier – recorded on paper, magnetic tape, picture, photo- and film-document, etc. In order to retrieve information from an external carrier, additional instruments, typically technical ones, are necessary. For instance, in order to receive information contained in magnetic environment, the respective reader is needed. Computer technology provides numerous facilities for storing information in a compact form: electronic, electromagnetic, optical carriers. They are characterized by their information capacity, time for access to information, reliability of storage, uptime. Systematization of information processes into a unified information system is necessary to begin by performing a qualitative analysis on the information content of the studied object. Information content can be divided into internal and external. Internal information brings together the following information: -
primary documents;
85
-
internal document flow (paper and electronic), including orders and
instructions given by the director or manager of each division; -
operational and accounting reporting for present or passed periods;
-
analysis and control of financial and economic activity;
-
other data.
The quality of the internal information content depends on the organizational structure of the governance, the rational allocation of functional duties, reliable accountability, sufficient efficiency of the document turnover. Internal information content is formed by its own sources of information, which can be checked for comprehensiveness and credibility. The variety of external information and its sources are basically the following: -
normative acts/enactments;
-
sectoral normative-and-reference type of documents;
-
sectoral reports,based on market sales;
-
state of the economy;
-
advertising, information for the public and organizations;
-
expert and consultant conclusions.
It is necessary to bear in mind the following essential problems that arise in the creation of the external information content: 1. Lack of authenticity of information. Part of information ( especially in certain management information systems and on the Internet) may be of dubious character and in some cases even invalid; 2. Incomplete information. The source of information may deliberately or inadvertently present not the whole information, but just a proportion of it; 3. Contradictory information. Information from different sources may differ, and besides, it may be difficult to identify the real information content; 4. Redundancy of information. In order to increase the speed of information processing, some data have to duplicate, but this should occur in a minimal degree; 5. Heterogeneous information. Information from different sources arrives in a different format.
86
For unification of information in view of
long- term use, storage and
processing via a unified technology, information needs to be converted. To form and maintain information in an active state is not a simple task. It can be solved only on condition there are normally functioning information flows, that have been covered by a modern automated government information system.
Literature 1. E-Government Act, effective from 13.06.2008 ., Official Gazette, Is.46, 12 June 2007. 2. Kiskinov, V., Electronic government, SIBI, Sofia, 2003.
Internet sources 1. http://www.bg-pravo.com/2009/11/32.html (18.11.2013)
Self-study questions 1. What is the nature of the administrative process? 2. What is the nature of the electronic execution of administrative processes? 3. Which are the criteria for transparency in administrative processes? 4. What are the forms of control to provide electronic documentation? 5. What kind of organizational actions should be taken to transform administrative processes? 6. What are the objectives when amending the legislative initiative? 7. What is the purpose of the administrative re-engineering? 8. What are the forms of administrative re-engineering? 9. What is the purpose of building a unified communication structure of the administrative process? 10. What are the stages of the information process?
87
Chapter 6. ADMINISTRATING AN ELECTRONIC GOVERNMENT WEBSITE 6.1. Institutional site Abilities of Internet technologies find an ever larger application in the public administration work. It is exactly for this reason that the number of institutional sites is growing and more and more state and municipal sectors are orientated to this type of websites. An institutional site differs from the business website mostly in that it has several areas of application aimed at different target groups. Typically an institutional site consists of three such areas (zones): available to the public, internal and administartaing. The zone available to the public is designed to serve all Internet users and in particular citizens and organizations who require services from the public administration. The basic difference between this zone and and similar zones in other kind of sites consists in its purpose. Whereas in other sites (especially in electronic shops) the aim is to maximally retain the client’s attention, so that he/she orders goods, the idea of an institutional site is to maximally quickly serve the respective citizen or representative of an organization. Thus the user is satisfied with the service and, on the other hand less traffic takes place, which allows for the number of users served to grow. The internal area is aimed at the civil servants and specialists who can only use it with passwords. In this area the results are prepared for services about which decisions must be made by state and municipal specialists. Usually such decisions are made when events and circumstances occur for which the relevant legislative and regulatory measures have not been envisaged. Often such events also affect the document turnover in several administrative sectors, which sometimes calls for the direct participation of administrative specialists in the preparation of the respective decisions. Therefore this zone is only accessible by means of passwords, but, on the other hand, a possibility is provided to citizens and representatives of organization to trace the movement of their requests through administrative sectors and how the request has been executed.
88
The administrating area is at the disposal of IT specialists called website administrators. An administrator ensures the maintenance and testing of site, as well as its SEO optimization (Search Engine Optimization – optimization for search engines). Apart from that, the administrator selects key words, announces (promotes) the new services and facilities of the site, maintains the news section, etc. In many cases administrating guarantees the normal functioning of the site. After the official start of the website the administrator analyses the site’s behaviour. He/she identifies a possibility for standardization and universalization of the user interface, suggests variants for improving the design, maintains and, if necessary, changes the communication plan of the site, etc. An administrator is a highly-organized specialist with a wide range of knowledge in various spheres of human life. Under certain circumstances it is the site administrator that the execution of a particular service depends on, even if there are programming inaccuracies. He/she ensures the normal work of the site and feedback from developers. Should there be a potential for improving the site, the admin informs the stakeholders. The correctly developed site allows the addition of more fragments and services, if necessary. This leads to expanding the site structure and to an increase in its capacity. Several aims are pursued in creating an institutional site. The first one is to provide information for the administrative unit in the Internet space, so that it is accessible to the public and organizations. In this the institutional site does not differ from typical sites. The second aim is to create low-cost and effective routines, i.e. automatic procedures (for instance, the drawing up of a document that does not require special decision-making). This also holds true for internal administrative messages, document flow and a number of reporting forms that can be implemented via Web interface. This is particularlyly effective if the administration has several branches in different regions. The third aim is to provide service results via the Internet, without a document, and in case of need (for example, the current status of a given organization is established should the interested party needs it, without being necessary to issue the respective document). For this purpose a special area is created in the site, with the
89
necessary functions for access and confirmation, but without it being necessary to apply the respective documents. Creating an institutional site takes a gert deal of intensive preparation and routine while it is being realized. Usually few ready elements can be borrowed for the universal preparation of the site. Therefore, as a rule, developing an institutional site for the purposes of the electronic government in Bulgaria has to be commissioned either to a team that is highly-qualified in the field of electronic government, or to be granted (as well as the overall project for building an electronic government) to a Web company of international reputation and experience in this respect. This fully justifies the costs (see Estonia, Colombia and other countries), since the creation and development of the site, as is the case with the entire project, demands that many factors are envisaged, such as the peculiarities of the services, the audience, the style of work of administrative specialists, etc. Besides, the guideline for expanding the site’s capacity is of particular importance. Thus, in order for these issues to be successfully resolved, we really need a Web company with a team of professionals. It should be a team that could ensure not so much the normal functioning of such a complicated project, but rather envisage, as early as at the developing stage, the possibilities for its further development. Practically all organs of state authority also maintain departmental sites on the Internet and publish general information about their activities. Within the framework of the implementation of administrative reform, there are described functions and processes of the state governance and the local government, individual projects are realized for reorganization and optimization of administrative processes in individual departments. Along with that, so far the results from the implementation of the information-and-communication technologies in the state authority bodies are of predominantly intradepartmental character. This, in turn, does not allow for the expansion of inter-departmental interaction and a higher quality of the administrative services provided to citizens and organizations. Many of the national authorities do not have complex programs for implementation of information and communication technologies or programs for improving their work. This nearly always leads to unforeseen expenses. A major part of budget costs are incurred by the purchase and 90
installation of computer and network equipment. This, in general, testifies of an inadeuate level of development and use of applied information systems. The conclusion to be made is that it is the technological approach that dominates in the solutions to informatization systems. The single, unified portal of institutional websites providing interaction with the organs of state authority with their institutions, as well as with organizations and citizens within the framework of provided administrative services is still at the stage of initial formation. The level of professional training of specialists from the organs of local and state authorities in the field of modern information and communication technologies is not high enough. This level is crucial for the implementation of ever more sophisticated and complex solutions in the w rk of public administration. The occurring situation does not allow for the provision of a new quality level of state governance and services to the public and organizations on the basis of modern information and communication technologies. The effectiveness of the budget spending on the development of a national information system has dropped considerably. The building of an electronic government requires the implementation of coordinated organizational and technological activities and a coherent approach on the part of local and state authority bodies within the framework of a unified state policy. 6.2. Unified portal – the “one stop” principle The “one stop” principle is applied in building a unified information system for citizens and organizations being served by public administration. This unified system is part of the complex system for provision of administrative services (by using multifunctional centers in the Internet space). The unified system, constructed to provide administrative services, has to ensure a working mechanism for informing and organizing information service stations for citizens and organizations. The service stations for providing administrative services have to guarantee remote access to information on the results of the executed services to citizens and organizations. Access to administrative services information is organized (within the general system of provision of administrative services) on the basis of a unified portal for administrative services (info-stand/ telephone/ mobile technology). The unified system 91
provides processing of citizens’and organizations’ queries and requests, search and defining the corresponding administrative body to provide the service result or detailed information about the service. The system provides information to the applicant in real time mode with the help of information and communication devices. The unified system informing citizens and organizations about the work of tadministrative bodies must be integrated with the internal systems that serve the state government bodies. Along with it, the system also serves the multifunctional centres for providing administrative services, as well as the register of administrative services. Such a constructive organization, built on the “one stop” principle, allows for the setting in motion of different channels for informing citizens and organizations, no matter where the administrative service is requested ( from a state authority or from a multifunctional centre). The unified system following the “one stop” principle functions on the basis of the following elements:
channels for information:
-
a portal for administrative services;
-
national and regional centers for telephone service;
-
information kiosks (informats );
-
tools for mobile information;
information-providing elements:
-
a register of administrative services;
-
for the bodies of authority;
-
information system of multifunctional centres.
On fig. 6.1. is presented a model of a system for serving citizens and organizations, based on the register of administrative services. The register contains comprehensive information about all administrative services provided by the organs of state authority.
92
Fig. 6.1. A unified system for serving citizens and organizations One of the most important components of the register of administrative services is the classification system. Through this system information is classified according a specification (passport) of the state and municipal services. The specification is a standardized form that contains complete information on administrative services: general information, the order to obtain information, appeals, as well as reference to the normative and legal regulation of services. The search of information from the specification of administrative services is carried out by means of service classifier. The classifier is applied in order to systematize services into sections and groups, and in itself it is an orderly informational array of services by the corresponding attributes (for example by social status, by types of directions, by the degree of national importance and other). For the correct function of the unified system the respective tools are needed, which directly participate in the process of providing public services to citizens and organizations. Together with the tools, corresponding mechanisms are necessary to ensure the functioning of a particular tool within the unified system. The unified system for electronic service of citizens and organizations provides access to information about the work of the bodies of authority by means of various 93
technological solutions on the “one stop”principle: a unified portal for public services, a call center, information stands, devices for mobile service. Irrespective of the many possible means of service, the basis channel is the unified portal for public services. The portal provides information interaction with other tools and mostly with the information systems of the organs of state authority and the multi-functional centers. Now practically every ministry, sector and agency has its own information portal, on which they partially display general and reference information about the services they provide. The available information makes it impossible, or at least highly inefficient, to search and provide methodology, terms and conditions for citizens and organizations to get public services. Therefore, it is necessary to provide the following functional abilities for the unified portal for public services:
publishing detailed information about the mode for receiving public
services – including the regulations for their provision, the category of the recipient,entitled to this service, argumentation for rejection, requirements about the set of documents, samples and electronic forms of documents;
publishing personalized information about the course of services that are
being provided, or consultation through the organs of state authority or a multifunctional center,whereby the rights to access to information are differentiated and a personal user account is organized. Requirements regarding the user interface of the unified portal for public services:
it should include general information on national and municipal services
with taking into consideration the normative acts/enactments that provision of services to the public is based on, description of the mode of service provision and the categories of services provided, information on the bodies of authority that provide the services;
detailed information on the order of getting national and municipal
services from the bodies of state authority and the multifunctional centers. The essence of a unified portal is to enable the user to quickly and conveniently find information about the services provided. Therefore, the unified portal for public 94
services should provide the facilities for integration of the authorities’information systems. In the process of integration, systems participating in the provided service can be activated by a multifunctional center (built according to the “one stop” principle), regardless of the place of residence, region or state where the requester is located. Owing to integration, the unified portal exchanges information with the administrative systems providing public services, and along with that, the portal ensures functional control and monitoring in the course of service provision. In the end the portal provides the necessary reporting data about the service provided. On fig. 6.2. there is presented a scheme of servicing through a unified portal for public services.
Fig. 6.2. A system for providing public services Another component of the unified system for providing public services is the Call Center. This center provides reception and processing of incoming telephone requests by citizens and organizations. The call center provides general reference information on the possible state and municipal services. Requests are received in the center over a single national telephone number in cases when citizens refer to the national bodies of executive power. If necessary, the same request (by means of its 95
single registration number) is sent to the regional service division. The Call Center has to provide:
reception and processing of telephone requests by citizens and
organizations on question referring to the public services provided;
general information on public services to citizens and organizations;
reference information on the time and place where citizens can be
received in person – the person in charge of citizens relations is a specialist in the conditions and mode of providing public services;
switching over to another department call center, should the call refer to
its sphere of competences;
informing the applicant of his/her rights and of the order of filing a
complaint against an officer’s action or inaction;
information for the applicant/ requester on the service status and results.
To ensure the organizational and functional efficiency of the call center, unified requirements must be developed. In these requirements there have to be defined the necessary conditions for providing information via the telephone, the order of interaction with citizens, as well as the technological parameters for the functioning of the said center. From the execution of the operators’ function (by the call center) concerning information and reference support one achieves shorter response time for the applicant, higher degree of credibility and the up-to-date character of information, the operator’s access to the necessary informationand reference resources, all through the unified portal for public services and following the “one stop”principle. Regardless of the call center and the unified portal for public services, the unified system for electronic service has to have a channel of information in the form of information stand (infomat, kiosk, counter). Sensor kiosks perform the role of “an electronic helper” of the human. They can be applied in various fields, including for payment transactions. The simplest and most frequently performed task for the sensor kiosks, however, is providing information. In their quality of being an information terminal, sensor kiosks are used in libraries, museums, exhibitions, railway stations, airports and other public spaces. Sensor kiosks make information available to a wide range of users. A large number of interactive sensor kiosks combine several types of 96
functions . Apart from the information provided, they enable the user to avail him/herself of various services (service stations). Installed in the sectors of executive power, information stands provide reference information, information on the department activity, working behaviour and visitor reception, as well as various interactive services ( payments, opening / closing batch accounts, updating a status and other). Service via mobile devices (technologies) is a promising and progressively developing means of electronic service of citizens and organizations, of the work of public administration organs and other. At present, however, the said instruments are very poorly presented in the public sector of Bulgaria. This is a consequence of a number of legislative issues and problems in information provision (lack of normative regulations for electronic identification of citizens, no mobile service schemes and other). Mobile service devices allow for receiving information on the course of service provision process. Via mobile telecommunication messages are sent about ongoing stages, decisions and results of service provision. In the end, the corresponding requirements are formed for the unified electronic system for servicing citizens and organizations. Information contained in the system should cover:
general information on services provided by the state authority bodies;
information on the service provision mode;
information on the legal coverage of the service provision process;
information on the appeal process against the action ( inaction) of state
authority employees engaged in service provision;
information on the process of informing and consulting citizens and
organizations on matters concerning the services provided. Requirements towards the system functionalities:
The system should be integrated with the internal systems of state
authority bodies and those of the multifunctional centers;
The system should be integrated via the unified portal for public services,
based on the public service register;
The system should be nationally and regionally scalable; 97
The system should be used not only in the places where services are
provided by the organs of state authority and the multi-functional centers, but also in centres where a large number of people are centred, interested in getting information regarding authorities (airports, bus stations, railway stations, etc) As a technological platform the unified system for electronic service of citizens and organizations by the pblic administration, the system should be based on a single portal technology. By providing access to information about public services, the system provides interrelation for all channels of the state authority system and those of the local government.
Literature 1. Civil Servants Act, effective from 27.08.1999 ., Official Gazette, Is. 67, 27 July 1999. 2. E-Government Act, effective from 13.06.2008 ., Official Gazette, Is.46, 12 June 2007. 3. Holms, D., E-government strategies, Klasika i stil, Sofia, 2002. 4. Kiskinov, V., Electronic government, SIBI, Sofia, 2003. 5. http://psc.egov.bg/documents/10180/21521/Obshta_Strategia_eGovernment _2011_2015.pdf
Internet sources 1. http://www.mtitc.government.bg/upload/docs/E_GOV_Conception_for_ publishing__2_.pdf (18.11.2013)
Self-study questions 1. What would be a very specific characteristic of an institutional site compared to other sites? 2. What are the main components of the institutional site? 3. What is the purpose of institutional site? 98
4. How to raise the professional level of specialists from local and state government in the area of information technology? 5. What are the advantages of a single e-government portal? 6. What integration processes are observed in the single electronic control system? 7. What are the elements that provide the “one stop” principle? 8. What is the content side of the register of administrative services? 9. What is provided through a single portal for public services? 10. What are the functionalities of a single portal for public services?
99
Chapter 7. E-DOCUMENT MANAGEMENT 7.1. Structure and elements of an e- Document In today’s society, where information and communication technologies prevail, electroning docyments are gaining importance. Electronic documents are designed to considerably ease work with documents: there is no paper bureaucracy, search of documents is considerably simplified due to the use of electronic databases. In addition, an electronic document has a number of advantages compared to the paper one. For instance, an environmental advantage is the possibility to make changes in the text of the document without wasting paper. In the past work with paper documents took a lot of time and labour costs because of the need for hand typing the whole document even if the most insignificant changes had been made. Under the Electronic Document and Electronic Signature Act (publ.in State Gazette issue 34 of 6 April 2001) the electronic document is documented information presented in an electronic form, i.e. in a form that is convenient to be perceived by a human using information and communication technology, as well as for this document transmission in a network environment or processing and storage by information systems. An electronic document can be defined as a form for preparation, sending, receiving and storing information with the help of coputer devices and the corresponding storage medium. This is information that is objectified in the form of a number of symbols, known in computer technologies as basic elements (bits and bytes) for processing, storage and transmitting information. Information in the electronic document contains attributes for identification and can be converted into a form that is convenient for human perception. Some of the typical characteristics of electronic documents are the following: -
It is impossible for a human to directly perceive the electronic document
in the physical form it is fixed on the technical carrying device. -
The electronic document is related to the technologies that generated it
and is used by means of the corresponding hardware and software, standard and for of data presentation, etc. The technologies involved in creating the electronic document
evolve and improve at an exceptionally high speed. There are huge problems when obsolete data have to be read lacking the relevant equipment or software; -
Electronic docuents have their own physical and logical structure. Unlike
paper documents, where form and content are visualized, the individual elements of an electronic document are stored in a database and only after a processing query can data assume their traditional appearance; -
Unlike the paper document, the electronic one is not closely tied up to
the information carrier. Information can be easily altered and even destroyed without a trace remaining on the carrier. Certain documents are only realized in the RAM computer memory; -
Electronic documents are distinguished by the possibility for unlimited
reproduction of the original. This, however, in some cases evokes controversy about verifying the authenticity and legal force of the electronic document; -
The electronic document needs to be protected agains unauthorized
access; -
There are still specific rules for confirmation and maintenance/support of
the electronic document, such as creating accompanying documentation; Both paper and electronic documents have advantages and disadvantages, that can be summarised in the following aspects:
Time for transferring the document – undoubtedly, electronic
documents have an undeniable advantage in this aspect, as electronic communication channels allow transmitting messages for an incredibly short time;
Reference and information work (searching information in the
information pool by document content and attribute) – with lack of information and optimal scheme of document classification, for paper documents this procedure may be too labour consuming. With electronic documents minimal time is spent, due to address links that allow the locating of not only a certain document, but also other thematically or functionally connected documents;
Requirements for document layout – paper docuents have a unified
form and meet certain standards. Sometimes certain changes in layout are possible, provided they do not affect certain statutory requisites, particularly those determining 101
the legal force of the document. So far, the layout of electronic documents has not been standardized. Yet reuirements concerning their layout can be more serious than those of the paper ones. For instance, during the transferring of information along the communication channels of different computer systems (for example, mobile ones) and different software. Transferring may be prevented or information may not be accessible to human perception;
Legal confirmation of the document – for paper documents practically
all problems with their legal force have been solved. For electronic documents of particular importance is the Electronic Document and Electronic Signature Act, which provides the legal conditions for using the electronic digital signature like for instance: o
duration of the certificate of the key referring to the electronic signature;
o
electronic signature confirms document authenticity;
o
using electronic signature in activities of legal significance.
When the defined conditions are observed, the electronic signature is equivalent to a handwritten signature on a paper-based document. For correct implementation of the law, specialized certifying centers are created for issuing certficates (keys) for electronic digital signatures;
Convenient perception of information – this quality is more apparent
in paper documents. Regarding information perception electronic documents can be compared to long medieval scrolls – going over the file sometimes makes one’s eyesight blur. Text on a computer screen(monitor) is perceived slower ( by 25%) than when the same text was read on a sheet of paper; Worldwide a major part of information resource is concentrated in documentation. In the present stage prerequisites are already achieved for conversion to new methods of working with documents – systems for electronic document turnover.Regardless of the problems ( legislation, verification, long-term document storage, implementation) the electronic document has a number of advantages over the traditional ones ( increased productivity of administration, instant access to information, quick location of the document and many other). Nevertheless, the present stage of our development belongs to complex systems using both paper and electronic source documents. 102
7.2. Electronic digital signature The European Union created Directive № 93 in 1999, whose purpose is the legal recognition of the electronic signature. Similar laws are in force in Germany, Italy, India, some states in the USA and other countries. Analysis of national and international legislation testifies of the availability of various approaches to regulation of usage of electronic signatures. Differences are identified mainly in using electronic signatures( for instance in public administration, banking transactions, between organizations and other). As a term in the Electronic Document and Electronic Signature Act, electronic signature (electronic key) is defined asinformation in electronic form, that is added to other information in electronic form ( signed information) or otherwise connected to such information,which is used by certain persons,signing the information. The electronic signature is information that connects two objects (subjects): the signed document and the person signing it. The certificate for the electronic key for verification of the electronic signature is issued by an accredited center or a fiduciary of such a center, which have been authorized to issue and control electronic digital signatures. According to informatization of the electronic business, a pressing issue is that of the legislative rights that will considerably expand the field of application of electronic signature and enable a legally meaningful electronic document flow. In relation to this and many other circumstances, an amendment was made in the Electronic Document and Electronic Signature Act, which came into force on1 July, 2011. The electronic signature as a requisite of the electronic docuent is designed to protect a certain document from corrections (forgeries), by means of cryptographic conversion of information by using a qualified electronic signature, which allows for the identification of the signature’s owner and establishing complete lack of inaccuracies (distortion) of the information in the electronic document. Asymmetric cartography is used for signing electronic information. The algorithm of asymmetric cryptography enable s the encryption of information, using two keys one for encrypting the message and the other – for decryption. The most 103
protected kind of electronic signature is believed to be the new qualified electronic signature that was introduced under the new law of 1 July 2012. In order to clarify the need for a new electronic signature and what has been changed with ithe law’s amendment, a brief historical review is necessary in relation to cryptography, i.e. the program designed to encrypt and assign electronic message. Initially national special services were very sceptical about the possibility for software crypting. Software crypting creates a number of annoying inconveniences for special services, because it is created by independent developers, and, moreover, because it is impossible to decode the message without knowing the key. This means serious difficulties for the special services when they want to read what users communicate about. Troubles with cryptography started as soon as it appeared. In the early 1990s, programmer Philip Zimmermann created the program PGP (Pretty Good Privacy), which is still the most widely used in the field. The program allows to sign files and messages and also to encrypt them. For signatures and encryptions two keys are used private and public. Usres freely exchange the public key but the private one remains a secret. Message encryption uses a combination of the addressee’s public key and the private key of the letter writer. The opposite is necessary for decryption – a private key for the addressee and a public one for the letter writer. By means of such a scheme encrypted messages are exchanged, without any danger of intercepting the decryption key, as long as two keys are used (at least one of them must be guarded). This security of public key encryption (asymmetric encryption) is widely popular on the Internet. Very soon after he created PGP a criminal investigation started against Zzimmermann for breaking the ban on export of US encryption software. But the law suit was cancelled only three years later. All charges against Zimmermann were dropped. Soon after that Philip Zimmermann set up his company PGP inc., where he went on developing the program. The ban onexporting the program was easily overlooked. Only an electronic copy of the program in its Source kind is made available. Afterwards the overseas version of PGP, which was brought out of the USA as print out, was compiled form a scanned copy of the text. These are, of course, exotic details, but the fact is other governments also treat cryptographic software very severely in a legal aspect. A number of countries simply forbid the use of any 104
cryptographic tools if these are not certified by a state authority. Besides the ban encompasses not only state-owned organizations which develop or import such programs but everybody! On the other hand, however, no criminal liability is envisaged for breaking the ban and, consequently, many people break it. Hence the proliferation of encryption technology. This applies even to programs delivered with the Windows family of operating systems, as well as to PGP itself, which has practically become a standard in the field. That is why in the end of 2001 the first Electronic Document and Electronic Signature Act was passed. In its early period the law applied only to legal relationships occurring when civil law transactions are performed. In accordance with this law, the instruments for creating a complete digital signature must have a certificate. All the remaining cryptographic programs immediately assume an incomprehensible status. From a theoretical point, it is possible to sign documents with them, the law does not forbid that. But the legal status of such documents is not regulated. Therefore, for issuing electronic keys the law envisages the creation of a network of digital certification centres which should certify keys upon request by users. As it was mentioned before, a signature based on asymmetric encryption demands two keys – a public one, which the holder can freely exchange, and a private key which must be kept secret. The private key should not be known to any one, but under the law this key is generated by a certification center, i.e. by total strangers. The law requires from these centres to ardently protect the secret of the key, but, on the other hand, common sense suggests this key should not be trusted to anyone ( a case!). Under the new law electronic keys are qualified, match the private key and also issued by certified service provider. The order of issuing these keys is consistent with the previous rules – the provider also issues electronic signatures for the client by using a certified program – provider’s own state certification and renders the signature “qualified”. The keys issued while the old law was in force, can be used in a futher period. Under the new law these keys they have the validity of a qualified signature. Under the new law certification centres issue an electronic signature certificate, which enables the creation of a private (qualified) key and a public key for verification of the applicant’s electronic signature. Oviously, under the new conditions the 105
certification centre only issues the certificate and the electronic key is generated by the user him/herself, in case of need. So, it is no longer necessary for the user to trust the certified service provider. Under the new law electronic signature can already be used not only by individuals, but organizations, legal entities and state authorites also can possess one. The electronic government suggests the creation of a nationwide distributed system of public administration, which implements decisions about the entire spectre of tasks related to document management and the processes of their ciphering. Thus work under the conditions of the electronic government is wholly based on the electronic signature. If that is missing, full authorization is impossible. In addition, it is with the help of electronic signature that the document verification takes place.In a certain aspect, the government makes it compulsory for legal entities to prepare reports electronically, to make purchases, implement docuent turnover systems in their internal work. What is more, the government calls for interdepartmental electronic interaction. On the other hand, the government provides services to citizens and businesses electronically and in these processes the electronic signature is already necessary. So the prospects are relatively wide for the use of electronic signature. By adopting the concept of electronic government in the Republic of Bulgaria in March 2010 there is envisaged a gradual restructuring of all systems of interdepartment electronic interaction. It should unite the efforts of public administration in Bulgaria and convert administrative services into a single nationwide electronic forma by means of the Internet. Unification begins of heterogeneous department information systems into a unified portal (www.egov.bg). For example the system of the National Revenue Agency and that of the National Insurance Institute have united as structures, as well. The important thing is that at present citizens and representatives of organization do not seek service result from office to office, they now address a unified portal of the national or local government. In its present state the system, via the portal www.egov.bg allows for the realization of the “one stop”principle. The electronic digital signature may be applied by legal entity and individuals for submitting income tax returns electronically, receiving the necessary references, 106
submitting reports to NRA and NII, replies to questions from state authorities and organizations, participation in competitions at national or local level, regardless of where these competitions are held and where the participant lives. The electronic signature is also applied for identification in systems of authorized access to banking institutions. It is used in some information systems for electronic notary services in corporate deals. Applying an electronic digital signature is a real technology, accessible and necessary to a considerable number of people. An understanding seems to be formed that using electronic signature may substantially alleviate the exchange and storage of documents. Already an electronic signature can be applied in all spheres of B2B, G2B, as well as in G2C processes. This in turn actively facilitates the development of the electronic government services and its “front office” – a portal for automated services (without the participation of an administrative officer). Several project feature in the agenda of the electronic government, such as a citizen a single ID card (Estonia, Colombia and other) which inites bank cards with electronic signature. Initially, the availability of individual PIN cards was strategically important, but at present it can begin creating only inconvenience. For this reason, in Bulgaria already serious opportunities are sought for the electronic signature to be universally applied, which for years has been a routine in other countries.
Literature 1. E-Government Act, 13.06.2008 ., Official Gazette, Is. 46, 12 June 2007. 2. Kiskinov, V., Electronic government, SIBI, Sofia, 2003. 3. Law on Electronic Document and Electronic Signature, effective from 06.10.2001 ., Is. 34,
6 Apr. 2001.
4. Maneva, N., Eskenasi, A., Software technology, Anubis, 2001.
Internet sources 1. http://lex.bg/laws/ldoc/2135180800
107
Self-study questions 1. Name the advantages of an e-document. 2. What is the structure of an e-document? 3. What are the specifics of an e-document? 4. What are the required conditions for the transition to electronic document systems? 5. What is the electronic signature certificate for? 6. Why is the principle of asymmetric cryptography used for signing electronic data? 7. Why are two keys used for signing an electronic document? 8. Which elements of the electronic signature are issued by certification services authorities? 9. Who is allowed to use contemporary electronic digital signing? 10. What is the role of the single ID card?
108
PART B. SOFTWARE DEVELOPMENT MANAGEMENT
Author: Chief Assist. Prof. PhD Olga Marinova
Chapter 1. MAIN CONCEPTS, SOFTWARE PROPERTIES, SOFTWARE ENGINEERING 1.1. Programmes and software products In order to give the most detailed introduction to the nature of programmes and programming products, we should take a look at the history of their origin and development. 1.1.1. History The emergence of the first computers during the 1940s resulted in the development of the first programmes for them. They were primarily designed for military purposes. There have been attempts for using computers for supporting scientific research, primarily for calculations. Before the end of the 1950s, the banks found out that their operations could be significantly simplified and supported by greater precision, if they used computers. Today, banks are still among the major consumers of computer and programme resources. Computers have gradually become part of a wide range of activities, such as trade, medicine, airlines operations and many others. This, on the other hand, is associated with the emergence of different programmes for the different scopes of application. Computers, however, remain the main frame or they are produced with certain variations upwards (supercomputers) or downwards (mini computers). The main users are still only well-trained specialists in the respective field of application, which also influences the software properties - there are no major achievements with respect to the ease of use and the interface. At the end of 1968, the IBM company, which was the largest manufacturer of hardware and software on a global scale at that time, introduced the so-called unbundling policy. This meant that the software that used to be provided free of charge together with the hardware, gradually became paid. Actually, this turned out to be the impetus for development of the software industry. During the 1970s, software development already had its own market and
enterprises to produce it, i.e. it started to become a separate industry. Personal computers emerged in the 1980s, followed by the global communication devices in the 1990s. This resulted in a sharp increase in the range of users, who became increasingly diverse with respect to education level, qualification, age, interests, etc. Today, the application of computers and software has permeated almost all spheres of life: cars, telephones, electrical devices, robots in different industries, lifesupport systems and business applications. Gartner estimates a 5.5% growth of the business software market in 2015, with global revenues of approximately USD 335 bn75. Regarding the hardware and software market, some additional development trends can be identified: In 2015, 20% of the companies from the Global 500 ranking that are not IT companies will become suppliers of "cloud" services76. In 2014, 90% of the organisations will support corporate applications for mobile devices. In 2015, 10% of your "online friends" actually will not be human beings. Many organisations have already established their presence. They communicate their messages via Twitter, update their Facebook pages and use RSS. In 2015, the efforts for systematisation and automation of social presence will result in the establishment of social bots – programme agents that are capable (within certain limits) of playing the role of people's companions77. The prices of hardware will continue to decline as a result of the continuous rapid and sometimes revolutionary IT development. The software industry will continue to be among the most profitable industries, because it is one of the few sectors where a unit of product can be sold at a price that is 100 or even 1000 times higher than the actual cost. 75
Gartner Says Worldwide IT Spending on Pace to Grow 2.4 Percent in 2015, http://www.gartner.com/newsroom/id/2959717 76 Gartner Reveals Top Predictions for IT Organizations and Users for 2011 and Beyond, http://www.gartner.com/newsroom/id/1480514. 77 Gartner Reveals Top Predictions for IT Organizations and Users for 2011 and Beyond, http://www.gartner.com/newsroom/id/1480514. 111
Periodic upgrade – companies provide new versions of the products they offer in order to integrate different innovations. In order to justify their periodic upgrades, companies create products that provide higher processor capacity, higher graphic productivity, more memory, etc. 1.1.2. Problems The brief history of the programmes development during the past 60 years discussed in the first section could easily be used for identifying some of their basic properties: each programme should offer the possibility to be corrected, extended, improved by its author or by another person; at first, it was not very clear whether the programme would be used by other people, different from its author; today, of course, there is no room for such a question; this, however, means that one of the main requirements to modern programmes should be the possibility for portability of the programmes. Since programmes are the product of production and commercial operations, there should be possibilities for them to be evaluated before being sold. Based on the discussed properties, we could summarise that there are two main requirements toward the programme: it should be recordable on some technical device and it should be accompanied by the necessary documents describing its different aspects. 1.1.3. Definitions Programme - a sequence of instructions, which, after being decoded by a computer, lead to the resolution of a given task by the computer78. The programming product is a programme or a group of interacting programmes written on a technical device and accompanied by the relevant documentation. According to the professional American Institute of Electrical and Electronics Engineers - IEEE (IEEE 1993) the term software includes:
78
Eskenazi, A., Maneva, N. Software engineering. KLMN, Sofia, 2006. 112
instructions (computer programmes), which provide the desired properties, functionality and productivity when they are used; data structures that enable programmes to adequately process information; documents describing the programmes operation and use. The software designed for sale (to customers / users) is called a product. Two main types of software products are identified: generic products – individual products/systems designed for each user who is willing and capable of buying them (e.g. DBMS, document processing systems, software development environments, etc.); customised products – ordered by a certain customer and developed based on the customer's requirements (e.g. systems servicing particular business processes; resource planning systems, etc.). It should be noted that the terms software product, programme product, software, software application and software solution will be considered equivalent in meaning and interchangeable in this report. 1.2. Properties of software Before discussing the nature of software engineering, we should clarify some of the basic properties of the software, which largely determine the specifics of its development. Required resources. Software products, unlike many other products, are distinguished by the resources input in them, which predetermines their price. The software development process is different from the process of production of hardware or other tangible objects. Software does not depreciate, it is maintained in a different way. Abstraction of software. Software is a logical, not a physical unit - it cannot be touched or seen. The commands written in a programme can be seen, however, the logical nature of the programme, particularly if it is a large one, cannot be "seen". The overall structure of a set of programmes is even more difficult "to see". This is why it is maintained that software constitutes a very high level of abstraction. Uniqueness of software development. The main efforts for development of a 113
certain software product take place before the emergence of the first working copy of the product. If there is a bug in a software product, it is present in all its copies. By contrast, this is rarely the case with notebooks, or at least it is not so common - defects are usually individual and pertain to each specific notebook or emerge after a certain period of operation. When the software product becomes obsolete, this is often the result of one and the same reason – the emergence of a new version with new features added which, above all, correspond to the changed hardware. For other products, like computers or cars, their "end of life" is the result of individual features and the life cycle of each product copy is different (depending on the way of use, maintenance or different failures). Multidisciplinarity of software development. Save for the specific instruments, OS and some specific types of software, which are developed solely by software engineers, a software product could not be created by programmers alone. An expert in the field of application for which the software is developed should also contribute to the development. Sometimes it is even necessary to combine the efforts of different groups of specialists. Communication problems are common for this type of cooperation, resulting primarily from the specialists' different way of thinking and the different professional jargons they use. Specific reliability issues. According to a 2012 research, software bugs and the necessary time to fix them cost approximately 50% of the programming time to software developers, which equals USD 312 bn for costs for bugs per year on a global scale79. No software product can be guaranteed to be absolutely bug-free. The main reasons for this are: ‒ too many possible routes through the programme; ‒ large eligible (and ineligible) data sets; ‒ unforeseen actions by the user. Therefore, even if the developer has a lot of time, money or other resources, they are unable to prove that their software product is absolutely bug-free. The
79
Software bugs cost more than double Eurozone bailout, http://www.businessweekly.co.uk/hi-tech/14898software-bugs-cost-more-than-double-eurozone-bailout. 114
technologies that reduce the time for debugging, such as reversible debuggers, can potentially have significant influence on the global economy with respect to correcting the reasons for the occurrence of bugs. Nevertheless, we constantly observe software products that are developed and sold in millions of copies by global companies, which have bugs or freeze at some point. On the other hand, if it is somehow proven for a given programme that it does not make any errors under certain conditions, then it is clear that none of the copies of this programme will ever make an error, if it is used under these conditions. Risks. The risk of failure or even project failure is very common for software development. The main reasons are usually related to: - unfulfilled requirements; - missed deadline for delivery (experience is of key importance here) - 90% of the software product is completed for a certain period of time; it turns out, however, that in the best case, the same amount of time is needed for the remaining 10% (the “90% syndrome”); - budget overspending or suspension of the project because of lack of funding. Software is a means, not an end. Software is a means that activates (operates) a certain system and it is the system that yields the desired result. For instance, the user wants to receive a document in a certain form with a certain content, which happens by using a computer, activated by a word processing programme. In this case, the document is the first level target. The computer is the means for achieving the result and therefore it is at the second level. The word processing programme is the third level. Software specialists should always remember that what they create is actually just a means to a certain end. Level of performance. Software development is one of the fields exhibiting some of the greatest differences in the performance of individual specialists of the same type, especially from one programmer to another. According to a research 80 carried out by M. A. Cusumano, the ratio between the software developed in Ireland and India was approximately 38 to 1 in 2004. 80
Cusumano, M. A. Software in Ireland, Communications of ACM, Oct. 2005 / Vol.48, No 10, p. 25-27. 115
1.3. Software engineering 1.3.1. Terminology The term “Software engineering” was first used during a NATO conference in 1969. The conference was held for the purpose of discussing the problem with the "software crisis" that was common at that time. The so-called third-generation computers emerged several years before that. Later, it turned out that one of the main problems for this period was the lack of clarity on the exact method for producing software of such high complexity and scale to meet the new computer capacities. Other problems noted in the report from 1969 were: - lack of understanding of the systems requirements by the users; - large disparity between the estimated costs and time and the actual costs and time spent, because of a lack of adequate estimation methods; - rapid growth in the volume of software systems; - programmers tend to write optimal and flawless programmes, neglecting the urgency of the users' practical needs; - rapidly growing demand for programmers and shortage of well-trained programmers with good practical skills; - poor communication between the different groups developing a project, exchange of unnecessary or poorly coordinated information; - difficulties in achieving sufficient reliability (no bugs) of large software systems; - accompanying costs that often outweigh the costs incurred for the development of the software system. Based on the problems and findings identified, it became naturally necessary to have a special discipline in an attempt to help overcome the software crisis. 1.3.2. Definitions In 1969, Naur defined the term "Software engineering" as follows: The establishment and use of sound engineering principles of development in order to obtain economically software that is reliable and works effectively on real machines.
116
According to the definition of IEEE (Institute of Electrical and Electronics Engineers), software engineering constitute of the application of a systematic approach to the development, operation, maintenance and decommissioning of the software. In 1984, Fairly formulated his definition as follows: a technological and managerial discipline dealing systematically with the development and support of software products developed in a timely manner and based on specific costs. Fairly’s definition is closer to the modern understanding of the nature of software engineering. A necessary addition to "software" is the adjective "highquality". The huge level of commercial distribution of software products and their marketing also constitute a significant feature. On the one hand, decommissioning is not such an important element as compared to the other elements and therefore it may not be present in the definition. Therefore, the definition we have chosen to adhere to, will be as follows: Software engineering is a systematic approach to the development of highquality software and to its marketing, operation and maintenance. 1.3.3. Objectives Based on the condition about quality added to the definition above, it is necessary to define the main attributes of a high-quality software. Each software product should be: Easily supported - it should be relatively easy to import changes and enhancements in it and it should be easy to remove bugs; in order to make this possible, the software product needs to be well-documented. Reliable - the bugs should be minimised as far as possible and the product should fulfil the functions expected by the user. Effective - optimal utilisation of the computer resources, mainly with respect to the economic use of operational memory and achievement of rapid performance. Convenient and easy to learn user interface - this has become increasingly important because of the dramatic increase of the number of users and the expansion of their fields of specialisation. It is often the case that a large part of the product's functions remain unused by most users because of poorly designed or implemented 117
interface. This, on the other hand, results in decline in the number of sales. Price of the software product - the costs during the development, especially the costs incurred during the maintenance phase, should be minimised, as far as they are unexpectedly high (often in a ratio of 1 to 2). It is impossible to achieve the best rates for all attributes listed at the same time, since some of them are actually contradicting. Example: If the interface is too "user-friendly" (aesthetic, ergonomic, easy to understand, equipped with many help instructions, etc.), the effectiveness of the software product will most probably suffer from this. Additional problem - the cost of modification often does not grow in a linear pattern, i.e. some small improvements to a certain attribute may require substantial increase in the input resources and hence the price. The task of software engineering is to provide guidelines how to develop a software that has the characteristics discussed above in their optimal ratio. This was also the idea for overcoming the software crisis in 1969, which is the reason for the emergence of this discipline. Today, everyone believes that the software crisis has not been overcome yet. Substantial achievements have been made that have improved the methods and technologies of software development, as well as means that have made part of the development processes automated. It seems, however, that the requirements toward the software and its complexity rise at a much more rapid pace than the rate of improvement of software developers' performance. 1.3.4. The software process as part of software engineering Software engineering is a discipline integrating the process, methods and means81. The software process usually covers all activities related to the development and maintenance of a software, such as: analysis and identification of requirements; system design; 81
Ilieva, S., Lilov, Vl., Manova, I. Approaches and methods for development of software systems. "St. Kliment Ohridski", Sofia, 2010. 118
programme design; programme coding; different types of testing; delivery of the system; support / maintenance. The software methods define the "HOW" of the technical development of the software. They should include the following elements: descriptions of the individual models of the system; rules (e.g. to assign a unique name to each unit within the model); tips – they ensure that the model is well-organised; manual about the process – description of the activities and links (dependencies) between these activities within the model. The software tools provide automated or semi-automated maintenance of the methods. They could be both independent and integrated in a shared environment (platform). In the latter case, the information created through a certain tool can be used by another tool, i.e. there is a system that supports the development of the software in an integrated environment. The presence of a well-defined software process is an important basis for the successful development of a software application. The main objectives of the organisation with regard to the software process are: performance – the efficient process helps us to create the correct product with the necessary quality, i.e. it helps in the identification of the customer's needs, creation of an application based on these needs, establishment whether the developed product corresponds to the initial requirements; maintainability – a good process will allow applying the necessary modifications easily and at any time; predictability – a good process should help during the project planning and the identification of the individual steps; repeatability – if a process is successful, it would be good for us to be able to use it again in future projects (rather than defining a new one); quality – the process should ensure compliance of the product with the 119
expected properties it must have; improvement – the process capability to identify the possible areas for improvement or further possibilities for adaptation to the rapidly changing requirements and conditions; tracking – a certain defined process should allow tracking of the project status by developers, customers and managers.
References and Internet sources 1. Eskenazi, A., Maneva, N. Software engineering. KLMN, Sofia, 2006. 2. Ilieva, S., Lilov, Vl., Manova, I. Approaches and methods for development of software systems. "St. Kliment Ohridski", Sofia, 2010. 3. Cusumano, M. A. Software in Ireland, Communications of ACM, Oct. 2005 / Vol.48, No 10, p. 25-27. 4. Gartner Says Worldwide IT Spending on Pace to Grow 2.4 Percent in 2015, http://www.gartner.com/newsroom/id/2959717 5. Software
bugs
cost
more
than
double
Eurozone
bailout,
http://www.businessweekly.co.uk/hi-tech/14898-software-bugs-cost-more-thandouble-eurozone-bailout. 6. Gartner Reveals Top Predictions for IT Organizations and Users for 2011 and Beyond, http://www.gartner.com/newsroom/id/1480514.
Self-study questions 1. What is the definition of software? 2. What are the main characteristics of software? 3. Why do we say that software is characterized by specific reliability issues? 4. Are the software attributes described in section 1.3.3 applied to web applications? 5. What are the main activities that software process usually covers?
120
Chapter 2. SOFTWARE BUSINESS – UNIQUENESS AND REGIONAL CHARACTERISTICS. MAIN STRATEGIC ISSUES. 2.1. Uniqueness of the software business Besides the software uniqueness, related to its characteristics, we could also note many other features that also define its development as a unique process. The main costs for development of a certain software are incurred up to the moment of creation of the first copy that is fit for use. The costs for each subsequent copy are negligible and if the product support turns out to be easy and cheap, it is completely normal (at least for a certain period of time) for the profit rate from this software product to reach 99%. These indicators are hard to achieve for any commercial or industrial activity. There are almost no production companies in other sectors offering different services, together with the process of manufacturing products. For most of the major software companies, this is exactly the opposite, because they are equally good in the development of both aspects – products and services. Even companies like Microsoft and Adobe could hardly be mentioned as an exception. Another characteristic that makes software production unique is related to the duration of the project. It is common and even acceptable for 80% of the projects to miss the planned deadlines. It can be stated that there is no other sector where this would be considered acceptable, in the presence of all kinds of organisational measures, introduction of standards and established practices, increasingly refined methods of management and the serious hazard of contractual penalties. Again, the reason behind this is the uniqueness, difficult predictability and the increasing complexity of the applications developed in the software business. It is also noteworthy to mention one more feature. For example, consider a construction company that has purchased certain machines for automation of a certain partial process of its operations. Probably it will keep contact with the supplier company for a long period of time. If the construction company decides to replace these machines with similar ones, however from a different company, this will require certain funds for additional setting, however, this is not likely to be critical or hard to achieve. On the other hand, there are thousands of companies that cannot make such 121
type of change in the software they have and use for years. Such a change would be very costly for them and it is not clear whether it is possible and the consequences it might lead to. Every day companies in each sector go bankrupt, some improve their status, others lose more or less from it. Disruptions in the software business, however, sometimes take unusually large dimensions, even for companies that are known to be extremely stable (e.g. the disruptions in 2000 – 2002). Giant companies like SAP, Oracle, Siebel Systems, Business Objects lose up to 80-90% of their value at certain moments. Even Microsoft has experienced fluctuations that have resulted in a 2/3 loss of its value at some point. In 2012, Microsoft registered loss for the second quarter for the first time after starting to trade on the stock exchange market. The company declared 492 million dollars loss, as compared to the profit of 5.9 billion dollars for the previous year. The main reason for the losses is the unsuccessful acquisition of the large Internet advertising company Aquantive in 2007, for which Microsoft paid 6.3 billion dollars. It was meant to support Microsoft in competing with Google, however, it did not bring the results expected. Nevertheless, despite the economic crisis, unsuccessful transactions or the maintenance of sometimes unprofitable decisions, large companies working in the software business have managed to survive. Software organisations face a number of challenges predetermined by the following trends in software business: the increasing complexity and size of software applications; the increasing requirements with regard to the possibilities for integration between different applications and platforms and also with regard to the interface - its interactivity and ease of use; the shorter deadlines for implementation of the projects; the increasing clients' and users' intolerance to software bugs; the difficult predictability in software development; the higher dynamics both in the clients' requirements and in the economic environment as a whole.
122
2.2. Regional aspects of software business Despite the global scale of software production and marketing, software development can be distinguished by a number of features, depending on the part of the world where it takes place. The main differences are related to the market orientation - export / import of software products and services, the level of development and application of innovative technologies, as well as the attempt to achieve high levels in the field of education. We will now discuss the main developing economies with the largest share in software industry82. 2.2.1. Europe A major part of the concepts related to hardware and, at a later stage, the ones related to software, originate from Europe (and also the USA). The main focus of most European software companies is to treat software and its development as a science. Over the past years, there has been emphasis on some new technologies, such as Cloud Computing, development of mobile device applications and modern web applications. Maintaining a high level of education in the field of information technologies in universities is one of the main prerequisites for the creation of some of the most complex and precise software products, such as SAP's ERP system, which was developed by the German company SAP AG – a global leader in offering software solutions for managing business. SAP features a set of programmes (the so-called ERP) for comprehensive management of a manufacturing or sales enterprise. Another example is the idea and software implementation (the HTML language) of the Englishman Tim Berners-Lee, which is the basis of the worldwide web. It was created while he worked for CERN - the European Organisation for Nuclear Research based in Switzerland. Despite these examples of significant achievements, as a rule, European companies pay more attention to the quality of software products. They focus less on the practical aspects related to attracting the mass users and generating profit from that.
82
Information economy report, 2012. http://unctad.org/en/publicationslibrary/ier2012_en.pdf. 123
2.2.2. Japan Companies in Japan started producing hardware (large machines) by following the achievements of IBM and some other large American hardware companies. They gradually made a transition to software production as well. Soon, many Japanese companies started to develop programmes for all types of applications - from real-time banking systems, transport vehicles management software to software for specialised gaming computers. This entire range of software products is characterised by the fact that they rarely contain any innovations from a software engineering point of view. Unlike Europe and despite the widespread belief, actually, Japan has not invested much in high-quality higher education in the field of information technologies. The software developed in Japan is also characterised by a certain level of "locality" because of the difference in the letters. Due to these reasons and some local features, software in Japan is developed by following certain heuristic rules, extreme discipline at all levels and without saving from workforce. Generally, the software produced in this way is necessary and good as software accompanying different hardware systems - from large administration computers and servers to small gaming computers. However, the innovative software the one with integrated and realised surprising, extremely useful and revolutionary ideas (such as electronic spreadsheets) - is missing. In other words, there are no indications about the development of software that will generate significant profits. 2.2.3. USA It is a well-known fact that USA are the masters of business. Software is not an exception to this rule. Americans perceive software engineering as an instrument for the creation of "sufficiently good" software by the software companies they own. As a result of their primary orientation toward generation of high profits, the software developed in the USA provides them with the highest profit on a global scale. This laid the foundation for the emergence of some of the greatest giants in software industry, such as Microsoft, Apple, Google, IBM and Oracle. They actually changed and continue to change the world. 124
The creators of Microsoft predicted that one day everyone will own a personal computer and decided to create and sell software that can be used on each such computer. In addition to OS, they continuously develop and update a range of software applications that serve both the business and the individual user. In August 2012, Apple became the most expensive company in the world, with market capitalisation of 623 billion dollars, beating the value of Microsoft from 1999 (620.58 billion dollars)83. Although most of its profit is based on innovative technological solutions and their popularity (such as iPode, iPhone, tablets), at the same time they also take up a significant share in the software sector on a global scale. Netscape became aware of the numerous possibilities of the Internet and they reckoned that in order for the Internet to reach everyone, a simple and inexpensive browser will be necessary, which should function on all types of computers and all types of operational environments. Because of the creation of such a browser, they are on the top of software business for a certain period. And the last example – Google, whose founders realised that the Internet would be nothing without fast, easy, cheap and high quality access to the unfathomable information in it. Computer education in the USA is also at a very high level. Over the last decades, USA has generated some top ideas in the field of IT education, used as a basis and adapted by other countries to their educational systems. This fact inevitable reflects on software engineering by making it well-organised and highly technological. Nevertheless, American companies continue to treat software primarily as a business. 2.3. Software business – 6 strategic questions There are several questions, the responses to which define the strategy of each software company. The main questions among them are as follows: 1. What is the company type – a company for software products or a company offering software services? 2. What is the target market - individual enterprises and individuals or the mass public?
83
Apple becomes the “most valuable company of all time”, http://www.bbc.co.uk/news/business-19325913. 125
3. Is the product or service horizontal (i.e. with wide application) or vertical (i.e. with narrow specialisation)? 4. Does the type of company business provide an opportunity for a continuous and relatively constant flow of revenues? 5. What is the company focus – to be a leader, a follower or to supplement the business of another company? 6. What is the company nature in its relations with customers, the state and the law? 2.3.1. Products or services Probably the most controversial issue most software companies hesitate about is whether the company should focus on the development of software products or on the provision of software services. For a long time, it was believed that a company cannot deal simultaneously or be equally good at both activities. Over the past few years, however, a number of companies showed that things are not that straightforward. Until 2001, the so-called technological companies, i.e. companies of the first type, were in a better position. Their revenues came primarily from the development and sale of software, mostly designed for the mass user. This type of software is also known as "shrink wrap" because of its package with a shrink wrap on the CD containing the respective software product. The most successful companies of this type are Microsoft and Adobe. Of course, these companies were faced with huge expenditure for marketing, research on competition, maintaining and supporting its products and updating them in line with the new technologies. Nevertheless, these expenses are compensated by the significant volume of sales. Software companies would like their business to be exactly of this kind. In most cases, however, they have to create software for individual clients. The more a client operates the product, the more the need of specific modifications, enhancements and consultations. Thus, the software company actually performs different types of software services and therefore belongs to the second type of companies. Sometimes companies that look like companies of the first type – software creators, such as SAP, actually generate most of their income from software services. In 2012, software sales in SAP reached 3.47 billion euros (marking a growth of 13%). 126
At the same time, revenues from software services increased by 16% to 13.16 billion euros, whereas the revenues from subscription fees and cloud services increased by 19% to 4.93 billion euros84. Anyway, there are some exceptions. The revenues of game development companies continue to be primarily generated from sales of products. Based on this, the following conclusions can be made: today, it is difficult to make a clear distinction and determine to which of the two types discussed a software company belongs; the majority of companies need to develop in both fields; balancing between those two extremes is the key to success. In this economic crisis, when the market, including the one for software, is more or less shrinking, the demand for new software products and even new versions of the products used is also shrinking. Thus, users and client companies continue to use the software they own and as a result they mostly need certain software services. Therefore, the strategy of flexible software companies should include decrease in production activities (because it will be more difficult to market the products) and increase and development of the range of software services offered. In contrast, in periods of economic progress there is high chance that demand for new software solutions will increase and the software company needs to be prepared to respond immediately, when this happens. The software company also needs to be active with regard to its customers, like in all other businesses. It should attract its customers: by using advertising and marketing; by direct conversations or other methods for offering long-term delivery of different types of software services. 2.3.2. Target market The entire software industry in Bulgaria generates sales amounting to BGN 750 million per year (according to data from 2012). It is expected that the software market will reach 384.8 billion dollars in 2015 on a global scale.
84
SAP declared an 18% decline in profit, http://technews.bg/article-28907.html. 127
Sales of software products and services in Bulgaria increased by 12% in 2010 and by another 6% in 2011 despite the economic crisis. More than 60% of the sales have been performed outside Bulgaria, the primary markets being in EU countries. The largest single market - over 30% of all exports, is the USA. With such a huge competition and the understanding that the number of software companies is too large and will be inevitably reduced, each software company - from the smallest to the largest one - needs to take a decision on the clients it should focus on. A startup software company should be clear right from the start whether it will sell and whether it will focus on small, medium-sized or large companies. Each of these groups is characterised by its specific features. Small companies resemble individual clients to some extent with respect to their financial capabilities and the fact that they prefer to buy mass products and require very few software services. These prerequisites influence the selection of objectives, strategy and organisation of a software company. The software company needs to make the difficult choice between the mass market, where sales and profits could be huge and where competition and market entry are extremely difficult or individual market niches, where the chances to conquer some territories are more realistic, however the expected revenues are significantly lower. 2.3.3. Horizontal or vertical market segmentation It is very important for each software company to determine the scope of the software it will develop. One option is to focus on products designed for the wide public – in this case we are discussing the horizontal approach. The other option is to develop highly specialised products – the vertical approach. The vertical approach can be predetermined by a specific sector, by the users' occupation or even by the operational system (i.e. a specific combination of hardware and operational system). A combination of both approaches is also possible. In this case, an initially universal product becomes specialised or customised for specific sectors, occupations or even based on the users' size. For instance, Microsoft creates a huge variety of software products. They are designed for different market segments. Ultimately, however, these products are of a more horizontal, rather than vertical nature. This is 128
due to the fact that most of their products almost always cover all users of personal computers, regardless of the specific sector they work in or the occupation they practice. Another example of a software company that successfully combines the horizontal and vertical approach is SAP. Since the very beginning of its establishment, it developed software products designed to "horizontally" cover the needs of computerised management of a wide range of enterprises. Over time, it became clear that the structure and functioning methods of companies from different sectors have certain differences and, as a result, the company started to focus on the development of more highly specialised products. SAP gradually started to create both possibilities for customisation and packages designed for a specific sector. This is how their products were "verticalised". Verticalisation reached the point where, in 2003, the company already offered more than 20 distinct sets. Each of these sets covers the needs of a different sector in the field of manufacturing and services. It is very tempting to select the horizontal approach – at its border line, the target market would be all owners of computers, mobile devices and tablets. At the same time, this approach is associated with certain drawbacks. First, no matter how "horizontal" the market looks, it has certain specifics requiring a lot of effort, including investment. It is necessary to consider the hardware requirements, the operational systems, the possibility for integration with other systems, the technical capacities, even for computer devices manufactured during the same year, etc. Second, in essence, this market is saturated. Third, even if those two arguments are neglected, it is a fact that companies willing to take a position on the horizontal market are too many and will continue to increase. This means that each company seeking a place on the horizontal market should compete both with the established historical leaders on the market and with the newly emerging companies willing to take a share, some of which have substantial financial capacity. 2.3.4. Continuous flow of income It is very important for software companies to have disposable funds, because their market value fluctuates the most, as compared to other sectors. Therefore, every 129
software organisation must put some efforts for ensuring a relatively constant (and, if possible - continuously growing) flow of income. Particularly, such income should be guaranteed through long-term contracts or specific and justified marketing forecasts of the future behaviour of the company clients. Contracts are the more reliable approach of these two. These can be related to product maintenance (enhancement of the possibilities, elimination of errors, delivery of new versions and modifications) and different services (consultations of different form, training, assistance in the operation in special cases). Yet, this type of income is as attractive as the income generated from license fees because of the significantly lower profit margin and the involvement of more human resources. Furthermore, activities related to support and provision of services entail more difficulties and troubles due to the inevitable intense and strained relationships with the customers. One should not neglect the mere opportunities related to products as another primary source of constant income. Some of the large software companies have already taken into account that consumers usually replace their hardware every 2 to 4 years. They sign contracts with hardware manufacturers for complementary sale of this product together with an operational system, anti-virus programme and even some popular specialised products. Even though users in difficult financial situation usually do not tend to purchase new software, they often tend to update their hardware in line with its dynamic pace of development and because of the declining prices for hardware with better properties. Based on this scheme, they actually also purchase the software (for example a notebook with software products and operational system installed). There are also some known unfair practices in this respect. There are cases when a certain specialised software product (for example a word processing programme) remains fully functional even when used with a new hardware. At the same time, however, a new operational system is launched for this hardware, where the specialised product either does not work at all or cannot use the new operational capabilities. Thus, the client is forced to purchase or pay a fee for the new version of the word processing programme, even though they do not need it. These tricks are possible with the files compatibility and the encoding methods. Such situations are 130
called “backward compatibility” and “forward compatibility”. Microsoft, for instance, guarantees the first type of compatibility, however, does not take any commitments on the second type of compatibility. 2.3.5. Company orientation – leader, follower or a complementing company Practice shows that a company can play either of these three roles – to be a market leader, to be a follower of a company that has already taken the leading position or to complement the activity (products developed, services) of another company with its operations. Sometimes we use the concept of "market leader" – the software product of the leading company has a dominant position on the market. However, it can also happen for a company to turn out to be a "platform leader". This is when the company has created a software, around which other companies create different software products compatible with the leading one. This is the role of the "complementing companies", who create this "complementary" software. For example, Windows is a typical platform, which means that Microsoft is a platform leader. The "Technological leader" is a company that has created and that masters a certain technology. There are cases when the "platform leader" is not the "technological leader" at some point. "Followers" on the other hand are companies creating software products that are analogical to the ones already launched on the market, relying on the lower price of dissemination, higher quality or at least some advantages compared to the leading product in some aspects. 2.3.6. Characteristics of the relations with other stakeholders Each company should determine its conduct with respect to the state, its customers and the public. It is a common rule in business that aggressiveness usually leads to positive business results. On the other hand, it is clear that too much aggressiveness surpasses the generally accepted limits of ethical conduct. A large part of the software systems used are of critical importance. The software administers a number of key activities – flight management, manufacturing of complex 131
equipment, billions of bank operations, medical observations and diagnoses. The state, the public and the individuals have no choice but to deeply trust the companies creating and maintaining this software. This, however, automatically means that companies should justify this trust with the appropriate conduct – responsibility, ethics and integrity. We can add some more details to this general overview. For public companies listed on the stock exchange, it is very important that the public, and, particularly investors know that they thrive, that they have revenues, that they frequently receive orders and comply with their contracts. Generally, such a situation increases the price of their stock. However, based on this, software companies (like many others) are tempted to distort the truth to the extent permitted by law.
References and Internet sources 1. Eskenazi, A. and Maneva, N. Software engineering. KLMN, Sofia, 2006. 2. Cusumano, M. The Business of Software, Free Press, New York, 2004. 3. http://www.bait.bg/novini/bait-uchastva-v-sazdavaneto-na-nov-kompetentnostenmodel-v-obrazovatelnata-ni-sistema/Software-Insdustry-Requirements-forEducational.pdf. 4. http://www.bbc.co.uk/news/business-19325913. 5. http://technews.bg/article-28907.html. 6. http://unctad.org/en/publicationslibrary/ier2012_en.pdf.
Self-study questions 1. What are the characteristics which define software development as a unique process? 2. What are most common challenges faced by software organization? 3. Provide three examples of software companies that are good at both activities – development software products and provision of software services. 4. What does strategic question “horizontal or vertical market segmentation” mean?
132
5. If you have a software company which „Company orientation” will you prefer? Explain.
133
Chapter 3. AGILE METHODOLOGIES FOR SOFTWARE DEVELOPMENT – GENERAL PRINCIPLES AND PRACTICES. DIFFERENCES BETWEEN CLASSICAL AND AGILE METHODOLOGIES 3.1. Origin and concept of agile methodologies From a historical point of view, the first steps laying the foundation of agile methodologies date back to the late 80s and the early 90s of the last century. This is when new models emerged, such as the Prototyping methodology (1986) and the Spiral model (1986). The Rapid application development - RAD model (1991) emerged later based on them. Because of them and the willingness to avoid the "cumbersome" processes of software development, the agile methodologies emerged, the most popular among them being the ones listed below, arranged chronologically: ‒ Dynamic systems development method (DSDM) in 1995 ‒ SCRUM in 1995 ‒ Extreme Programming (XP) in 1999 ‒ Adaptive Software Development (ASD) in 2000 ‒ Feature-Driven Development (FDD) in 2002 During the years before them, classical models were applied, such as the so-called waterfall model, the iterative model and other models based on them. The tip of the group of waterfall-based methodologies is the popular Rational Unified Process (RUP). It is the first one to combine techniques from the traditional project management with the elements specific for the IT sector, by using the UML language for modelling the system at different levels. For the first time, users were included in modelling and their methods of interaction with the system were considered. Yet, this model has certain drawbacks: too much volume modelling and too detailed modelling (scenario model, static, dynamic model, test model, etc.); complex application; change management only covers synchronisation in the models already made. In addition, we can also mention some common problems in the methodologies based on classical approaches for management of the software development process: - “Big Design Up Front” (BDUF) – i.e. too many efforts for planning and design of the early project stages, before the real coding starts; 134
- lack of mechanisms for adequate response to the business and IT sector dynamics; - primary focus on the processes, rather than the real needs of the customers; - spending too much time on maintaining strict and detailed documentation. In 2001, a group of leading specialists headed by Kent Beck caused a real boom by publishing
the
famous
Manifesto
for
Agile
Software
Development
(www.agilemanifesto.org ). Representatives of some of the Agile methodologies established at that moment combined their efforts around some principles and values and established an organisation they called "Agile Alliance". They focused on the general practices agile methodologies adhere to. Today, 14 years later, these values and principles are still valid, they have become very popular and are integrated by an increasing number of organisations all over the world. According to the Manifesto for Agile Software Development, the main values of agile methodologies are: Individuals and interactions over processes and tools. The main idea behind this is that people are the most important capital on the road to success. A good process will not provide a guarantee against project failure, if the team does not have strong participants who are good in teamwork. A strong participant should not necessarily be an excellent programmer - he/she can be a medium-level specialist; it is more important for him/her to be able to work in a team. Working software over comprehensive documentation. Documentation is a mandatory condition for each software, however, it is believed that documentation that is too comprehensive is worse than limited documentation. It should be concise and logical and documenting should take place when the need for this is significant and urgent. Customer collaboration over contract negotiation. Successful customers require regular and frequent follow up from the customer. The best contracts are not the ones describing the method of development, but the ones describing the method of collaboration between the developer and the customer. Responding to change over following a plan. A good planning strategy is to make detailed plans for the next few weeks, general plans for the next months and 135
estimated plans for larger periods. In this way the tasks to work on will be known and the overall objective and overview of the system will be outlined. These values might sound revolutionary at first and many people perceived them exactly this way at the beginning. However, the great reputation of the authors and their indisputable success in the field of software creation resulted in dissemination of the idea and to its development up to now, when agile technologies have become dominant. In addition to the values, the manifest also defined 12 principles: 1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 3. Business people and developers must work together daily throughout the project. 4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 5. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 6. Working software is the primary measure of progress. 7. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 8. Continuous attention to technical excellence and good design enhances agility. 9. Simplicity – the art of maximising the amount of work not done (that we could decide not to do in order to simplify life) – is essential. 10. The best architectures, requirements, and designs emerge from selforganising teams.
136
11. At regular (frequent) intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. 3.2. Comparison between agile and classical methodologies Based on the reviewed principles and values defined by Agile Alliance, we can summarise the main features of agile methodologies: the development process is constantly subject to changes; iterations with short cycles of development that allow rapid verification and corrections; duration of iterations - from one to six weeks; aspiration to eliminate all unnecessary tasks in the development process; adaptivity to risk of rapid changes in the software; incremental software process that allows introduction of new functionality in small increments; people-oriented - agile methodologies focus on individuals rather than the software process and technology; work style in the spirit of collaboration and interaction. If we compare agile methodologies with the classical ones, we could note that one of the main features of classical methodologies is the plan for development that is fixed from the very beginning. This is why they are also called "planning" or "plandriven" methodologies. Classical methodologies have been applied since the early 70s, when they introduced a systematic approach to software development for the first time. They focus on: comprehensive documentation, traceability of the software development from the concept to the finished product and continuous monitoring of the process (see Table 3.1.). The procedures for product quality control and improvement of the development process are an essential part of traditional methodologies.
137
Table 3.1. Main differences between agile and classical methodologies AGILE METHODOLOGIES
Type of interaction Managerial style Knowledge used Requirements
Development
Quality control
Documentation
TRADITIONAL METHODOLOGIES Informal Formal Based on leadership and Based on management and collaboration control Non-apparent knowledge Apparent knowledge Prioritised informal Requirements in formalised requirements and test scenarios; form, defining the software support unforeseen changes capabilities, user interfaces and quality; predictable change in requirements High level software design, short Comprehensive and thorough iterations, easy to change the software design, longer software design iterations, repeated design is undesirable and expensive Continuous monitoring of the Formal control and later detailed requirements, the design and the planned testing based on presolution; continuous testing defined activities Minimum volume necessary Comprehensive and formalised
In their work, Boehm and Turner formulated 6 "observations"85 characterising the two approaches to software development - the classical and the agile one. They called classical approaches "disciplined" approaches. After their analysis, they offered a method for evaluation of the balance between the two approaches in each individual company. They also proposed a method for improving this balance with a view to the specific company objectives. The method covers elements of formalisation and quantification. The six conclusions derived by Boehm and Turner are as follows: 1. Neither agile, nor plan-driven method is a silver bullet for software development. 2. Agile and plan-driven methods have their own home grounds, to which either of the two groups is more appropriate. 3. Future applications will need both agility and discipline. 4. Balanced agility-discipline methods are emerging.
85
Boehm, B., Turner, R. Observations on balancing discipline and agility. Proceedings of the agile development conference. IEEE Computer Society, Salt Lake City, 2003. 138
5. It is better to build your method up, rather than tailor it down. 6. Methods are important, but special attention should be paid to the relationships between people, values, communication and expectations management. In addition to the conclusions, Boehm and turner defined 5 dimensions that they believe influence the choice between using agile or classical methods for software development: 1. Experience of the project personnel - it shows the ratio between the highskilled and unskilled specialists involved. 2. Criticality – it is defined by the possible losses in case of a system defect in the following descending order: loss of more than one human life, loss of one human life, loss of own funds, loss of someone else's funds for which one is liable and loss of comfort. 3. Project size – it is defined by the number of staff involved. 4. Organisational culture. Organisations focusing on order and following predefined rules and procedures predetermine their cultural habits differently from organisations with clear levels of freedom. 5. Dynamism – it is defined by the percentage of changes in the requirements occurring for a month. Generally, agile methodologies are suitable for: less critical projects (in most cases) of up to several dozen staff members, with dynamic requirements, predominantly with high-skilled staff and greater opportunities for freedom of choice. The opposite is valid for projects that are more appropriate for disciplined (classical) methodologies.
References and Internet sources 1. Eskenazi, A. and Maneva, N. Software engineering. KLMN, Sofia, 2006. 2. Ilieva, S., Lilov, Vl., Manova, I. Approaches and methods for development of software systems. "St. Kliment Ohridski", Sofia, 2010. 3. Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. Agile software development methods.VTT Publications, 2002. 139
4. Boehm B., Turner, R. Observations on balancing discipline and agility. Proceedings of the agile development conference. IEEE Computer Society, Salt Lake City, 2003. 5. http://agilemanifesto.org/
Self-study questions 1. What are the main values of agile methodologies according to the Manifesto for Agile Software Development? 2. What are most common problems in the methodologies based on classical approaches for management of the software development process? 3. Describe the tenth principle of the Agile Manifesto in your own words. 4. Describe the main features of agile methodologies 5. What are the main differences between agile and classical methodologies?
140
Chapter 4. NATURE, PROCESS AND APPLICATION OF THE XP, SCRUM, FDD, DSDM, ASD METHODOLOGIES 4.1. Extreme Programming - XP Extreme programming is a methodology designed for small and medium-sized teams (from 3 to 20 people). It is suitable both for development of specific software applications and for web-based systems. Communication and coordination between the participants should be possible at any time. Therefore, XP is not applicable for teams distributed at different floors or in different offices. A certain technology could be a hinder to the success of an XP project - if it does not support agile changes or if it requires too much time for feedback, then it is not appropriate. The development process in XP is comprised of six stages: exploration, planning, iterations phase, finished product, maintenance phase and death. Exploration phase – customers summarise the functionalities they want to include in the first version (release) of the developed product. Planning phase – priorities are set. The developers' team familiarises itself with the technologies and practices that will be applied for the development. The technology is tested and short system prototypes are made. The phase can take up several weeks, depending on the developers' skills, but usually it continues for a couple of days. Iterations to release phase - it includes several iterations before receiving the first version of the product. Iterations have a duration of 1 to 4 weeks. During the first iteration, the architecture is developed through the selection of functionalities that are essential to the system development. Functional tests created by the customer are performed for each iteration. Finally, during the last iteration, the system is ready for installation at the customer's site. Productionizing phase – intense system testing, before delivering it to the customer. During this phase new changes can be still added. Maintenance phase – focusing the efforts for maintaining the customer's tasks. The phase may require to include additional people in the team or a change in 141
the structure of the existing team. Death phase– the customer does not have any further requirements to the system. The necessary project documentation is drafted and no more changes in the architecture or code are expected. This phase may also occur if the system is delivered in a way that does not satisfy the customers' requirements or if the development becomes too expensive.
Fig. 4.1. XP process 4.2. SCRUM methodology The SCRUM methodology can be used for the management of each type of project and introduces some general guidelines for achieving agility, adaptability and productivity in the course of the development. The Scrum process itself is suitable for projects that are subject to frequent changes or the requirements of which are highly unpredictable, which is definitely the case with software projects.
142
The Scrum process includes the following phases: pregame phase, development phase and postgame phase (see fig.4.2.).
Fig. 4.2. SCRUM process The pregame phase is comprised of two subphases: planning and high level design/architecture. The "planning" subphase covers the definition of the system before the development starts. A list of the known requirements to the system at the time is created - this is the so-called Product Backlog list. The requirements can be given by the customer, by the company Sales Department, by the Marketing Department, by the Customer Support Department or by the developers themselves. Priorities are set for each requirement and the time necessary to fulfil them is estimated. The product backlog list is periodically updated with new elements, new priorities for them and increasingly accurate estimates regarding the necessary time for implementation.
143
Planning includes defining the team to work on the project, the resources / tools used and all other resources. It is necessary to obtain approval of the defined conditions for the project implementation by the organisation's management unit. After each iteration (in Scrum, these are called sprints), the updated product backlog list is reviewed by the Scrum Team in order to specify the parameters and the specific conditions for implementation of the next iteration. The "design/architecture" subphase includes the highest level of design and development of the architecture based on the elements from the product backlog list. If certain changes are necessary in order to improve the developed system, the project is analysed and suggestions on its modification are made, by taking into account the problems that the new changes might cause. During the design/architecture phase, preliminary plans are also created with respect to the content of the system's next version based on the relevant requirements. The development phase in Scrum is also called "game" and constitutes the agile part of the approach. The phase is considered a "black box", because anything unpredictable might happen in the course of its implementation. Different variables, such as time, quality, requirements, resources, tools and budget may undergo changes at any time. Therefore, they are subject to control and monitoring by the application of different practices defined by the Scrum process during the sprints. If there are changes, the new limitations are included in the planning for the next sprint in order to achieve agility and adaptability to changes. During the sprint, no one can change the sprint backlog, which means that the requirements within a certain sprint are strictly fixed. Each sprint covers the common phases of software development – analysis of requirements, design, development, testing. The architecture and design of the developed software evolve with each subsequent sprint. The postgame phase is the finalisation of the project and the creation of the finished version (release) of the system. The transition to this phase happens after reaching an agreement with the customer on the implemented functionality for the time defined. This phase covers activities such as integration, system tests, documentation, drafting training materials and other supplementary materials and 144
drafting marketing materials.
Requirements
Product backlog list
Sprint planning meeting
Spring backlog list
Daily Scrum meetings
Sprint Effort estimation
Sprint review meeting
Standards Conventions Resources Technologies Architectures Executable product increment
Fig. 4.2. SCRUM sprint The high popularity of Scrum (not only in the software industry) is the result of its simplicity and ease of use. The methodology defines only organisational and social approaches, leaving freedom of choice for the managerial and technological approaches. Scrum does not define any specific techniques for software creation during the development phase. It focuses on how the team members should work in order to ensure agility of the product developed under constantly changing requirements. 2 ways of application have been defined for Scrum: upon creating a new product and upon enhancement and further development of an already existing product. A typical example is the transition to Scrum in projects that are challenged by the frequently changing conditions and that use new and complex technologies. When Scrum is applied, teams of no more than 10 people are organised (the recommended number of members is between 5 and 9). Large projects could also be developed with the involvement of much more people, organised in small teams. Scrum is a well-developed and documented methodology, for which even a certification procedure is offered.
145
4.3. Adaptive Software Development - ASD Adaptive Software Development (ASD) focuses on the problems in the development of large and complex systems. The methodology stimulates incremental (stepwise) and iterative (repetitive) development and the use of prototypes. ASD provides specific guidelines for avoiding chaos in the project. On the other hand, these guidelines are not too many in order to prevent restriction of creation in each development. The development of the software project under the ASD methodology undergoes cycles, each consisting of three phases:
speculate; collaborate; learn.
During the speculate phase, the term “speculate” is used instead of "planning", because the plan is regarded as something, where uncertainty is a flaw and any deviation from it is considered a failure. It is comprised of two subphases – the project initiation phase and the phase of adaptive cycle planning. The project initiation phase defines the project milestones and its mission. It defines the overall vision of the project with respect to functionality, project data list and the specifications of the developed project. During this phase the overall schedule is drafted. The cycles usually have a duration of 4 to 8 weeks. The planning of cycles is part of the iterative process, since the definition of components is continuously specified in order to reflect the changes in the requirements about the components and each new change. ASD is a component-oriented methodology, rather than a task-oriented methodology. The focus is put on the outcomes and their quality, rather than the tasks or the process followed for reaching the outcomes. The collaborate phase highlights the significance of teamwork in the development of a constantly changing software. The component-oriented approach entails adaptive development cycles that are part of the collaborate phase. During this phase, it is possible to develop several components simultaneously. The basis for the next cycles is achieved by iterative quality reviews focusing on demonstrating the functionality of the software developed during the cycle. An important factor in the quality review is the presence of the customer represented by expert groups. 146
The last "learn" phase focuses on the need to realise the mistakes and to undertake measures and also on the fact that the requirements will change during the development. I.e. learning from the mistakes and learning for agile adaptation. The last stage of the learning phase is a final analysis of the software quality and installation at the customer's site. ASD does not discuss the method of conducting this phase; it only emphasises the importance to master what has been learnt.
Learning cycle
Project initiation
Adaptive cycle planning
Speculate
Development by cycles
Final quality analysis and finished release for the customer
Quality review
Collaborate
Learn
Fig. 4.3. Lifecycle phases of ASD The principles and ideas set out in ASD are well-justified, however, very few guidelines on the methodology application have been provided. The methodology offers a small base of ASD integration instructions for a software organisation. Therefore, it is recommended to use this method in combination with other methodologies. There are no limitations with regard to the teams' location, as is the case with many other Agile methodologies. 4.4. Dynamic System Development Method - DSDM Instead of fixing the set of functionalities in a product and then adapting the time and resources to that, DSDM would rather define the time and resources first and then define the multitude of functionalities on that basis. The DSDM process comprises of 5 phases: feasibility study, business study, functional model iteration, 147
design and build iteration and implementation. The first two phases are consecutive and are only performed once. The next 3 phases when the actual development takes place are iterative and incremental. The time necessary for each iteration is planned in advance, together with the expected results. During the feasibility study phase the DSDM approach is evaluated for its suitability for the respective project. The project, the objectives, the problems to resolve, the team and the financing are identified. 2 documents are drafted – a report on the availability of resources and a schematic plan for development. During the business study phase the essential characteristics of the business and technologies are analysed. It is recommended to organise seminars with participation of as many customer representatives (experts) as possible. The purpose of this is to reach an agreement on the priorities of the development. During the definition of the business field, the processes are described and presented in a suitable format (E-R diagrams, business models, etc.). 2 more results are obtained from the business study phase - one of them is the definition of the system architecture and the other one is the plan for creation of a prototype. The functional model iteration phase is the first iterative and incremental phase. It covers: development of (functional) prototypes, analysis, writing a code. Prototypes are gradually further developed to a quality that will allow them to be included in the final software product. As a result, a functional model is created, containing the prototype code and the models for analysis. Testing is the key and longest part of this phase. Iteration of the design and build is the phase when the main software development and building takes place. The result is a tested system that covers at least the minimum requirements. The design and implementation are iterative and each functional prototype undergoes design, coding, testing and discussion with the customer. Each subsequent prototype includes new functionalities and modifies the existing ones in line with the conclusions from the discussion. The last phase is the implementation phase, when the developed software is transferred from the development environment to the actual environment - the 148
customer. The results from this phase are: "User Manual" and "Project Report" summarising the project results. It is recommended that the DSDM team comprises of 2 to 6 people with the possibility to work with several teams. If it is applied for large projects, DSDM requires to break up the developed software into components to be developed by separate small teams. DSDM is considered the most formal and "ceremonial" methodology of the Agile family. This makes it the preferred option when the formal side of things matters, for instance in public projects or projects with public funding. 4.5. Feature Driven Development (FDD) FDD focuses on breaking up the total project into many smaller ones, each of which deals with a certain feature of the system. The feature is an important function for the customer that can be implemented for no more than 2 weeks. FDD does not cover the entire software process, but focuses on the design and build stages. FDD pays more attention to project management and quality management as compared to the other agile methodologies. The FDD process consists of 5 consecutive phases, when the system design and build take place - development of an overall model; building a feature list; planning by features; design by features and implementation of features. The last two phases - design and implementation of features - are the iterative phases of the process. They help maintain an agile development with quick adaptation to late changes in the business requirements and needs. During the phase of development of an overall model, the team and the customer define the scope, context and requirements of the system. During this phase, there may already be documented requirements, however, FDD is not specifically oriented toward the process of their selection and management. The analysed field is divided into subfields and a detailed overview of each one of them is carried out. Then, the developers' team develops models for the subfields. At the same time, an overall system model is developed, which represents its summarised architecture. Based on the activities during the first phase – "overall review", the models of the subfields and the existing documentation with the requirements, a comprehensive feature list of the features to be included in the developed system is drafted. The main 149
functionalities are divided into subsets of detailed features. These are different activities within each defined subfield. Planning by features covers the establishment of a high level plan, where the sets of features are implemented in a certain sequence, based on their priority and dependencies. Schedules and deadlines for implementation may be defined as part of this. Small groups of features are selected from the numerous detailed features and teams for their development are formed. During the last two phases - design and implementation of functions, tasks, such as design check, code writing, module testing, integration and code checking are covered. Upon successful iteration, the completed features become part of the main release and a new iteration starts with designing and creation of a new group of feature out of the predefined set of features. FDD is suitable both for new project startups and for development of existing applications. In contrast to other agile methodologies, FDD is considered appropriate for the development of critical systems, because it entails more detailed planning and analysis, which could significantly reduce the risks for large and complex projects. Yet, the authors of the methodology suggest gradual and incremental transition to FDD, until they utilise it fully in the development of software applications.
References and Internet sources 1. Ilieva, S., Lilov, Vl., Manova, I. Approaches and methods for development of software systems. "St. Kliment Ohridski", Sofia, 2010. 2. Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. Agile software development methods.VTT Publications, 2002. 3. Abrahamsson, P., Wasta, J., Siponnen, M., Ronkainen, J. New Directions on Agile Methods: A Comparative Analysis. International Conference on Software Engineering, Portland, USA, 2003. 4. Cobb, Ch. Making Sense of Agile Project Management: Balancing Control and Agility. Wiley, 2011. 5. www.agilemanifesto.org. 150
Self-study questions 1. What does Extreme Programming mean? 2. Define the phases of the Scrum process? 3. What are the main characteristics of Adaptive Software Development? 4. Define the most formal and "ceremonial" methodology among reviewed above. Explain. 5. Which of reviewed agile methodologies is considered suitable for critical systems, as it entails on planning and analysis in greater detail?
151
Chapter 5. SCRUM – CONCEPT, CHARACTERISTICS, PROCESS, PRINCIPLES, ROLES. APPLICATION OF SCRUM - HISTORY, PRODUCT BACKLOG, SPRINT BACKLOG, BURNDOWN CHART 5.1. Introduction The Scrum methodology defines an intensive development process that allows to focus the efforts toward finalisation of the most important feature for the business within the shortest timescale. The approach was created in 1987 and its name originates from scrum, scrummage - "struggle for possession of the ball", particularly in rugby, or a holistic approach, in which a team attempts to take the distance as a whole, by tossing the ball back and forward. It is believed that this approach serves better in the current conditions of rivalry and attempts to achieve maximum speed and agility. Initially, the Scrum methodology was proposed for management of the development of products outside the field of software creation, but gradually started focusing on software projects management. Scrum allows rapid and cyclical real inspection of an operating software. The business sets priorities. Teams are selforganised in order to find the best way to develop the most important requirements. Every two weeks or every month, everyone can see a software that is actually working and take a decision for market release as it is or a decision to continue with the enhancements during the next sprint (iteration). Today, Scrum has become widely popular and is used by companies like Microsoft, Yahoo, Google, Philips, Nokia, BBC, IBM, Intuit, BMC Software and many others. 5.2. Main concepts 5.2.1. Sprint Software development takes place in small iterative cycles – sprints, when a new system feature is created and/or an already existing feature is improved. Usually, the duration of sprint is 1 to 4 weeks or it is recommended to continue for no longer than 30 days. During sprint, the product is designed, programmed and tested. It is recommended to include between 3 and 9 sprints (or 3 to 6 months) in the 152
development of a certain system, before the system is ready for delivery to the customer or for being launched on the market. Scrum does not limit the number of teams to develop the system – it is possible for several teams to work in parallel on different system features. Instead of implementing the activities one by one for the phases of defining the requirements, design, programming and testing, the Scrum teams implement everything at the same time and continuously. The duration of the sprint shall be equal to the period in which the organisation can work without changes, because no changes are allowed during spring. The time is also determined based on other important factors, such as product complexity, evaluation of the risk and the desired level of compliance. Each Sprint is comprised of one or more teams, performing the following: Development: defining the necessary changes for implementing the requirements from the Product Backlog in "packages", opening the packages, analysing the field, design, development, implementation, testing, documenting changes. Packaging: Finalisation of packages (potentially finished products), creation of an executable version based on the changes made and checking how they fulfil the requirements from the backlog. Review: All teams meet periodically to present the work done and to overview the progress. Different issues and problems and the methods for their resolution are reported and new elements to the Product Backlog List are added accordingly. Setting: Combining the information collected during the review meetings, including the requirements for different appearance of the software or for new properties. 5.2.2. User stories In the Scrum approach, user stories are a method to clarify the requirements. Often, when the development process is cyclical, each version received by the customer will lead to the formulation of new requests for change, which will require 153
new changes and, in turn - more documentation. In Scrum, the requirements are largely maintained through an informal approach – description of the stories on sticky notes or index cards. The stories themselves are short and written from the perspective of the customer's interaction with the software product. It is recommended that the customer writes the stories. A story may give rise to a number of questions, which are clarified with the developers, so that the purpose of the story from the customer's perspective can be fully understood. In addition to the stories, it is also necessary to formulate a clear objective of the sprint. This is a short description of what the team's efforts will focus on during this sprint. For example: "To add a data import feature from MS Excel and MS Word and possibilities for editing after the transfer". 5.2.3. Roles The Scrum methodology defines three roles - Product owner, Scrum master, Scrum team. Each of these roles involves certain responsibilities and obligations for the persons that should implement it. The product owner is responsible for: ‒ defining the product features; ‒ taking a decision for market launch; ‒ responsible for the return on product investment (ROI); ‒ sets the features priorities; ‒ if necessary, changes the functions and priorities before each sprint; ‒ accepts or rejects the demonstrated feature. The Scrum Master should: ‒ represent the project management; ‒ be responsible for establishing the values and principles recommended by Scrum; ‒ remove hinders; ‒ take care of the functionality and productivity of the team; ‒ ensures effective collaboration between all roles and functions; ‒ protects the team from external influence; 154
‒ chairs the retrospective meeting at the end of each sprint; ‒ maintains the Burndown chart. The Scrum Team usually comprises of 5 to 9 people and is cross-functional, i.e. it includes programmers, testers, user interface designers, etc. The team members should work full-time only for this role. Exceptions for some specialists, such as DBA (database administrators) are possible. The teams are self-organising – ideally, there are not titles like senior or junior. The team members may only be changed between the individual sprints. 5.2.4. Product Backlog The product backlog covers all expected requirements toward the product, assigned to the different sprints, and is usually presented in a table (see fig. 5.1.). ID Rank
Score in points for the story
64
1
5
69
2
6
53
2
5
67
4
4
57
5
3
Description As a user, I want to be able to log into the system, so that I can use the resources I need As a user, I would like to be able to recover my forgotten password As a student, I want to be able to edit the details in my profile As an administrator, I want to be able to administer the accounts of the other users As a student, I want to be able to check the history of my actions in my profile
Status
Iteration
completed
\ Sprint 2
in progress
\ Sprint 2
in progress
\ Sprint 2
not started
\ Sprint 3
not started
\ Sprint 3
Fig. 5.1. Sample product backlog The backlog may contain more information about bugs discovered (which should be removed) and non-functional requirements, which constitute the limitations of the project. The product owner is responsible for defining the priority (rank) of the elements in it. He/She should understand each story (requirements are formulated in the form of stories). The backlog is updated after each sprint, since no adding of elements is recommended during the sprint. Each participant can add elements in it, including the team. It does not contain tasks. The elements may have acceptance criteria defining what the respective element is expected to do, e.g. statements like "When this is completed, if you do , the result will be . 155
5.2.5. Sprint Backlog The sprint backlog contains a defined set of stories selected from the product backlog, which should be implemented during the sprint that is planned. This set is defined during the meeting for planning the Sprint. Each story is broken down into tasks by the team. The number of members and specific team members to work on each tasks are determined. Everyone selects the task to work on. Tasks are never assigned. The amount of the remaining working hours changes every day based on the hours worked and the estimated time of completion (see fig. 5.2). Tasks
Monday
Design of business logic Creation of the user interface at the login page Creation of the acceptance tests Coding Testing (Unit and acceptance tests) Documenting in online help
Tuesday
Wednesday
Thursday
Friday
6
6
3
0
0
5
5
8
6
0
6
2
0
0
0
8
4
6
2
2
7
7
7
5
5
5
5
5
5
5
Fig. 5.2. Reporting the remaining time by tasks in a sprint backlog Each team member may add, delete or change the sprint backlog. The necessary time for the implementation of each task is planned in hours. The sprint duration is defined. Based on it, the time planned for the tasks and the estimated performance of the team, it is decided whether to add or remove some of the stories (or whether to decompose the more complex ones into 2 or 3 substories). If there are unclarities related to the work, it is recommended to create a task in the backlog with a large number of hours and later break it down to smaller tasks when there is more information available. 5.2.6. Burndown chart The Burndown chart represents the progress with respect to the remaining work planned from the Sprint backlog within the timescale defined for the Sprint. In order to determine this, the remaining efforts by stories (in points) and the estimated hours remaining by tasks at the end of each day are added. The chart shows: the number of 156
days planned in the sprint; the performance of the team during the period of the entire sprint; whether all tasks have been completed and how do they progress as compared to the estimated planned time for their implementation defined by the team.
Burndown chart - number of hours remaining Number of hours remaining
200
25
180
173
160
20 144
140 120
15
115
100 87
80 60
10 58
40
5
ОPoints remaining by stories АActual а hours и (remaining) ча ве аващи ПHours а и а и ча ве planned
29
20 0
0 1
2
3
4 5 Days in Sprint
6
0
7
Fig. 5.3. Sample Burndown chart 5.2.7. Meetings One of the most important meetings defining the Scrum methodology is the Sprint Planning meeting. During this meeting, the team selects points from the product backlog it undertakes to complete within the forthcoming sprint. Based on this, the sprint backlog is drafted by identifying the tasks for each story and estimating the necessary time for implementation (from 1 to 16 hours, preferably no more than 1 man-day). The entire team takes part in this meeting, not only the Scrum Master. Then, the project is discussed at a higher level. Once a day, a Daily Scrum Meeting with a duration of 15 minutes is held, where the team is standing upright. It is considered that these meetings are not the place to resolve problems. Everyone can attend them. However, only team members, the Scrum Master and the project owner are allowed to speak. This helps for the avoidance of holding unnecessary meetings. Everyone responds to 3 questions: 157
1) What did you work on yesterday? 2) What will you work on today? 3) Is there anything that bothers you? This is not a meeting for reporting status. Its purpose is to inform everyone on the implementation and the short-term plan for the day. The developers' team uses the daily Scrum meeting to evaluate the progress toward the Sprint objective and to determine how the progress approaches the finalisation of the work on the individual elements from the product backlog. At the end of each Sprint, the so-called Sprint Review Meeting meeting is held. The team demonstrates what they have achieved during the sprint. Usually it is in the form of presentation of the newly implemented features and architectural changes which are potentially ready for use by the Product Owner. This is not a formal meeting. In addition to the team members, the Scrum Master and the Product Owner, the meeting can also be attended by external persons. About 2 hours of preparation are necessary and usually the meeting also continues for two hours. After the Sprint review and before the next planning for a Sprint, the so-called Sprint Retrospective is held. It constitutes regular monitoring at the end of each sprint on what works and what does not. It is recommended that the meeting continues for no more than 3 hours in case of one-month sprints and to be shorter for shorter sprints. The main objective is to find approaches and methods for improving the development process based on the mistakes made and the lessons learned during the completed sprint. It is attended by the Scrum Master, the Product Owner and the Team. The entire team gathers and discusses what they would like to: stop doing or what needs improvement; to start doing or what they could do better; to continue doing (i.e. they do it well). This is one of the many methods to hold a Retrospective meeting. During the retrospective meeting, the actual performance is compared to the planned one. If there are large differences, an analysis of the reason for that is carried out. At the end of the retrospective meeting, the Scrum Master tries to summarise the specific proposals regarding things that could be done better during the next sprint.
158
References and Internet sources 1. Ilieva, S., Lilov, Vl., Manova, I. Approaches and methods for development of software systems. "St. Kliment Ohridski", Sofia, 2010. 2. Schwaber, K. Scrum Development Process. OOPSLA Business Object Design and Implementation Workshop, Springer, 1995. 3.
, .
.
http://adm-lib.ru/books/10/Gibkie-metodologii.pdf. 4. Kniberg, H. Scrum and XP for the trenches. http://wwwis.win.tue.nl/2R690/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf. 5. http://www.osp.ru/os/2007/04/4220063/.
Self-study questions 1. Define the term Sprint in the Scrum methodology. 2. Who is writing the user stories? 3. What items should a product backlog contain? 4. What shows burndown chart and how frequent should update it? 5. Describe the deferent meetings in the Scrum methodology.
159
Chapter 6. CREATING A PRODUCT BACKLOG. PLANNING A SPRINT IN SCRUM 6.1. Creating the Product Backlog During the first phase of the Scrum process of development, a Product Backlog is drafted that includes all requirements to the software product to be developed. The elements in the list should be: Independent; negotiated and flexible to future negotiations (Negotiable); Valuable); possible to estimate (Estimate); Small and Testable. Independent – the purpose is to apply different practices to decrease the dependencies between the individual requirements. Independence means that the story can be developed, tested or even provided for use at the end of the sprint, without being dependent on other stories. This, on the other hand, means that it can be independently estimated. Negotiated and flexible to future negotiations - in contrast to traditional requirements, the user story is not binding like a contract for a specific feature. Stories are the result of negotiations between the business and the team with focus on the requirements of the business and the possibility for future modification through collaboration and constant feedback. Valuable - well-defined stories must provide a certain benefit (value) for the business. The product backlog is arranged in descending order based on the elements with the highest value. Therefore, it is noteworthy to say that this is one of the most important requirements to the stories. Possibilities for estimation - for each story, the team should be able to estimate the level of its complexity and the necessary work it requires implemented. All further possible estimations for its implementation would improve the predictability within the team. If the team has not reached a consensus on the estimation for the story or if it is unable to make an estimation, this means that the story has not been fully understood by everybody yet or that it is too large. Small - stories should be sufficiently small in order to be implemented within a given iteration. There are even recommendations that a story should not take up more than ¼ of the team's efforts within the timescale planned for a Sprint. 160
Testable - if it is difficult to test a story, this means that it was poorly formulated, it is too complex or it depends on other stories in the Product backlog. Therefore, one should avoid words like rapid, manageable, wonderful, reliable, etc. in the requirements and in the definition of stories, which, if not accompanied by specific criteria for quantification, are very difficult to test. An example of a poorly defined story: "As a user, I would like to be able to manage my advertising spots so that I can remove advertisements that have expired or ones with mistakes." It is not clear here who this user is – whether it is the administrator, a company employee or an advertising agency, i.e. the role of the person to fulfil this function is missing. When defining the Product Backlog, three main tasks are pursued: clarification of the requirements, estimation of efforts and decomposing of large elements from the Product Backlog into smaller stories as a result of their discussion with the participation of the Product Owner, the Scrum Team or the Scrum Master. The meeting for creation of the Product Backlog, like all other meetings in the Scrum methodology, is limited in time. 6.2. Sprint Planning in Scrum The objective of the sprint planning meeting is to provide sufficient information to the team to help it get a clear vision about the work in the next few weeks and to provide the Product Owner with sufficient assurance that their requirements will be fulfilled within the time planned. Usually the meeting takes place in 2 stages - first the specific stories from the product backlog are selected (an answer is given to the question "What should be done") and then, the tasks for each story are defined (how to do it). The resulting information after the meeting includes: purpose of the sprint; list of team members and their level of involvement (in some cases it may be less than 100%); sprint backlog (list of part of the stories from the product backlog selected for implementation in the forthcoming sprint); predefined final date for the spring and defining the time and place for the daily Scrum meetings. Again, in this case, the team, the Product Owner and the Scrum Master should be involved, because each story is related to three variables – scope, estimated efforts and significance (rating). 161
They are very interdependent and are predetermined by the different roles in Scrum. The scope and level of significance are determined by the product owner. The estimation of efforts for implementation of the story is made by the team. During the sprint planning meeting, the priority stories initially identified by the product owner may change their scope and rating after discussion between all people involved. In some cases, the estimation for a certain story will differ from the one expected by the product owner. This may cause him/her to change its rating, which could move its implementation for a later period. The other option is to change the scope of the story, which, in turn, could necessitate additional evaluation of the story, etc. (this process may be repeated several times). The product owner should be involved in the sprint planning. In order to avoid problems, the following strategies may be applied when the product owner refuses to participate: To explain to him/her that his/her direct involvement is essential for the software development; To select a suitable team member to play the role of a representative of the product owner. In this case the product owner should be clear that his/her representative will have the authority to change the priorities of the stories and to change their scope. This means that the product owner should synchronise his/her requirements with the ones of his/her representatives as far as possible. As a last option, if the selected product owner is not willing to participate actively, a new one could be selected, only if the customer and the team management in the software organisation agree to this. It is not necessary for the team to define all the tasks necessary for the implementation of the stories selected from the product list during the spring planning meeting. According to Schwaber
86
it is sufficient to identify about 60% of the tasks
during the meeting. The remaining tasks will be identified in the course of the Sprint implementation. Regarding the sprint duration, shorter cycles (sprints) are sometimes 86
Schwaber, K. Agile Project Management with Scrum. Microsoft Press, 2004. 162
preferred, because of the following reasons: the finished outcomes are obtained at shorter intervals, the availability of finished outcomes that could be evaluated is more frequent, there is more frequent customer feedback and, therefore, less time spent working in the wrong direction, which means that learning and improvement of the development processes is faster. On the other hand, longer sprints are also a preferred option for the Scrum team, because the team has more time for development, correction of problems and for achievement of the spring objective. Also, there is lower chance of hours on tasks remaining unused at the end of the sprint. Therefore, it can be stated that the duration of the sprints is a compromise between the shorter sprints wanted by the Product Owner and the longer sprints preferred by the team. Each Sprint should include an analysis of the requirements, design, development
(coding),
testing,
integration
and even
implementation.
The
development of potentially ready to deliver products within one Sprint is possible by: ‒ improvement of the collaboration techniques (working in a single room, daily meetings and other approaches); ‒ application of modern practices for software development, such as testdriven development, continuous design and ongoing integration; ‒ organising the team around individual features, instead of developing components of the architecture; ‒ checking the code several times per day and elimination of problematic spots; ‒ selection of a small scope of features for implementation within one Sprint. In this way, there will be a lot more time available for integration, testing and elimination of errors. All participants (the team, the product owner and the Scrum Master) should work in coordination during the Sprint, with much more intensive collaboration than traditional teams. The task of the Scrum Master is to prevent the team from being assigned additional tasks by someone (even if that someone is a member of the team or the product owner). If someone wants to add new stories, they are added to the Product Backlog, so that the planned schedule of the Sprint is not interrupted, unless there are 163
special circumstances. When a 30-day Sprint is planned, it is considered that the meeting organised for planning the sprint should have a duration of 1 day. It is essential for the product owner and the team to reach an agreement regarding the definition of “done”. For instance, they should decide whether the story will be considered done when the entire code is checked or whether it will be considered done after installation and integration. There may be a different definition for the different stories and the time of their implementation, but generally, the definitions include meeting of the following conditions: the regression tests after adding the new feature have been successfully passed; the mistaken and poorly structured code has been corrected during the refactoring; there is no duplicate code and all tests have been passed successfully. It is recommended for software companies starting to apply SCRUM, who are not very experienced in defining the cases when a given story is done, to describe the definition of done for each story. "Done" also means a story that was properly tested, refactored and potentially shippable. An important stage of the sprint planning is the further review of the evaluation of stories (in addition to the one performed while drafting the Product Backlog). During the sprint planning phase, when the story is broken down into tasks, it may become necessary to decompose it to substories. Based on this or based on the tasks included, the initially defined estimations of the efforts for the story might need to be reduced. By prompting each team member to evaluate the stories, it is ensured that everyone is clear about them and will provide a justification during the discussion as to why they have evaluated a story as requirement more or less effort. The evaluation of the stories by the entire team is used to analyse the reasons for discrepancies among the estimations of the different team members and, upon discussion, a consensus is reached regarding the final evaluation. It is recommended to hold these discussions as early as possible. It is possible for team members to be influenced by someone else's estimates during the evaluation. The approach that could be applied is using a stack of cards, 164
each of which represents an estimation of the story expressed in points. During the estimation, everyone determines the estimation for the story alone and puts the respective card face down. The cards should be turned face up simultaneously only after all team members have put their estimates. The scale can be from 1 to 10 or another random combination of numbers (for instance, Fibonacci's numbers). If we consider the scale from the first example, values close to 1 will mean that almost no efforts and time are necessary for implementing the story and, respectively, values close to 10 will mean that serious efforts are necessary, the story is more complex or it requires more time for implementation. Another important indicator in sprint planning is the calculation of the focus factor in a previous sprint and using it for estimation of the expected performance. Focus factor = Actual performance / Man-hours available Example: If it is known that the actual team performance in a previous project was 260 hours and that the man-hours available at that time were 360 (e.g. 8 hours (working hours) * 9 days (days in sprint) * 5 team members), then the focus factor will be: 260 / 360 = 72%. Based on this, the estimated performance for the current sprint (CS) can be calculated: Man-hours available in CS * Focus factor from previous sprint In this example, estimated performance = Man-hours available in the current sprint * focus factor from previous sprint = 280 h. * 72% = 202 hours. The focus factor is an estimation of the level of team focus on the tasks. A low focus factor is an indicator of chaos in the team or that the tasks have been evaluated too optimistically (i.e. they need to be re-evaluated). References and Internet sources 1. Pries, K., Quigley, J. Scrum project management. CRC Press, 2010. 2. Schwaber, K. Agile Project Management with Scrum. Microsoft Press, 2004. 3. Kniberg, H. Scrum and XP for the trenches. http://wwwis.win.tue.nl/2R690/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf. 4. http://www.scrumguides.org.
165
Self-study questions 1. What should be the elements in the product backlog? 2. What key tasks are pursued when defining the product backlog? 3. What is the purpose of sprint planning meeting? 4. Define what should be the sprint duration. 5. Define the phases that ach Sprint should include.
166
Chapter 7. EXTREME PROGRAMMING (XP) – CONCEPT, DIFFERENCES FROM OTHER SOFTWARE METHODOLOGIES. THE FOUR CONTROL VARIABLES 7.1. The concept of XP Extreme Programming (XP) is a light and agile methodology for small and medium-sized teams developing software under unclear or rapidly changing requirements. After a number of successful projects in practice, XP was "introduced" in theory with its main principles and practices by Kent Beck in 1999. Although the individual practices comprising XP are not new, they have been collected and combined in a new way, thus forming a new methodology for software development. The core of XP consists of four values – communication, simplicity, feedback and courage, which lay the foundation of the principles and practices for software development that are characteristic for the methodology. The term "extreme" is associated with the extreme level of application of the adopted principles and practices: ongoing review of code (pair programming); ongoing testing (by units and features) daily project improvement (refactoring - changing the initial code, however, without changing its functionality in order to improve the internal quality and obtain a simpler code); maximum simplicity of the design with preserved features; everyone works and reworks the architecture (system metaphor); ongoing code integration; short iterations and constant planning; active involvement of the customer - continuous participation of the customer; but no extreme overload for the developers - 40-hour working week. XP takes two types of commitments – to developers (programmers) and to the customers and managers. Regarding the programmers, the commitment of the methodology is to provide them with the following conditions: to work continuously every day on tasks that are actually important; not to be forced to deal alone with 167
complex situations; to have the opportunity to contribute as far as possible to the project success; to need to take decisions within their competence and never outside their qualification. The commitment to customers and managers is to provide them with the following opportunity: to receive the maximum possible value for each week of work; to obtain specific and usable results they have requested in advance every few weeks; if necessary, to change the direction of the project in the course of its implementation, without incurring huge costs for that. XP is a discipline and the application of the different practices defined by it is mandatory. These are practices that work based on the short-term instincts of programmers and based on the long-term interests of the project. It can be stated that the XP methodology is most appropriate for projects developed by small and mediumsized teams of 3 to no more than 20 members. XP might sometimes startle you at your first encounter, but none of the ideas behind XP is completely new. The new thing here is that these ideas are combined and interact with each other. Some of the main differences between XP and other software methodologies that could be noted are: short cycles and ongoing feedback from the user; method of incremental (stepwise) planning; ongoing testing via tests written by the users and the developers; ongoing intensive communication, periodical discussion of the system structure and objectives; close collaboration among programmers who are not necessarily expected to have exclusive capabilities. In XP, the function of the price of changes is not exponential; on the contrary, it is very close to linear. In other words, the traditional belief that the later the changes are introduced in the development process, the more costly they will be. XP allows and recommends to postpone changes, because it is believed that if a certain change is done later, the chances that this change will satisfy the user will increase. The ground for that are the practices offered by the methodology, such as simple design and 168
intensive automated tests. 7.2. Main problems in software engineering and how XP deals with them Each software company is faced with a number of problems in the course of development, part of which often turn out to be fatal for the development of the project. Usually, problems are considered from the perspective of the likelihood of any of the following situations: interruptions in schedule – it is often necessary to inform the customer that the deadline planned cannot be met; project termination – because of different reasons, the production needs to be suspended; the product turns out to be too expensive to support – therefore it is necessary to decommission it ahead of time; the level of defects – the bugs during operation are so many that it is impossible to use the product; lack of understanding of the business objectives – the business objectives initially set by the customer were not understood and have remained unaddressed as a result; change in business – the product has been commissioned, but the business issue it offers a solution to has changed in a few months and the product has become useless; unnecessary features – interesting features have been implemented in the product, which, however, turned out to be completely useless for the user; staff turnover – most programmes leave over time because they lose interest to the tasks, because they are not satisfied with their remuneration or due to other reasons and there is no staff to support the software product developed by the company. Regarding the first problem related to the interruptions in schedule that is characteristic for software development, X
imposes short production cycles
(releases), rather than longer ones of a small number of months. Within one release, iterations of 1 to 4 weeks are applied, and tasks of 1 to 3 days are planned within each 169
iteration. In this way, the decomposed schedule is subject to more accurate planning and less interruption. In order to decrease the risk of project termination, Х
requires from the
customer to select the closest practical objectives for implementation by themselves. XP requires the creation and maintenance of a solid set of tests which are executed and repeated after each group of changes. In this way, it is less likely that the product will turn out to be too expensive to support during the last phases of development. Regarding the level of defects, XP's tool to cope with this problem is the joint creation of tests by features by the customer and the developers. Х requires that a representative of the customer becomes an integral part of the developers team during the entire period of development, which significantly reduces the risk of lack of understanding of the business objectives. Because of the shorter cycles and active involvement of the customer, the latter has the chance to define new features or change a feature that has already been specified numerous times, which is a tool to overcome the problem of frequent change in business. In order to reduce the likelihood of creating unnecessary features, Х requires sequential implementation of features by implementing first the features of highest priority according to the customer. XP fights staff turnover by focusing on the personal responsibility of the developers, by providing them with constant feedback on the observation of the preliminary estimates with respect to time, by setting fixed rules who, when and how could make changes to the programmes, by promoting interactions within the team and by providing incentives for new team members.
7.3. The four control variables XP has defined four control variables on which software development is based cost, time, quality and scope. There are two main groups that attempt to benefit from and influence the four variables in a different way: externalities – customers and managers and internalities – developers. Neither externalities, nor internalities, however, could optimise the four variables simultaneously. On the other hand, the variables themselves also have certain 170
interdependencies. Regarding the cost, the allocation of Х times more money for Х times more programmers does not make much sense. It does not necessarily yield X times less time for production (maybe just a little less and only in certain cases), it does not increase the product quality X times (actually it might be the contrary), it does not expand the system functionality X times (often this is unnecessary, not useful or even harmful). Managers tend to overestimate the significance of money for the production process. Yet, larger financial resources could improve the conditions for work computer equipment, tools office environment, etc. Larger investment could also lead to improvement of the quality of work to a certain extent, to a reasonable expansion of the scope and to more rapid market launch of the product. The pressure and limitation with respect to time often come from outside. For example, the usual requirements for the deadline - at the end of the month, at the end of the quarter; deadline associated with replacement of old software; deadline related to a fair or exhibition; information about market launch of a competitive product in the short term. Although this is usually an "external" impact, the most crucial ones among these external factors are customers and not managers. Quality on the other hand defines the level of compatibility of the product or service created with certain standards and criteria. Quality is a variable with specific behaviour. It is naturally expected that the efforts to increase quality should lead to certain delay in programming, i.e. in the entire production process. However, often the requirement for higher quality results in exactly the opposite - acceleration of production. For example, the requirement for higher quality can be satisfied with more intensive testing. The outcomes from the tests, on the other hand, can result in acceleration of programming. Similarly, the quality requirement may impose certain coding standards. They usually result in acceleration of programming. Sometimes it is believed that the external quality (i.e. the quality from the user's point of view) would not suffer much if no sufficient attention is paid to internal quality (i.e. quality from the point of view of programmers). This is absolutely untrue, 171
because no accelerations in the development process are possible at the expense of the software quality characteristics, without harming the product quality, i.e. the quality from the user's point of view. Maintaining a high level of quality also has a psychological effect. Everyone wants to do their job well. On the other hand, successful work is an incentive for even better work. By contrast, if the quality declines because of lower number of tests, neglecting the inspections or because of another reason, there may be temporary acceleration. However, in any case, the temporary benefit will lead to demoralisation and demotivation of programmers in the long run. Most managers recognise the role of cost, time and quality and the importance to manage these. Many of them, however, do not realise the importance of the scope. From the perspective of XP, the scope is the most important control variable. Furthermore, when we intentionally change the scope, we directly influence the other 3 variables. The main problem with the scope is that in most cases it is unclear - the user does not realise, especially at the start, the exact feature they need. Practically, when the user sees the first implemented feature, they understand what the next one they need is and, sometimes - what the first feature should have been. A good method to turn the scope (i.e. the requirements toward the product) from a problem to an opportunity is by: actively and continuously involving the customer in the production process; requesting the customer to define their priority features in sequence and implement them in this order and by constantly evaluating what has been achieved, including by accounting for the customer's opinion. This actually means constant, albeit slight, and targeted changing of the scope. This would make the process controllable, even if the other 3 variables are fully fixed. It can be concluded that the four discussed variables influence each other to some extent. For example, if the project scope is increased, the costs and time for development could also increase disproportionately. Or, if the planned project budget is cut, this might result in the need to compromise with quality or to reduce the system scope, which, in turn, could lead to reducing the necessary time for implementation of the project. Therefore, maintaining a balance between the variables is an important and 172
challenging task, which should also consider the positions of the two parties - the customer and the developer.
References and Internet sources 1. Eskenazi, A., Maneva, N. Software engineering. KLMN, Sofia, 2006. 2. Beck K., Embracing Change with Extreme Programming, Computer, October 1999, Vol.32, No 10, p.70-77. 3. Beck, K., Extreme Programming Explained. Addison-Wesley, 2000. 4. Beck, K., M. Fowler, Planning Extreme Programming. Addison-Wesley, 2001. 5. Wake, W, Extreme Programming Explored. Addison-Wesley, 2002. 6. Jeffries, R., A. Anderson, Ch. Hendrickson. Extreme Programming Installed, Addison-Wesley, 2001. 7. http://www.extremeprogramming.org/
Self-study questions 1. What are the four values in XP? 2. What mean the term extreme? 3. What are the main differences between XP and other software methodologies? 4. What are the four control variables in XP? 5. Do the four variables influence each other? Explain how.
173
Chapter 8. THE FOUR FUNDAMENTAL VALUES OF XP. BASIC AND LESS CENTRAL PRINCIPLES IN XP 8.1. The four fundamental values XP is characterised by application of a certain number of well-defined practices. Before they are defined, however, there is the important issue of fundamental values the method is based on. This enables to check the compatibility with these values of each defined practice and to reject it if there is no such compliance. 8.1.1. Communication Often, it turns out that the problems with the implementation of a software project have occurred because of the following reasons: someone from the team did not discuss an important problem with someone else from the team; a programmer did not communicate an important change he/she has made to the programme; a programmer did not ask the customer an important question and an entire feature was left out; sometimes the manager has failed to ask the programmer about something important and this lead to non-fulfilment of the deadlines. All this is a sign of poor communication. The reasons for this might be different, such as: the programmer has told the manager some bad news and the latter punished him/her; the customer said something important to the programmer, however he/she does not have the habit of listening to the customers' words or none of the managers in the company has though about the issues related to communication. XP imposes good communication through several specific practices that are not possible without it: unit testing, pair programming, evaluation of the performance of the individual tasks. These practices alone have short-term objectives but also achieve a long-term objective - good communication in the team becomes predominant. This does not mean that there is always good communication when XP is practised. Even if they have the good habits, developers sometimes make mistakes, 174
they are distracted or simply in a bad mood. One of the manager's tasks is to capture these moments and undertake corrective actions. 8.1.2. Simplicity One of the most important questions the manager asks to programmers is: What is the simplest thing that will function in this case? It is a known fact that simplicity is not easy. On the contrary – the expression "genius simplicity" is not accidental. The main strategy of XP is: to make something simple today, even with the risk of more efforts needed tomorrow to change it, instead of making it complex today with the risk that there will be no need to change it (i.e. you will not use it) tomorrow. 8.1.3. Feedback Timely feedback on the ongoing product status is absolutely necessary. Almost every programmer suffers from the professional carefree optimism that a certain programme component "might not work" or that a certain test "will surely pass". Feedback works at different levels and at different timescales. Unit testing is performed within minutes, the results are known on the spot and this is exactly what immediate feedback is about. Things become a bit slower when the customer writes another "story" and when programmers discuss and evaluate this. This is followed by a feedback on the compliance with the personal schedule, which is usually within one day or more. The feedback on the overall schedules is performed no more than once a week. The feedback from the acceptance tests is also not very frequent. Feedback is at the core of one of the basic strategies of Х – gradual provision of features starting from the one that is most important for the user. Upon each such delivery, feedback is received almost instantaneously, on: the quality of the technological solutions taken, the user satisfaction, the feasibility of the resources planned and the quality of communication with the user. The feedback is an integral part of communication and simplicity. It is true that part of the data from the tests originate directly from the system. However, they would make no sense, if they are not interpreted by people interacting with each other. The feedback from the tests is the best evidence for achieved simplicity of the design and programming.
175
8.1.4. Courage The psychological aspects of software development are rarely explored, which does not mean they are not present. Many decisions require courage. If the programmer has devoted 6 hours to write a system unit and understands from the tests during the next 2 hours that things are not the way they should be, it takes courage to destroy the written programme (in some cases) and start over again on the next day. The practices of XP require constant decision-making both by managers and developers, regarding: - the choice of "stories" proposed by the customer; - the border of project simplicity and the code; - postponement of changes; - improvement of the "alien" code; - "pressuring" the customer with respect to their tendency not to be as active as the developers; - the moment of integration of the next new unit. All these decisions, like many others, require courage. It is clear, however, that courage would make no sense and would be of no use without the other fundamental values - communication, simplicity and feedback. Apparently, there is one more value – respect to the other members of the team. The consideration of the XP practices shows that XP is characterised by particular sensitivity to mutual respect and recognition. 8.2. Basic principles The four values of XP discussed above seem too general and therefore they are further detailed into 5 basic and 10 less central principles. The basic principles are: rapid feedback; assume simplicity; incremental change; embracing change and quality work. Rapid feedback. It is clear that the time between the action and the feedback (response) is essential for learning. The same applies to extreme programming - the basic principle is to receive the information from the feedback, its interpretation and respective revision as soon as possible. 176
Assume simplicity. Classical methodologies recommend to contemplate on the repeated use of the designed and programmed code. Х
requires to design and
programme without having this in mind and to be as simple as possible instead. The principle of XP is to make things as simple as possible, however, to thoroughly test them. It is relied that if adding a new feature or enhancement is necessary in the future, these will be implemented successfully. The problem of XP is to overcome the tendency of most programmers to put a lot of effort in obtaining a code that is good for reuse. Incremental changes. XP believes that large changes made at once are impossible or at least inefficient. The principle of XP states that things should be done gradually with small changes. This principle applies to different activities: design with small changes; planning at small increments, small changes in the team of programmers, gradual introduction of the XP methodology. Embracing change. According to the XP methodology, developers should: always work on the problem with the highest priority; at the same time, they should consider the introduction of any type of change at each stage of the development. Quality work. This principle is evident and could not be denied. Sometimes there is a problem with the quality assurances practices neglected by some programmers. Yet, XP does not require application of the complex quality assurance measures that are characteristic for classical methodologies. 8.3. Less central principles The less central principles defined by XP that could help us decide how to act under specific circumstances are: teach learning; small initial investment; play to win; concrete experiments; open, honest communication; work with people's instincts, not against them; accepted responsibility; local adaptation; travel light honest measurement. Teach learning. Each practice in XP is prescribed in exact terms and is based on the need of it. When this is not possible or disputable - the organisations applying it 177
have the opportunity to decide for themselves whether to use it. Small initial investment. It is accepted that large initial investment is unreasonable and leads to failure. According to XP, tight budget is a good option encouraging the most efficient utilisation of the resources available. On the other hand, too much limitation in the disposable funds makes the project implementation impossible or difficult. Play to win. Similarly to other fields (e.g. basketball), 2 main strategies are possible in software development: 1) playing not to lose and 2) playing to win. The first strategy is characterised by: too much formalism, increased documentation and excessive bureaucracy of the management. The objective is to insure against failures, however, this is always related to increased costs or delay of the development process to some extent. XP firmly supports the second approach - to take certain risks in order to achieve higher efficiency. Concrete experiments. The preceding strategy meant constant decision-making. Each decision carries some risk. Reducing the risk is possible if the subject of the specific decision is, for instance a certain requirement, is checked through a series of experiments answering all questions that have arisen during the design. Open, honest communication. This principle is a direct reflection of the first fundamental value (communication). The developers should be able to: Explain their own mistakes and the others' mistakes they have noticed with no reservation; to be able to communicate bad news to their managers and customers; to express their fears freely; to require support from the others and they should not be punished for anything of these. Work with people's instincts, not against them. People like: to win; to learn new things; to communicate with others; to be part of a (successful) team; to know that others trust them; to rule the situation. Software developers strongly want their programmes to work. The good manager should be aware of this and should not confront him/her but use this for the purposes of the project. Actually, the practices of XP are generally in line with these instincts, trends and preferences. Аccepted responsibility. XP prefers that tasks are not assigned, however, this means that there shall be a certain level of personal responsibility by each team 178
member. Therefore, there shall be no top-down planning (assigning of tasks) and everyone should accept that what has been planned should be implemented within the given period after a general discussion. This principle does not mean that everyone will do only what they like, since there will always be hard and unpleasant tasks. Actually, it is because of them that responsibility should be accepted by everyone. Local adaptation. The working conditions are "local" in a different sense. They depend on the characteristics of the region, the country the company operates in and the rules established in the company. The practices of XP are fixed. Despite this, there are still too many levels of freedom that should be used, depending on the local conditions, because the process of development is individual in each company. Travel light. This is a metaphor used by Kent Beck. "We should travel quick and travel light". This principle means that we should be equipped with a small number of objects with high value at each stage of the project. This is necessary because of the prominent dynamism in software development, where the customer requirements rapidly change and often change in an absolutely unexpected direction. Honest measurement. XP requires too many measurements - of deadlines, resources and results. In many cases, the instruments available do not offer the required accuracy. It would always be good to be able to tell: "This unit should be programmed and tested for 8 days and 5 hours." If we talk about the first "release", probably the best thing we could say is “from 6 to 10 days". For the next release, probably based on the experience we have acquired, it will be already possible to define it more accurately - "8 or 9 days". But we will hardly be ever able to define that we need exactly "8 days and 5 hours". Thus, in any case, the measurement should be sufficiently accurate, but also honest. References and Internet sources 1. Eskenazi, A., Maneva, N. Software engineering. KLMN, Sofia, 2006. 2. Beck K., Embracing Change with Extreme Programming, Computer, October 1999, Vol.32, No 10, p.70-77. 3. Beck, K., Extreme Programming Explained. Addison-Wesley, 2000. 4. Beck, K., M. Fowler, Planning Extreme Programming. Addison-Wesley, 2001. 5. Wake, W, Extreme Programming Explored. Addison-Wesley, 2002. 179
Self-study questions 1. Why communication is so important in XP? 2. Describe the correlation between the four fundamental values and the five basic principles. 3. Explain the meaning of incremental changes. 4. What are the ten less central principles? 5. Explain what does travel light principle mean in your opinion.
180
Chapter 9. 12 PRACTICES IN XP 9.1. Concept of the 12 practices The method of application of the XP methodology is defined and specified by 12 practices that are based on four main activities – coding, testing, listening and design. Regarding the need to apply absolutely all practices, it is possible to only use some of them, based on the discretion of the respective software organisation. In most cases, it is considered that the uses from them will be far greater when they are applied together. 9.1.1. Planning Game No comprehensive documentation is kept, but a planning game is organised. For example, the main requirements are described in small notes, primarily in the form of stories. Although it is the customer that should define these stories, including the different test scenarios, complex tests require the involvement of testers. The following is necessary for each story: to identify the non-functional requirements - usability, performance, reliability, etc.; to determine the costs for its implementation; the time it will take; how many people will be necessary for its implementation. Neither business, neither technology should prevail in the planning. The software product is a compromise between what is wanted (by the business) and what is possible (for the developer). The plan is the result of the dialogue between the customer (business) and the developer (technology). The customer has a say on: The scope - what part of the entire problem should be resolved in order to make sense for the business, because the customer knows best where the border between the necessary and the unnecessary is. Priorities - as a rule, the customer decides which of the 2 tools should be implemented first.
181
Content of the release - after defining the priorities, the customer is more clear what should be included in the specific release in order to derive the maximum benefit; often the programmer's intuition in this regard is wrong. The periods of the release - what is the reasonable period after which the effect of the software introduction would no longer be so significant. Yet, the customer cannot take these decisions alone, without accounting for the technological factors. The developer has a say on: The evaluation - how much time the implementation of a feature will take. The consequences - each technological solution (selected language or database management system or search engine) leads to certain consequences that can be clarified only by the developer. The process - how to organise the work and the team based on the technological choice made. The detailed schedule - in what sequence should the individual features (stories) of a release be implemented; usually programmers develop the elements involving more risk first, by taking into account the business priorities. 9.1.2. Small releases The main idea of this practice is rapid launching of a simple system and then launching some small additions in short intervals. The necessary conditions for this is the most valuable services (features) from the user's point of view to be defined based on their priority. Another requirement is to perform continuous integration, which makes the finalisation of the release relatively rapid and cheap. Each release must meet 2 (contradicting) criteria: to be as small as possible and but still meaningful as a whole (i.e. to implement a certain complete feature). XP considers that planning and respective implementation for month or two ahead is better than planning for six months for example. Short intervals are preferred, because if there are any errors, they will be present for a short period and a quick response will be possible. Each new release usually constitutes a new product version or new service packs added to the existing system. 182
9.1.3. Metaphor The metaphor in XP in a sense replaces what is called "architecture" by traditional methodologies. The term metaphor is used in order to highlight that it should be simple and understandable for both parties (the customer and the developer). The technical terminology should originate from the metaphor. The metaphor evolves together with the development process. Examples of metaphors: 1) If the final product is a system for recipes, a suitable metaphor would be a cook book; 2) If the final product is an online shop, an appropriate metaphor could be a shopping cart. The first question is what the objects and operations associated with the selected metaphor are. Some more specific questions around the second example of a metaphor could be: who fills the cart, what it is filled with and in what order; what happens if the item searched for the cart is not available; can an item be returned from the cart to the stand; where the filled cart goes; who charges for the selected items and how; how the charge is documented; what the payment method is, etc. There are cases when the metaphor might require some limitations, i.e. when it should not reflect all aspects of the application. Sometimes, it is possible to have a metaphor that is too "naive", i.e. not a metaphor, but an almost straightforward description of the development. Another undesirable situation is to have a metaphor that is understandable only for one party, for example the "t-ledger accounting" in most cases would be understandable only for accounting specialists and not for all developers. 9.1.4. Simple design The system should have a simple design at any time. In particular, this means that there should be no duplication in logic; there should be no excessive elements; it should reflect all intentions of the developers and it should contain the minimum number of classes and methods (XP primarily focuses on objective orientation). Also, the practice is that no extra effort should be put to make the project too detailed with respect to the future evolving of the development. The main reason for this is that XP adheres to the understanding that it is very difficult to predict the future and therefore we should mostly focus on solving the tasks of today. 183
9.1.5. Testing There is no programme without automatic tests. Programmers write unit test in order to make sure that the programme works correctly. The customer writes functional tests in order to make sure that the feature required by them is implemented. The tests should be detailed within reasonable limits. However, it is not possible to write a test for each individual method; tests should be primarily written for the ones that might not work normally in some cases. Also, it is often common to apply writing unit tests first and then coding. The successful completion of one or more tests creates positive feelings in programmers and is a positive incentive for the project development. 9.1.6. Refactoring Programmers add new functions to the programme section they have already written. Then, they try to simplify what they have written without interfering with the completion of the tests that have already been successfully launched, i.e. there is continuous restructuring of the system without changing its behaviour. This is the essence of refactoring, which usually does not require too much additional effort. Classical methodologies do not recommend such dynamism because of the difficult management and certain loss of time. Yet, refactoring is not an end in itself. If it turns out, for example, that adding a new feature necessitates duplicating part of a code that has already been written, most probably refactoring will be necessary. On the other hand, however, if a programmer sees how he/she will roughly achieve the test completion in 1 minute and, at the same time, how he/she can achieve the same with a more elegant approach and simpler design in 10 minutes, it is recommended to choose the 10-minute approach in order to obtain a simpler and more elegant design. 9.1.7. Pair programming Two people write on one computer with one keyboard and one mouse. They have two roles. One of them, called driver, thinks specifically - how to write this method at this place in the best possible way. The second participant, called navigator, has more strategic thinking: will the overall approach work, which additional tests 184
might fail, is there a way to make a general improvement, so that the respective section becomes simpler or completely unnecessary. Working in pairs is dynamic. Changing the roles within the pair is common, even within one day. It is possible for one or more pairs to be composed of different members within the day. If a certain programmer is assigned a task they feel somewhat insecure about, he/she can request that the second programmer is someone with suitable experience. Developers that prefer to work independently instead of working in a team or those that want their achievements to be distinguished and noticed are usually unsuitable for an XP team. 9.1.8. Collective ownership The entire code belongs to all programmers. Anyone can change anything, however, they all should write the code in uniform style, based on the same rules. It is important to have changes of roles, so that the project could continue if someone is missing. The standard model is individual ownership over the code. There has also been a model with complete lack of ownership, however, it was not effective because of the lack of responsibility in the individual programmers. In the case of individual ownership, on the other hand, no interference by other people is allowed, which often leads to loss of connection and mutual understanding between the programmers. XP requires each programmer to be responsible for the entire system. Of course, not everyone is equally familiar with the entire code. Everyone, however, knows the entire code to sufficient extent. This enables targeted intervention by everyone if a need and possibility for improvement is felt. It is recommended to implement changes at reasonably short intervals (not continuously) in order to allow more time for resolution of eventual conflicts. Also, in this way the risk of errors or lack of understanding is reduced because all developers follows established coding standards (see practice 12). 9.1.9. Continuous integration Continuous integration means integration several times a day. There is one computer where the integrated system is located. Every day, the entire code is 185
extracted automatically from the source control system, it is compiled, all tests are performed and it is integrated. By definition, automatic tests have a success rate of 100% there. Everyone (each pair) that adds their own code to the existing system must achieve 100% success again. If they fail, they should try to fix things alone or request support from other programmers. In case of a failure in both cases, they should return the system to the original state before their intervention. 9.1.10. 40-hour week A 40-hour week does not necessarily mean 40 hours of work by everyone absolutely every week. On the one hand - it is possible to have up to 1 week (but never more than that) with increased workload. On the other hand - sometimes 40 hours actually means 35 hours (for some countries with such regulations). The main idea is that each systematic overload results in long-term decline in performance with all the ensuing consequences. The method of organisation of the activities in XP helps to remove stress caused by unrealistic schedules, lack of vision what happens, concerns about the quality and that something might go wrong after the final integration. Breaks are also related to that. Kent Beck supports the European habits of taking breaks of 2 to 4 weeks. In the USA it is common to have breaks of several days – Х recommends a breaks of 2 weeks altogether plus another 1-2 weeks for short breaks. Furthermore, it is recommended that 4-5 hours of those 40 hours a week are devoted to trainings, seminars and other activities that are different from the specific work on the project. 9.1.11. On-site customer The real customer should: always accompany the developer; respond to his/her questions; define the priorities for subsequent implementation; discuss the emerging problems; 186
write acceptance (functional) tests. Х
requires the team to include a real, available, active and full-time
representative of the customer. The problem is that if it is necessary to provide a customer representative that will be most useful for the developer, then this person is also very useful for the customer and the customer does not allow him/her to work with the developer. Actual projects show that this is the most difficult practice to implement out of the twelve practices. The managers of the customer are still unable to realise that sending a highly qualified representative to the developer will "pay back". Some of them are not ready to even send a "second hand" representative. Therefore, it is necessary to explain to the customer that the lack of his representative increases the risk of lack of understanding of his requirements, extension of the deadlines and completing the releases in the wrong sequence. 9.1.12. Coding standards A large part of practices require very good mutual understanding and communication, such as: pair programming; refactoring; simple design; collective ownership and continuous integration. A necessary condition for this purpose is to follow pre-defined rules (conventions) for writing documentation and particularly for writing programmes: ‒ identification of objects; ‒ communication of parameters; ‒ rules for writing comments; ‒ rules for shaping the programme structure. Like most of the other methodologies, XP requires programmers to write the programme code in accordance with well-defined rules. Regardless of the natural tendency of developers to be individualistic and not to obey the rules created by others, experience has shown (irrespective of the methodology) that (consciously or not) they learn to keep discipline in this regard.
187
Self-study questions 1.
What are the four main activities in XP?
2.
Define the twelve practices in XP.
3.
What are necessary conditions for achi ving small releases?
4.
Why system should have simple design at any time?
5.
What does Collective ownership practice mean?
References and Internet sources 1. Eskenazi, A., Maneva, N. Software engineering. KLMN, Sofia, 2006. 2. Beck, K., Extreme Programming Explained. Addison-Wesley, 2000. 3. Beck, K., M. Fowler, Planning Extreme Programming. Addison-Wesley, 2001. 4. Wake, W, Extreme Programming Explored. Addison-Wesley, 2002.
188
Chapter 10. PLANNING IN XP. DEFINITION OF REQUIREMENTS. RELEASE PLANNING 10.1. Planning in XP Planning in XP is an incremental process. First, a general plan is rapidly drafted. Based on this plan, the most significant and the smallest set of requirements (stories) that should be implemented based on the customer expectations and the deadline agreed with them is identified. Then, the plan is improved in short intervals. The main objectives of planning are: to bring the whole team together and to involve it actively from the very beginning; to outline the scope and priorities, to define the budget and the schedule in advance and to define the methods for ensuring feedback. Some specific principles are observed in planning: Short-term planning: based on the level of planning or up to the next release or the next iteration. It is recommended to also make a general plan of the next steps (releases and iterations). Taking responsibility (additional core principle 7 in XP): responsibility is not assigned, it should be accepted by everyone. In other words, there is no assignment of tasks by superiors (in the hierarchy, for instance). Everyone accepting a task to implement should first evaluate the resources needed and the necessary time for implementation. Ignoring interdependencies: priorities play the key role; they are planned in detail and the features (stories) identified as priority are implemented; the remaining ones are ignored at this point. Planning of the priorities (defined by the customer) is far less detailed than planning the development process, particularly the part about testing, where numerous tests are mandatory. 10.2. Definition of requirements 10.2.1. Main concepts Each new software product requires initial analysis of the subject field before undertaking the planning of the different activities and processes. 189
Business analysis is a set of tasks and techniques used as a linking unit between the stakeholders and has the purpose of understanding the structure, policies and processes within an organisation and to propose solutions that enable the organisation to achieve its objectives. Business analysis focuses on defining the needs of the business and on proposing solutions on this basis, which are in line with the limitations set (including time, budget, rules, etc.). The solutions can be related to the introduction of a software system, improvement of the existing business processes or another organisational change. The scope of the solution (or the scope of the product) is the set of possibilities the software solution should provide in order to respond to the needs of the business (customers). It includes the characteristics, properties, features and services that need to be developed. It is related to anything associated with the implementation - what the final product should look like, how it should function and all the other characteristics. Usually it is implemented by the business analyst in collaboration with the customer. The scope of the project is the work that needs to be implemented in order to implement a specific software solution (usually prepared by the project manager). Often, the business processes and the scope of the product are determined at a very high level. For example, the scope can be defined with this statement: "Application of Purchases SAP module". This definition makes it impossible to tell what the exact business activities and functions lie within or outside the scope. The strategic objective of defining the scope is to put a certain focus. The following requirements regarding the individual definitions should be observed in the identification of the product scope: 1. They should be clear and concise. 2. They should include a short description that clarifies the respective business processes. 3. They should be arranged in order of their defined priority. 4. They should serve a specific business objective. 5. They should focus on the software solution itself, not on the work that needs to be done (this is done when the project scope is defined). 190
The requirement is a condition or possibility that needs to be fulfilled by a certain software solution or a component thereof in order to satisfy established contracts, standards, specifications or other formal documents. 10.2.2. Types of requirements According to the publication of the International Institute of Business Analysis Business Analysis Body of Knowledge 2.087 (BABOK), the types of requirements are: Business requirements; Customer (or user) requirements; Software product requirements; ‒ functional requirements; ‒ non-functional requirements; Transition requirements. The business requirements describe the benefits the organisation or its customers expect to obtain from the implementation of the software project. The business requirements can be documented in several forms - as a separate section (clause) of the project, as a business scenario, as a project vision o r in the form of description of the product scope. Usually they are in the form of: description of: problematic issues; project vision; project limitations (budget, schedule, resources); business objectives; project scope (possibilities); analysis of the business processes and analysis of all stakeholders (users). The user requirements describe what the users will be able to do by using the system. Stories or scenarios are used to define them. They should be defined in a clear and understandable way. The functional requirements describe the processes and information that will be managed by the software solution. All functions expected by the customer need to be defined, without any conflicts between them. Non-functional requirements define the conditions that are not directly linked to the system functionality, but rather to the inherent conditions related to the system performance, reliability and quality. Therefore, they are sometimes called quality 87
A Guide to the Business Analysis Body of Knowledge (BABOK Guide), . 191
requirements or additional requirements. Example for such requirements: loading speed, security and user interface. The requirements regarding changes describe the possibilities for the software product to support changes from the current status within a company to the desired future status. However, after these changes are implemented, these requirements are no longer necessary, i.e. they are temporary. 10.2.3. Tips for defining the requirements Avoid long descriptions and too much detail - they should not be like a novel; Avoid uncertain phrases, such as "if necessary" - they make the requirements useless; Avoid the inclusion of too many requirements in one paragraph (usually recognised by the word "and" in between); Avoid hypotheses; Avoid words like usually, mainly, often, normally, typically; Avoid words like "friendly", "flexible"; Avoid wishful statements, like: 100% reliable, works on all platforms, never fails, possibility for upgrading to all future situations. An example of poorly defined requirement: "The account number should be validated online based on a controllable list of corporate account numbers, if possible". This requirement can be revised as follows – "The system should validated the account number entered based on a controllable list of corporate account numbers. If the number is not found in the list, an error message should appear and the order should be rejected". 10.3. Release planning The main objective of the software process, including planning, is to maximise the value of the final software product. This should take into account the cost of the development and the level of risk assumed. The ideal strategy for the team would be to achieve the most valuable functionality possible (for the customer) with the most rapid integration possible, with 192
design and programming strategies that carry the lowest risk. These contradicting requirements need compromise and priority setting. Release planning consists of three phases: Exploration Commitment Steering Each phase has its typical activities, however, it is also possible to implement certain activities defining a given phase into another phase. For example, writing stories is typical for exploration, but it can also happen during the steering phase. 10.3.1. Exploration The objective of the Exploration phase is to reveal to the players what the product will actually do. It consists of three actions: Write a story – the customer writes stories (functional requirements that the product should meet) at any time and arranges them according to their importance and significance (with sufficient detail, so that the developers can determine the costs to allocate for it). It is most often done on story cards or sticky notes. Each card has a name, index and brief description. Estimate a story – the developers review each story and estimate the time necessary to implement it. The estimation is made by identifying the "perfect time for development" - i.e. by assuming lack of any other commitments - other stories, meetings, interruptions. One perfect week is equal to three actual weeks. Later (during the next phase, action three) this perfect time is transformed into real time. Split a story – sometimes the developer finds that the story is actually more than one story based on its volume or logic. Also, it is possible for the customer to decide that one complete part of the story is more important than another. In these cases, the story is decomposed into two or more parts. 10.3.2. Commitment The purpose of this phase is to enable the customer to select the scope and date of the next release and to enable the developer to commit to the implementation in a justified and confident manner. It consists of four actions: 193
Sort by value - the customer sorts the stories into three groups (three stacks of cards): stories the product would not be able to function without; less important, but still necessary; stories that would probably be useful. Sort by risk – the developer sorts the stories into three groups: stories that have been accurately estimated; stories that have been estimated relatively well; stories that could not be estimated at all. Based on this, the developer implements them in an order that puts the stories that are more important for the customer at an earlier stage in the plan. The risky stories are also moved at the beginning of the plan. Set velocity – the developer communicates the performance to the customer (allocation of points to each story based on the efforts required) that will be achieved under perfect and under real circumstances. Choose scope – the business chooses the stories to implement in the next release by selecting the final date and, based on this and the velocity communicated to the customer, it selects the stories or the set of stories (cards) and, based on this and the velocity – estimates the final date. 10.3.3. Steering The purpose of this phase is to update the plan if necessary based on the results from the current development. It consists of four actions: Iteration - each iteration lasts from 1 to 3-4 weeks. At the beginning of each iteration, the customer selects the most valuable stories for them to be implemented during this iteration. At the end of the iteration, the stories should be completely working, although the system may not be operated actually. Recovery - at a certain point, the developer may find that he/she overestimated something or that unforeseen circumstances have occurred. Then he/she should request from the customer to define the stories to remain in this release and the ones to go to the next release. New story - even during the implementation of the stories, the customer may decide they need a new story. Then the customer writes it. The developer estimates it he/she defines the necessary efforts, re-estimates the risk and defines the priority. The 194
customer removes the stories planned for this release that require equivalent effort to the new one. Re-estimate Estimation may turn out to be more difficult than described in the "Recovery" action above. In this case, the developer can estimate that the actual development deviates substantially from the plan followed. Then, he/she should reestimate the remaining stories and propose a new plan by the end of this release. If the plan is not sufficiently accurate or clear, everything goes back to the initial phase of estimation of the stories in order to decompose them, set priorities or define risks. References and Internet sources 1. Eskenazi, A., Maneva, N. Software engineering. KLMN, Sofia, 2006. 2. Amber, S. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. John Wiley & Sons, 2002. 3. Beck, K., Extreme Programming Explained. Addison-Wesley, 2000. 4. Leffingwell, D. Agile software requirements. Addison-Wesley, 2010. 5. Hull, E., Jackson, K., Dick, J. Requirements engineering. Springer, 2010. 6. http://www.p2080.co.il/go/p2080h/files/4071469962.0.pdf.
Self-study questions 1.
What are the specific principles observed in planning?
2.
Describe what types of requirements do you know?
3.
What is the difference between the scope of the solution and the
scope of the project? 4.
Define what should be the iteration duration.
5.
Define the phases of the release planning.
195
Assoc. Prof. PhD Silvia Parusheva Assoc. Prof. PhD Kolyo Nestorov Chief Assist. Prof. PhD Olga Marinova
Electronic Business 2nd Part Software Development Management Editor Assoc. Prof. PhD Silvia Parusheva Reviewer Prof. PhD Vladimir Sulov ИК 9.9 Publishing house „Science and Economics” University of Economics – Varna ISBN 978-954-21-0837-5
196
