Software Development Process Improvement At Tiptop-ICT

(1)

Software Development Process Improvement

At

Tiptop-ICT

Gerben Teitsma January 2007

University of Groningen, The Netherlands

Master Business Administration, Business & ICT

Supervisors:

T. W. de Boer

Faculty of Management and Organization, University of Groningen A. Foreman

Manager Development, Tiptop-ICT

Co-assessor:

J.H. van Uitert

(2)

Preface

For my master study ‘Business Administration - Business & ICT’ at the University of Groningen I started my thesis project in September 2006. I have completed my master thesis in a practical setting at Tiptop-ICT in January 2007.

The thesis took place at the Business Unit Software within Tiptop-ICT. I want to thank my supervisor Adrian Foreman for the support, discussions, and answers. Furthermore, I want to thank the many colleagues within Tiptop-ICT for their help and cooperation, despite their busy schedules.

Thomas de Boer provided the input of the University of Groningen for my master thesis. His theoretical insights, knowledge, support, and feedback about the subject were very useful and constructive. I would like to thank him for the effort and time he put into this thesis.

Furthermore, I would like to thank Hans van Uitert for the feedback of the final draft. Finally, I would also like to thank my family, friends, and students for their advises and support.

The result of my thesis is this final report; I hope you will enjoy reading it. Gerben Teitsma,

(3)

Management summary

This research paper reports about the results of my graduation thesis at the Business Unit Software at Tiptop-ICT. The motive for starting this research is that occasionally the

functionalities of developed systems differ from the functionalities required by the customer. In addition, errors are found in a late phase of the process; therefore, reworking parts of the system is very expensive and time-consuming. The research question for this research is:

Which problems can be detected in the software development process at Tiptop-ICT, and how can the software development process be improved in order that developed systems better meet the customer’s requirements? In order to provide an answer to this question and to describe the current situation of the

software development process, interviews are held with employees of the Business Unit Software. The research indicates four problem areas at Tiptop-ICT. Following, this report describes the theoretical insights concerning the problem areas. These provide the basis to analyse and judge the software development process at Tiptop-ICT and to provide recommendations.

The software development process at Tiptop-ICT is ISO certified and documented, but the execution of the different activities is poorly defined. Furthermore, the execution of the activities is greatly dependent on the person doing it. The result is that activities are performed in different ways, quality varies, and responsibilities are not clear. The next four areas for improvement are defined:

Organisation of the process

System development at Tiptop-ICT is performed sequential, so requirements and design must be completely specified before the implementation can start. Also, there is hardly any interaction with the customer between the delivery of the design and the installation of the system. It is hard to make adjustments or implement new requirements once the design is approved.

Requirements and design

Requirements are mainly captured in the functional design of the system, which is used to

communicate with the customer, but also with the programmers who have to develop the system. This document is too detailed for the customer to understand, and it bears a complete technical design for the programmers. The result is that the customer does not always understand what functionalities the system will provide, and the functional design is not always sufficient for the programmers to develop the system correctly.

Inspection and testing

These activities can ensure the correctness, completeness, and quality of project artefacts and the developed system. Unfortunately, inspection and test activities do not have a high priority at Tiptop-ICT. Therefore, it occurs that systems are delivered that contain to many faults and do not completely satisfy the requirements of the customer.

Cost estimation

The cost estimation of a software project indirectly affects the degree in which the system meets the customer’s requirements. Estimates at Tiptop-ICT are not accurate and there is no standard procedure for cost estimation.

(4)

a more structured process. The employees of the Business Unit Software are involved in the research in order the check the attainability of proposed recommendations and the willingness of employees to embrace change. Furthermore, several process improvement meetings are held with the manager of the department Development and the manager of the Business Unit Software. The management and employees of Tiptop-ICT wanted to hold on to a waterfall based methodology to develop a system. For that reason, my first focus was to improve the process without changes the methodology; however, the advantages of an incremental process above a sequential process became clearer during my research. This research makes clear that an incremental approach is more appropriate in most situations. The incremental delivery methodology is to a certain extent based on the waterfall methodology. It involves breaking down the system into small components that will be designed, codes, tested, and delivered in sequence. Incremental delivery is especially appropriate for developing systems with unclear requirements and unfamiliar technology. It gives Tiptop-ICT the opportunity to better deal with the customer’s (changing) requirements, needs, and wishes.

The next problem area that is treated is requirements and design. The analysis shows that the functional design serves different purposes; therefore, it is impossible to produce an

unambiguous document. The main conclusion is to produce three different documents: one for the requirements, one for the functional specifications, and one for the technical specifications. Furthermore, Tiptop-ICT should pay more attention to the non-functional requirements and must ensure that the system will meet these requirements. The main document for

communication with the customer should be the requirements specifications instead of the functional design. The requirements specifications must give the customer a clear overview of which processes the system supports and which functionalities the system must have, and this document must include an explicit list of functional and non-functional requirements In addition, it is recommendable to use clear models and images to make the documents more readable and better understandable for the customer.

In the field of inspection and testing, this report indicates that the quality assurance activities must have higher a priority and need to be performed strictly. The aim of inspections is to ensure that artefacts of the software development process have an acceptable level of quality, to detect errors in an early stage of the process, and to assist developers in improving their work. It is recommendable to formally inspect the following artefacts at Tiptop-ICT: requirements

specifications, functional design, technical design, code, and test plan. Besides inspection, testing is a powerful mean to ensure the quality of the system. Unfortunately, the testing process at Tiptop-ICT is nearly unstructured. As the first step to improve the test process and to achieve a higher maturity level, it is recommendable to implement TMap light (test management approach for structural testing of software products) at Tiptop-ICT. The foundation for a structured test process, and TMap, is the test plan. A test plan is used to describe how, by whom, with what, and when the test activities will be carried out. To further improve the quality of the tests, and thus the system, it is recommendable to establish an independent test team that is responsible for the system test. Furthermore, test specifications need to be created and employees need to be trained in making and executing tests.

(5)

actual measurements should be subsequently compared and analysed with the early estimate, and at the end of the project, the estimated costs should be compared with the actual costs.

(6)

1 Introduction and research set-up

This chapter provides an introduction and describes the research set-up. Furthermore, the structure of the report will be described and various terms will be defined.

1.1 Research context

This section describes the context and the scope of the research. 1.1.1 Introduction of Tiptop-ICT

Tiptop-ICT is a fictitious company name. Figure 1 depicts the organisation chart of Tiptop-ICT.

Staff Services

Business Unit X

Development Support

Software Business Unit Y Tiptop-ICT

Figure 1: Organisation chart of Tiptop-ICT

1.1.2 Scope

The scope of this research is the software development process within the Business Unit

Software. Within this Business Unit, the department Development takes care of the development of standard and custom-made applications. The department Support is responsible for the maintenance and support of both standard and custom-made applications.

The focus of my research is on the development of custom-made applications. The process that will be analysed concerns software projects of more than 300 hours. Tiptop-ICT applies an ISO certified procedure for these projects. The software development process includes the steps from initial contact with the customer till the customer accepts the developed system. The installation and release of the software and project management activities are not included in the scope of this research.

1.2 Research question and conceptual model

To define the scope in clear targets the research question and sub questions will be defined. Section 1.2.2 will provide and explain the conceptual model, and section 1.2.3 will explain how data and information for this research will be gathered.

1.2.1 Research question

The motive for starting this research is that occasionally the functionalities of developed systems differ from the functionalities required by the customer. In addition, errors are found in a late phase of the process; therefore, reworking parts of the system is very expensive and time-consuming. The next main objective is formulated:

The objective of the research is to provide the management of Tiptop-ICT with insight in the software development process and to provide pragmatic recommendations to improve the software development process.

To achieve this objective, the following research question is formulated:

(10)

Now that the objective and research question are defined, it is important to split the research question into sub questions. The sub questions split up the research into manageable pieces. When all sub questions are answered, an answer to the research question can be formulated. The first aim of this research is to construct a picture of the software development process at Tiptop-ICT. Therefore, the first sub question will give an answer on how systems are actually developed at Tiptop-ICT. Through interviews with employees, I will describe the current software development process. During the interviews, the employees will be asked what

problems they encounter, and I will already perform some analysis. Because of the characteristics of the software development process, it is likely that the interviews will reveal different kinds of problems. In order to perform a good analysis, the problems will be categorised. Following, by getting acquainted with the organisation, it became notable that the software development at Tiptop-ICT is performed sequential. Because of my study background, interests, and knowledge, I find it valuable to analyse what effect software development methodologies have on the degree on which a system meets the customer’s requirements. Next, requirement is a very important term in the research question; therefore, one sub question will give an answer on how customer’s requirements can be translated to system requirements and design. According to the defined problem categories, different theoretical perspectives will be described, compared, and analysed. The description of the current situation and the theory are the basis for a thorough analysis of the software development process. As result of the analysis, different improvement action will be proposed. The following sub questions are formulated:

1. What is the method of working within the software development process?

2. Which problems arise in the current situation, and which categories can be identified? 3. How mature is the current software development process?

4. Which methodologies can be applied to develop software systems?

5. How can customer’s requirements be translated into system requirements and design? 6. Relating to the problem areas, how can a software development process be set up

properly according to different theoretical perspectives?

7. What can be recommended to improve the software development process? 1.2.2 Conceptual model

Figure 2 illustrates the conceptual model for this research. The conceptual model indicates on which way the formulated research question will be addressed. The central question is how systems can meet with the needs, wishes, and requirements of the customer, which are used as input for the software development process. Hence, the software development process must be designed for an appropriate processing of these requirements. The customer is the person who has signed the contract for the development of a system; however, domain experts and end users also represent the customer. Therefore, I refer to customer as the people who pay for the system and the people who are responsible for accepting the system. Goal is to provide pragmatic recommendations in order to improve the software development process at Tiptop-ICT.

(11)

1.2.3 Data resources

Within this research, different methods of data collection will be used in order to provide an answer to the sub questions. Baarda and de Goede [1995] make a distinction between two different methods of data collection:

Desk research: Identification and analysis of information that already is available and published in some form or other;

Field research: Gathering of information through observations, questionnaires, or interviews.

Desk research

For this research, the literature that is related to software development and the specific facets of the software development process will be analysed. Literature includes books and articles from the University library, articles from specialist journals, and online available reliable resources. Furthermore, several internal documents will be examined, such as annual reports, quality system, presentations, researches, forms, and finished deliverables (tangible outcomes, such as documents and plans) of software projects.

Field research

Because the research is empirical, not all information needed to answer the sub questions can be found with desk research. The remaining information needs to be gathered by performing field research. In order to describe the current situation of the software development process, several interview sessions will be held. To construct a complete picture of the process, the interviews will be held with several employees that have different roles and functions. The interviews will be held separately and in a neutral (meeting) room to prevent distraction. The next employees will be interviewed: Manager Development; Manager Support; Account manager; Project manager; System analyst; Programmer.

Moreover, the employees of the Business Unit Software will be involved in the whole research in order the check the attainability of proposed recommendations and the willingness of employees to embrace change. Also, process improvement meetings will be held on a regular basis with the manager of the department Development and the manager of the Business Unit Software. 1.3 Report structure

This report can be divided into three parts. Part one primarily describes the current situation of the software development process at Tiptop-ICT. Part two provides theoretical insights, and part three gives an analysis of software development process and provides recommendations. The sub questions for this research will be addressed in different chapters.

(12)

different theoretical perspectives. Following, chapter 7 will provide an analysis and present recommendations to improve the process, and the conclusion of the research will be given in chapter 8.

1.4 Definitions

This section gives the definitions of terms that are related to this research to prevent confusion about the interpretation of these terms.

1.4.1 Software development process

The world’s leading professional association for the advancement of technology (Institute of Electrical and Electronics Engineers) has defined the software development process as the process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design in code, testing the code, and sometimes installing and checking out the software for operational use [IEEE, 1990]. A software product can be further defined as the complete set of computer programs, procedures, and possible associated documentation and data designated for delivery to a user [IEEE, 1990]. In this report, the software product will be mainly referred to as a system. Though this report will include different terms like application, program, or software product; the meaning of the different terms is the same.

From studying the definition of a software development process, the process can be divided into five parts:

Translating user needs into software requirements; Transforming the software requirements into design; Implementing the design in code;

Testing the code;

Installing and checking out the software for operational use. 1.4.2 Software development lifecycle

Another term that is often used in the software literature is the software development lifecycle. This term is frequently confused with the software development process. The software

development lifecycle defines the period of time that begins with the decision to develop a software product and ends when the software is delivered [IEEE, 1990].

1.4.3 Requirement

IEEE [1990] has defined three definitions for requirement:

(1) A condition or capability needed by a user to solve a problem or achieve an objective; (2) A condition or capability that must be met or possessed by a system or system

components to satisfy a contract, standard, specification, or other formally imposed documents;

(3) A documented representation of a condition or capability as in 1 or 2.

(13)

1.4.4 Functional and technical design

(14)

2 Current situation of the software development process

This chapter provides insight in the current situation of the software development process at Tiptop-ICT. Section 2.1 gives an overview of the software development process, and section 2.2 informs about the developments at Tiptop-ICT. The next section presents a list of problems, and section 2.4 assesses the maturity of the software development process.

2.1 Description of the software development process

The Business Unit Software is responsible for the development and support of systems. The Business Unit exists of three departments:

Sales: responsible for finding new orders, marketing, and customer relationship; Development: responsible for the development of software systems;

Support: responsible for the support and maintenance of the developed systems.

Software can be developed under supervision of the department Development and Support. The Support is responsible for the maintenance and support of developed systems, but also takes care of customer dependent adjustments. These adjustments are often small and take normally

between 8 and 40 hours of developing time. When there are needed larger adjustments, the development will be done under supervision of the department Development.

The software development of ‘large’ systems (> 300 hours) is the subject of this research. These systems are developed at the department Development. There can be made a difference between two different kinds of software projects, namely:

Development of custom-made systems;

Development of custom-made adjustments or extensions to previously built systems at Tiptop-ICT.

Annually, Tiptop-ICT deals with about five large software projects. The software development process for these projects is ISO certified and documented. To manage a software project, the project manager makes a project plan. This plan includes the planning, occupation, consultation structures, quality control, milestones, and organisation of the project. The project manager is responsible for the execution of the procedures within the project. Throughout the project, meetings are arranged with all involved persons. The goal of these meetings is to inform the project team and the customer about the status and progress of the project, and to discuss the results of assessments and verifications. The next sections describe how the software

development process of large projects is set up. 2.1.1 Initial contact with customer

The account manager is responsible for finding new customers and orders. When the account manager has established contact with a potential customer, he makes a few appointments to make an inventory of the requirements, needs, and wishes. The system analyst also makes

appointments with the customer to identify the requirements. When requirements are not directly clear, the system analyst will perform a preliminary investigation to complete the picture of the system.

2.1.2 Preliminary investigation

The goal of this investigation is to describe the main functionalities of the system. Inputs for this investigation are, if present, a list of demanded requirements of the customer and the interviews. The preliminary investigation includes the following parts:

(15)

Connections with other systems;

Other requirements, which are needed to design and develop the system. 2.1.3 Cost calculation and first offer

Once the basic requirements of the system are clear, the account manager, system analyst, and project manager discuss about the attainability and feasibility of the project. After that, an estimate is made about how many hours the development of the system will take. Following, the account manager makes an offer for the creation of the functional design, and this offer also includes an estimated price of the system. Before the offer is send to the customer, the Business Unit manager must approve it.

2.1.4 Functional design

When the customer has accepted the first offer, the system analyst can start to make the functional design. The purpose of the functional design is to describe all functionalities exactly and in detail. The system analyst has intensive contact with the customer in order to get ‘all’ requirements of the customer clear and to design a system that meets with these requirements. The functional design includes the following parts:

Name, purpose, frequency, and description of each independent function; Graphical user interface of the system (1 or 2 screen layouts);

Data model.

The project manager verifies the functional design and signs it for approval. Besides that, the customer must approve this document.

2.1.5 Cost calculation and second offer

Normally, the first offer only concerns the creation of the functional design. After the completion of the functional design, the customer has the possibility to outsource the

development to another software development company. However, the customer grants Tiptop-ICT the development of the system in nearly all cases. After completing the functional design, a new offer is made for the development and support of the system, and a new calculation of the development effort will be made. In this case, a programmer is also involved in the estimation process. After determining the price of the system, a new offer is made by the account manager. When the customer accepts this offer, the process will continue.

2.1.6 Technical design

According to the ISO procedure, a technical design needs to be produced before you can start to program the system. In practice, when the functional design is ready, programming starts right away. There are only made technical designs for large adjustments to the PerfectApp system (see also 2.2.3). Because of the complexity of this system it proved to be necessary to make technical designs. For other projects, the programmers start to code the system with the functional design as main input. When there are questions on how to program a function, the programmer must ask another (senior) programmer or the system analyst for explanation. In case that a technical design is made, the project manager must approve it. Approval of the technical design by the customer is not required.

2.1.7 Programming

(16)

project manager. When errors are detected, the project manager gives the first programmer instructions to correct these errors. After that, the code is tested once again.

2.1.8 System test

When all components are developed and tested, they are integrated and transferred to a test environment. After that, the system analyst, who made the functional design, performs a system test. Purpose of this test is to check whether the system meets with the functional design. Test plans are made occasionally. The structure of the system test is dependent on the system analyst; this results in an ad hoc test of varying quality. The results of the test are registered and handed over to the project manager. When errors are detected, the project manager gives a programmer instruction to correct these errors. After passing the system test, the system can be installed at the customer.

2.1.9 Acceptance

After completing the system test, the system is ready for the acceptance test, which is performed by the customer. Tiptop-ICT supports the customer with installing the system in a test

environment. When errors are detected in the acceptance test, the project manager gives a programmer orders to correct these errors. When the system is accepted, Tiptop-ICT installs the system in the production environment. This also includes the execution of conversions;

furthermore, Tiptop-ICT can provide trainings to end users. When the project has come to an end, the department Support gets the supervision over the application. Therefore, a transfer-document is made, which contains information about the customer, technical information of the system, and the functional design.

2.2 Developments at Tiptop-ICT

The previous section has given a global impression of the software development process. Within Tiptop-ICT, there are several developments identifiable that affect the software development process. This section describes these developments.

2.2.1 Workload

The revival in the ICT sector has given Tiptop-ICT the opportunity to obtain more orders. Also, the sale of particular systems has indirectly led to new orders and customers. This means that the software development process is currently running at maximum capacity. The increasing

workload leads to more pressure on the process and to more mistakes. 2.2.2 New employees and techniques

About several years ago, Tiptop-ICT was only developing systems in a specific fourth generation programming language. However, nowadays customers are demanding also other programming languages for the development of their systems. Moreover, Tiptop-ICT is currently working with a new framework, which requires time to learn. In the past months, new employees are hired to reduce the workload. Because the new employees have no knowledge of the systems at Tiptop-ICT, and the programmers also need to learn new techniques, the software development process has become unstable.

2.2.3 Clean Development

(17)

2.3 Problems

Interviews were necessary to describe the current situation, but they also revealed problems. For the execution of the activities within the software development process, Tiptop-ICT relies entirely on the knowledge and experience of the employees. The result is that processes and activities are carried out differently, depending on the situation and person. Furthermore, job descriptions and roles are not very clear. By asking employees what problems they encounter, and by performing some analysis, a list of problems could be defined. Problems that are related to the software development process are categorised and described below:

Organisation of the process:

Documentation of systems is not complete and/or up-to-date. Mainly for one specific system, there is also one developer with overall knowledge;

The execution of activities within the process is dependent on the employee doing it; There is no prioritising of components and quality aspects of the system;

Responsibilities and roles of employees are not always clear;

It is hard to made changes to requirements or implement new requirements after the completion of the design;

Once the system is delivered, at the end of the project, the differences between the required functionalities and the functionalities of the developed system become clear. Because this is in a late phase of the process, rework is very expensive;

Requirements and design:

Customer does not always understand the functional design or has another perception of the system and/or functions;

The functional design contains too much detail for the customer;

Requirements are not clearly defined; there are normally no explicit lists of requirements; The functional design is not always sufficient to develop a system;

Inspection and testing:

It occurs that the customer detects errors in the acceptance test that definitely should have been noticed and solved in the system test;

There is no standard method for the different tests; There is no dedicated tester;

Because of lack of time at the end of a project, and the high workload, there is no possibility to execute an appropriate system test;

Regression tests are usually not executed; Inspections are not structurally executed; Code is normally not inspected;

Cost estimation:

It is hard to estimate the effort and time necessary to develop the system;

Calculations are less accurate because programmers reserve more time because lack of technical knowledge/skills;

There is no standard procedure for cost estimation;

There is no information stored about estimates that are made. 2.4 Maturity of the software development process

This section gives a judgement about the level of maturity of the software development process at Tiptop-ICT. Section 2.4.1 presents information about the certification of the software

(18)

2.4.1 ISO certification

To ensure the quality of the processes, Tiptop-ICT has applied the ISO9000 approach. ISO9000 has become an international reference for quality management requirements. The theory behind the ISO standard is that an organisation with well-defined processes is more likely to produce products that meet customer’s requirements. The software development process at Tiptop-ICT is described in the X1 procedure. Although the procedure is documented and certified, it gives no precise representation of the current software development process. Not all phases in the X1 procedure are truly executed, or they are done in a different way. The X1 procedure consists of the following phases:

Preliminary investigation; Functional design; Technical design; Development; Testing code; System test;

Installation and acceptance.

At the end of each phase, the product is reviewed to determine whether to move to the next phase. The X1 procedure outlines the main phases of the software development process, but misses the explanation on how the activities are exactly executed. For example, the procedure describes that a functional design must be made, but does not describe in which way it must be made. The procedure only gives an outline of the process from a high point of view and lacks detail. Next to it, as well as in many organisations that are ISO certified, the described processes are not fully consistent with the real-life processes. ISO standards are usually taken by customers to imply that the produced product is of the certified standard; however, the standard only ensures that the process is documented and maintained. Therefore, the level of maturity of the process can be regarded as low.

2.4.2 Capability Maturity Model (CMM)

The capability maturity model (CMM) is commonly used to determine the maturity of software processes. This model attempts to place organisations at one of the five levels of process maturity to indicate the quality of their software development process.

In 1986, the Software Engineering Institute (SEI) began developing a process maturity framework that would help organisations to improve their software process. After years of experience with the software process maturity framework, the SEI developed the capability maturity model for software. The CMM helps organisations to improve the maturity of their software processes. It describes an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes [Paulk et al., 1993]. Paulk et al. [1993] define maturity as the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. A low level of maturity incorporates a high level of risk in performing a process, as organisations become more mature they are better capable of decreasing risks and improving quality [van Solingen and Berghout, 1999]. The CMM can also be used to determine the most important areas for improvement.

The five maturity levels of CMM are described as follow [Hughes and Cotterell, 1999]: Level 1: Initial. The procedures followed tend to be ad hoc. Some projects will be

(19)

Level 2: Repeatable. Organisations at this level have basic project management procedures in place. The way an individual task is carried out will depend largely on the person doing it;

Level 3: Defined. The organisation has defined the way in which each task in the software development cycle is to be done;

Level 4: Managed. The products and processes involved in software development are subject to measurement and control;

Level 5: Optimising. Improvement in procedures are designed and implemented using the data gathered from the measurement process.

Each maturity level provides a foundation for effective implementation of processes at the next level1. Therefore, maturity levels should not be skipped. The maturity of a software process is at least at level 1 (initial). The capability of a level 1 process is unpredictable, and the processes are likely to be changed or modified. Level 2 processes are reasonable stable and managed, and level 3 processes are well-defined and management has good insight into the progress of the project. At level 4, processes are measured and controlled, and in level 5, the organisation is focussed on continuous process improvement. From the given high-level description of the CMM, a reader should conclude that Tiptop-ICT is at least at level 2.

Harmon [2003] states that most organisations fall between level 2 and 3. Each level maturity level is decomposed into activities that have to be performed to achieve a maturity level. For maturity level 2, the following process areas need to be addressed [Paulk et al., 1993]:

Software configuration management. Establish and maintain the integrity of the products of the software project throughout the project’s software life cycle;

Software quality assurance. Provide management with appropriate visibility into the process being used by the software project and of the products being built;

Software subcontract management. Select qualified software subcontractors and manage them effectively;

Software project tracking and oversight. Establish adequate visibility into actual progress, so that management can take effective actions when the software project’s performance deviates significantly from the software plans;

Software project planning. Establish reasonable plans for performing the software engineering and for managing the software project;

Requirements management. Establish a common understanding between the customer and the software project of the customer’s requirements that will be addressed by the software project.

By analysing these process areas and the current situation at ICT, I conclude that Tiptop-ICT pays attention to these process areas, but that they not have accomplished all process area goals. Therefore, the maturity of the software development process at Tiptop-ICT should be classified as initial; however, the maturity is close to the repeatable level.

Additionally, you can also focus on the management of the software process to give a judgement of the maturity. Figure 3 focuses on the management view of visibility into the software process.

(20)

Figure 3: A management view of visibility into the software process at each maturity level (source: Paulk et al., 1993)

As described in section 2.4.1, the structure of the process is visible and defined. Nevertheless, the management only has insight in the visibility of the project on predefined occasions (between the development stages), and the internal structures of the phases are not defined. From this

perspective, the maturity of the software development process at Tiptop-ICT can be classified as repeatable.

(21)

3 Software development methodologies

This chapter will discuss and analyse a selection of the most applied software development methodologies. Section 3.1 will give an introduction, and the next sections will describe different methodologies. The last section of this chapter will present a framework for selecting the most appropriate methodology.

3.1 Introduction to software development process

Building a software product is often compared with building a house. The process is in many ways similar. First of all, it is difficult to know whether you can build the product that the customer wants, and within a timeframe until you have a full understanding of the customer’s needs. It also occurs that the customer does not exactly know what he wants or has other expectations of the end product. Furthermore, the structures of the two processes share similarities [Dennis et al., 2005].

A house/software product starts with a basic idea;

The idea is transformed into a simple drawing that is shown to the customer and refined until the customer agrees;

A set of blueprints is designed that present much more detailed information about the product;

The product is built following the blueprints and often with some changes directed by the customer, or changes because of technical restrictions as the product is constructed. Within software development, these phases can be defined as: planning, analysis, design and implementation [Dennis et al., 2005]. Although there are many different software development methodologies, they all share those four basic elements. The four basic elements are described below:

Planning: this phase includes project initiation and project management. Before a project starts, a feasibility study must be made. The results of this analysis will be used to judge whether the organisation should develop the system. After the project is approved, the project should be managed;

Analysis: in this phase, the requirements are gathered for the software product. This includes all the things that are related to what the system must do;

Design: in the design phase you determine how the system will exactly work; Implementation: in this phase, the system is actually developed, tested, and

implemented.

The next sections describe different software development methodologies. The following types of methodologies are covered:

Waterfall methodology: this approach separates the software development process into different phases. When a phase is completed, the process proceeds to the next phase; Iterative development: an iterative methodology is based on enlargement and

refinement of the software through multiple development cycles of analysis, design, implementation and testing [Moses et al., 2002];

Agile development: Agile development is also a type of iterative development, but they are less bureaucratic and more focussed on smaller software projects.

3.2 Waterfall methodology

(22)

software systems. He had experienced different degrees of success of software projects with respect to arriving at an operational state, on time, and within costs. In Royce’s original waterfall model, the following phases are proceeded in order:

System requirements; Software requirements; Analysis; Program design; Coding; Testing; Operations.

The waterfall methodology proceeds from one phase to the next. One characteristic of the waterfall methodology is that it is document driven. The main products that are carried from one phase to another are documents. At the end of each phase, these deliverables are presented for approval. After approval, the process advances to the next phase. It is possible to go back to a previous phase in the process, but this is difficult. Therefore, you should only move to the next phase when its preceding phase is fully completed and perfected.

The advantage of the waterfall methodology is that the time spent early in the software

development process (such as requirements specifications and design) leads to greater economy in rest of the process. The waterfall methodology requires that the requirements and design must be completely specified before the programming of the system can start. However, McConnell [1993] states that software design is a wicked problem, a problem whose requirements and limitations cannot be entirely known before completion. Therefore, requirements often change when a project evolves. Another disadvantage of the waterfall model is that the time between the analysis phase and the delivery of the software product is very long. When the project team has overlooked some requirements, expensive post implementations are needed. Moreover, changed business environments can lead to rework.

Many different authors have mentioned problems concerning the waterfall approach. However, a research of Cusumano et al. [2003] indicates that this methodology is still commonly practiced. Almost 40% of the companies are still applying this approach. The waterfall methodology works well for projects that are well understood but complex [McConnell, 1996]; in an early stage of the process you can tackle the complexity.

3.3 Iterative software development methodologies

As defined, an iterative methodology is based on enlargement and refinement of the software through multiple cycles. Each cycle iteratively builds upon the success of the previous cycles until the final software product is built and the project is complete [Moses et al., 2002]. Iterative development methodologies incrementally deliver the functionalities of the system. These methodologies are extremely useful when the customer has no clear requirements and only can describe in outline the services that have to be provided by the system. The next sections describe the two most popular iterative development methodologies.

3.3.1 Rapid application development (RAD)

The philosophy behind the rapid application development based methodologies is to develop some parts of the software quickly (prototypes) and to present these to the customer. In this way, the end user and customer better understand the software product and can bring in some

(23)

specifications. The main problem with which the RAD methodologies are dealing, are user expectations [Dennis et al., 2005]. Due to the review sessions with the customer, the user expectation of what is possible can change. As the user better understands the information technology, the system requirements tend to expand [Dennis et al., 2005]. Figure 4 depicts an overview of the phases within the RAD methodology.

Figure 4: Phases of the rapid application development process

3.3.2 Rational unified process (RUP)

The Rational software corporation has developed the Unified Process. In this methodology, the Unified Modeling Language (UML) is used to model software products. RUP is an iterative development methodology for object-oriented systems. Object-oriented programming is a method of programming in which programs are organized as cooperative collections of objects, each of which represents an instance of some type, and whose types are all members of a hierarchy of types united via other than inheritance relationships2_{. RUP embraces use cases for} building the foundation of the software product and for modelling the requirements. Figure 5 depicts an overview of the phases, disciplines, and iterations within RUP.

Figure 5: Phases of the rational unified process3

Each phase of the process contains of one or more iterations. The inception phase defines the objectives of the project. In the elaboration phase, the problem domain is analysed and

architectural foundations of the system are established. In the construction phase, the system is implemented, and in the transition phase, the system is tested and prepared for release. RUP is a heavy and large software development methodology. It requires much effort to implement this methodology, and it requires training to learn the modelling techniques of UML.

3.4 Agile software development methodologies

(24)

An agile software development methodology focuses on generating early releases of the system. The name ‘agile’ is introduced in 2001, when seventeen process methodologists held a meeting to discuss future trends in software development. They noticed that their methodologies had many characteristics in common, and they defined the agile software development methodologies. For many people, these agile methodologies were a reaction to the bureaucracy of the ‘heavy’

methodologies [Moses et al., 2002]. As a result, these methodologies are less document-driven. In general, agile methodologies are more appropriate for smaller projects [Moses et al., 2002]. Abrahamsson et al. [2002] have further defined the term ‘agile’. They conclude that agile development methodologies share the same following characteristics:

Incremental development: small software releases, with rapid cycles;

Cooperative: customer and developers working constantly together with close communication;

Straightforward: the methodology itself is easy to learn and modify, and it is well documented;

Adaptive: able to take into account last moment changes.

Based on these definitions, I conclude that the following software development methodologies are agile:

Adaptive software development (ASD); The crystal family of methodologies;

Dynamic systems development method (DSDM); Extreme programming (XP);

Feature driven development (FDD); Pragmatic programming (PP); Scrum.

Occasionally, RUP is also considered to be an agile methodology; however, due to the complex and large characteristics of RUP it is considered to be not agile. The Crystal family of

methodologies is an agile methodology, but it includes a number of different methods from which you have to select the most suitable one for each individual project. Furthermore, one may note that not all agile methodologies can be fully called a software development methodology. Some agile methodologies do not support all phases of the software development lifecycle, like acceptance test and implementation of system. Moreover, some methodologies are more focused on practices while other are focused on the management of a software project. The next sections describe shortly two of the most practiced agile methodologies.

3.4.1 Extreme programming (XP)

Extreme programming is developed by Beck and is an agile method for developing software subject to rapidly changing requirements. The XP process can be characterized by short

development cycles, incremental planning, continuous feedback, reliance on communication, and evolutionary design [Beck, 2000]. An XP project starts with user stories that describe what the system needs to do. Programmers code in small, simple modules and must provide rapid

(25)

3.4.2 Feature driven development (FDD)

The feature driven development methodology focuses mainly on the design and building phases. The FDD approach is an iterative process that is characterised by delivering frequently tangible and working deliverables. As the name implies, features are an important characteristic of FDD. A feature is a small, client-valued function that can be delivered in two weeks or less. For example, calculate the total of orders and validate username and password. There are five main activities in FDD that are performed iteratively:

Develop an overall model. Identify and understand the fundamentals of the domain. The overall domain is divided into different, more defined domains;

Build feature list. There is made a list of all features for the domain models; Plan by feature. In this plan, the features are prioritised and schedules are made.

Furthermore, milestones may be set for the feature;

Design by feature and build by feature. In this phase, the selected features are further designed and eventually built.

3.5 Selecting the appropriate methodology

The large variety of different methodologies is the consequence of the large variety of different software projects. Figure 6 depicts an evolutionary map of (agile) software methodologies. It shows the variety, relation, and origin of the different methodologies.

Figure 6: Evolutionary map of software methodologies (source: Abrahamsson et al., 2003)

(26)

Furthermore, Highsmith and Cockburn [2001] report that the chancing environment in software business also affects the software development process.

Before you can adopt a methodology to your organisation, you have to learn the systematic of the methodology and the techniques and tools that are required. Especially RAD and RUP require tools and techniques that have a high learning curve. However, once the team is familiar with these tools and techniques it can speed up the process significantly [Dennis et al., 2005]. Based on the criteria that Dennis et al. [2005] and McConnell [1996] are using to select the appropriate methodology, a framework will be given. The criteria are as follow:

Clarity of the requirements. The clarity of the requirements has a large influence in the consideration of the appropriate methodology. When customer’s requirements are unclear, it is to be expected that requirements change and/or new requirements must be implemented during the project.

Familiarity with technology. The technology refers to the kind of programming language and database technology.

System complexity. When the software system is very complex there is need for a careful analysis and a proper design.

Project size. Size refers to the number of hours that is planned for the project. Heavy weight methodologies are less appropriate for small projects.

Application knowledge. This refers to projects that are adjustments to earlier built systems. With the knowledge about these systems, the project team is better capable of developing the adjusted system.

Table 1 depicts an overview of the software development criteria and the result of the assessment of different methodologies. This table is based on the frameworks of Dennis et al. [2005] and McConnell [1996]. Each rating is either poor, good, or excellent. Finer distinctions are not meaningful at this level, and the ratings in the table are based on the methodologies best potential.

Waterfall RAD RUP XP FDD

Unclear requirements Poor Excellent Good Excellent Good

Unfamiliar technologies Poor Good Excellent Poor Poor

Complex system Good Good Good Poor Poor

Small project Good Poor Poor Excellent Excellent

Much application knowledge Excellent Good Excellent Good Good

Table 1: Criteria for selecting a software development methodology

Note that all methodologies do not exist in pure form; therefore, small changes in the

methodology can be made by an organisation to increase results. To proceed, projects that are well understood but complex are very suitable to adapt the waterfall methodology [McConnell, 1996]. When the requirements are unclear and the technology is unfamiliar than an iterative mythology can be adopted to tackle these problems. For large projects, RAD and RUP are more appropriate, and for smaller projects one of the agile methodologies is the best choice.

Some software projects may require fast development. For instance, a product must be

(27)

Agile methodologies require a more active role of the customer, and programmers may need to develop on location. Therefore, also the characteristics of the project team and the user’s needs should be analysed in the process of selecting the appropriate software development

methodology.

(28)

4 Requirements engineering and design

The hardest single part of building a software system is deciding precisely what to build [Brooks, 1987]. Many requirements errors are passed undetected to the later phases of the software development process, and correcting these errors during or after implementation are costly [Christel and Kang, 1992]. Requirements are the description of the services and constraints of the desired system. The process of identifying, analysing, and documenting the correct requirements, is called requirements engineering. Before the requirements engineering process starts, you should perform a feasibility study. Once decided to develop the system, the requirements engineering process can be initiated.

Requirements are either functional or non-functional. A functional requirement relates directly to a process that the system has to perform or information it needs to contain. Non-functional requirements refer to constraints on the services or functions that the system must have. They may relate to system properties such as reliability, performance, and security. Requirements may range from a high-level abstract statement of a system to a detailed specification. This is because the requirements specifications can serve two purposes:

It can be the basis for a bid for a contract; It can be the basis for the contract itself.

Figure 7 illustrates the different views that the system/business analyst and the customer have of the imagined system. They both have different expectations about the same project. The

customer usually does not fully understand software technology, and the analyst does not fully understand customer problems. Furthermore, the customer knows what is needed and how the system should behave, and the analyst knows what the technical issues are and what is feasible. The result of the requirements phase should be that the two different pictures become one clear picture for both the customer and the software development company. However, according to McDermid and Rook [1993], no single interpretation of a language exists, pointing to the fact that possible misinterpretation of requirements during software development will always exist.

Figure 7: Different expectations (source: McConnell, 1996)

Southwell et al. [1987] state that the construction of the requirements specifications is inevitably an iterative process, which is not, in general, self-terminating. Thus, at each iteration it is

necessary to consider whether the current version of the requirements specifications adequately defines the customer’s requirements. It is not always possible to gather all requirements before developing a system; there should be a moment to make a decision to move on to the next phase of the process. Although you might be able to specify the requirements of the system in

(29)

activities. During this phase, the customer must be able to communicate their requirements to the analysts, and the analysts need to be able to communicate the specifications of the system back for validation.

4.1 Requirements engineering process

Sommerville et al. [1998] have defined a generic model of the requirements engineering process, which is an adoption of cyclical requirements models of several authors. It is a spiral model in which requirement information emerges from successive iterations. The original model contained three distinguish phases; however, the model is used and altered by several authors. I define four phases that are essential in the requirements engineering process:

Requirements elicitation. Requirements discovered through consultation with

stakeholders (stakeholders can include the customer, domain expert, (managers of) users, and all other persons that are involved with the development of the system);

Requirements analysis and validation. The requirements discovered during the elicitation phase are analysed. Usually, this will result in the identification of missing requirements, inconsistencies, and requirements conflicts;

Requirements negotiation. Problems found in the analysis phase are resolved in the negotiation phase. The analyst(s) and stakeholders clarify and discuss the problems and seek for a solution;

Requirements documentation. The agreed requirements must be documented and readable for the customer.

4.1.1 Requirements elicitation

In this phase, all activities are performed in discovering what the requirements are. This includes the following input for the requirements engineering process [Kotonya and Sommerville, 1998]:

Existing system information. Information about the functionality of systems that need to be replaced, or other systems which need to interact with the system;

Stakeholder needs. Descriptions of what stakeholders need from the system to support their work;

Organisational standards. Standards used in an organisation regarding to the system development;

Regulations. External regulations, which apply to the system;

Domain information. General information about the domain of the system.

An effective elicitation is important because the system must meet the requirements. When the elicitation process is not properly performed, it becomes impossible to formulate the correct requirements. The difficulty in the elicitation of requirements is that stakeholders don’t always know exactly what they want. Furthermore, stakeholders can express requirements in their own terms, and different stakeholders may have different requirements. Moreover, the requirements may change during the requirements engineering process.

There are many problems that can arise when identifying the requirements. According to Christel and Kang [1992], 10 problems of requirements elicitation can be grouped into three categories:

Problems of scope

: the requirements may address too little or too much information.

o The boundary of the system is ill-defined; o Unnecessary design information may be given.

Problems of understanding

: problems within groups as well as between groups such as users and

developers.

o Users have incomplete understanding of their needs;

(30)

o Analysts have poor knowledge of problem domain; o User and analyst speak different languages; o Ease of omitting “obvious” information; o Conflicting views of different users;

o Requirements are often vague and untestable, e.g., “user friendly” and “robust”.

Problems of volatility

: the changing nature of requirements.

o Requirements evolve over time.

Many different information-gathering techniques are available to identify the requirements. These include interviews, JAD sessions, workshops, brainstorm sessions, questionnaires, document analysis, and observations. The document analysis and observation are very useful techniques to gather information about the “as is” situation. The other techniques can also be useful to identify the “to be” situation. Besides these techniques, the use of modelling tools can help to make requirements more clear and to speak the same ‘language’ with the customer. For example, an UML use case diagram can be used to indicate the main processes and functionalities of the system, but it is also useful to make the domain of the system clear to the customer.

4.1.2 Requirements analysis and validation

In the analysis and validation phase, the draft requirements are checked for conflicts,

inconsistencies, ambiguities, and overlaps. Activities that are performed in this phase include prioritisation and classification of requirements and the identification of possible risks. Furthermore, the requirements need to be checked for correctness, completeness, and

consistency to ensure that the requirements are verifiable and of a good quality. Models like data flow diagrams can be made to better understand the requirements and for validating the

completeness and consistency. The quality of the requirements analysis is heavily dependent on the skills and experience of the analyst(s).

Projects can be so complex that the requirements of the system can never be fully analysed, and understanding of the requirements develops during the system development. Therefore,

requirements can be both incomplete and inconsistent. In these cases, it can be necessary to develop prototypes to further discover, analyse, and validate the requirements. Also, when a software development company deals with inexperienced users, it can be essential to produce a prototype.

Normally, the customer wants a system that supports or improves the business processes. This implies that the analyst should have knowledge about analysis and improvement techniques. Techniques such as business process automation (BPA), business process improvement (BPI), or business process reengineering (BPR) can help the analyst to further develop the vision of the system.

4.1.3 Requirements negotiation

(31)

4.1.4 Requirements documentation

A requirements document usually contains problem descriptions, business domain and models, and a list of requirements. According to IEEE [1993], the software requirements specifications should be correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable, and traceable. The difficulty with requirements is that a large amount of the information is coming in variety representations and sources; therefore, one dilemma with the requirement documentation is the contained level of formality. For communication with the customer, an informal and natural language is desired, while for communication between developers, a more formal notation is desirable. In addition, developers are willing to talk about the system in terms of its procedures and data structures, and the customer prefers to talk about the system in terms of its general supporting functionalities. Furthermore, McConnell [1996] notices that customers tend to interpret requirements broadly, and developers tend to interpret them narrowly. To prevent ambiguity, the requirements can be written in a particular

requirements specification language instead of natural language. A successful documentation approach has to balance on the need to use a widely understood notation, with the importance of eliminating ambiguity and vagueness. Nowadays, UML is a popular standard for specifying software requirements (and design). Theoretically, in order to be sure of a good interpretation you must define together with the customer the right notation, and plan sessions/workshops to check whether the requirements specifications are interpreted correctly.

Al-Rawas and Easterbrook [1996] have done research about the communication problems concerning requirements. On the question whether customers found the notation of the

requirements readable, only 14% of the developers who respond said that their requirements are readable and understandable to end users, and 86% of the developers said that they would normally need additional explanation in order to understand the notations in which requirements are specified. Moreover, several studies4 show that half of the problems of all system failures are due to problems with requirements.

One of the dangers of requirements is that each person interprets things in the light of their own background assumptions [Al-Rawas and Easterbrook, 1996]. This is especially problematic when there is no opportunity to check whether the reader has interpreted the requirements as was intended. Al-Rawas and Easterbrook also conclude that documents are a poor substitute for interpersonal communication. Furthermore, they conclude that in general, end users have little or no influence on the choice of methods and notations in which their requirements are

represented, and consequently find the notations used by the software development company difficult to understand and validate.

As result from this research, the need of intensive interaction between the analyst and the stakeholders is essential. Also, it is fundamental to validate all assumptions and interpretations that have been made. It is important to realize that the requirements documentation will be used to communicate between personnel of the software development company, but also with stakeholders who have no detailed technical knowledge. Therefore, the requirements should be documented in a way that non-specialists can understand, but the correctness of the readers’ interpretation should always be checked. To properly document the requirements, you can make use of a structured natural language (templates); furthermore, for some sections it can be

appropriate to make use of a more formal/mathematical notation to reduce ambiguity. Moreover,

Software Development Process Improvement At Tiptop-ICT