Effects of Cognitive-driven Development in the Early Stages of the

Software Development Life Cycle

Victor Hugo Santiago C. Pinto

1,2 a

and Alberto Luiz Oliveira Tavares De Souza

Federal University of Par

a (UFPA) - Bel

em, PA, Brazil

Zup Innovation - S

ao Paulo, SP, Brazil

Keywords:

Cognitive-driven Development, Cognitive Complexity Metrics, Experimental Study.

Abstract:

The main goal of software design is to continue slicing the code to ﬁt the human mind. A likely reason for that

is related to the fact that human work can be improved by a focus on a limited set of data. However, even with

advanced practices to support software quality, complex codes continue to be produced, resulting in cognitive

overload for the developers. Cognitive-Driven Development (CDD) is an inspiration from cognitive psychol-

ogy that aims to support the developers in deﬁning a cognitive complexity constraint for the source code. The

main idea behind the CDD is keeping the implementation units under this constraint, even with the continuous

expansion of software scale. This paper presents an experimental study for verifying the CDD effects in the

early stages of development compared to conventional practices. Projects adopted for hiring developers in

Java by important Brazilian software companies were chosen. 44 experienced software engineers from the

same company attended this experiment and the CDD guided part of them. The projects were evaluated with

the following metrics: CBO (Coupling between objects), WMC (Weight Method Class), RFC (Response for a

Class), LCOM (Lack of Cohesion of Methods) and LOC (Lines of Code). The result suggests that CDD can

guide the developers to achieve better quality levels for the software with lower dispersion for the values of

such metrics.

1 INTRODUCTION

Separation of Concerns is one of the key principles of

software engineering (Liskov and Zilles, 1974; Par-

nas, 1972) that a software engineer can apply in all

software life-cycle. During analysis developers must

subdivide the problem and adopt an architectural pat-

tern in order to achieve proper modularity and cohe-

sion.

Software complexity increases as new features

are incorporated (Yi and Fang, 2020; Zuse, 2019;

Fraser et al., 2007) impacting its maintainability,

one of the most rewardful software quality attributes

(ISO:ISO/IEC 25010, 2011). Therefore, the separa-

tion of component responsibility must consider not

only the domain but also the cognitive complexity

of software as it goes through an evolution (Wang,

2006).

Over the years, researchers continue to seek bet-

ter and novel methods for handling complexity (Zuse,

2019; Clarke et al., 2016; Weyuker, 1988; Shepperd,

1988). Approaches have been adopted to support

https://orcid.org/0000-0001-8562-6384

code design based on architectural styles and code

quality metrics. Nevertheless, there is a lack of prac-

tical and clear strategies for changing the way that we

develop software with regard to maintenance efforts

efﬁciently.

Most research involving human cognition in soft-

ware engineering focuses on evaluating programs and

learning rather than on understanding how software

development could be guided by this factor (Duran

et al., 2018). Cognitive complexity departs from the

standard practice of using strictly numeric values to

assess software maintainability. It starts with the

precedents set by cyclomatic complexity (CYC) (Mc-

Cabe, 1976), but uses human judgment to determine

how the code’s structures should be interpreted. Shao

and Wang proposed a set of object-oriented cogni-

tive complexity metrics (Shao and Wang, 2003) and

Misra et al. (Misra et al., 2018) suggested a relation-

ship among basic control structures and correspond-

ing weights. Although cognitive complexity mea-

surements can help assessing the understandability of

source code, studies exploring how this strategy can

be used to reduce complexity in all stages of the de-

Pinto, V. and Tavares De Souza, A.

Effects of Cognitive-driven Development in the Early Stages of the Software Development Life Cycle.

DOI: 10.5220/0011009000003179

In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 2, pages 40-51

ISBN: 978-989-758-569-2; ISSN: 2184-4992

velopment process are lacking.

In the cognitive psychology area, cognitive load

refers to the amount of information that working

memory resources can hold at one time. Cognitive

Load Theory (CLT) (Sweller, 2010; Chandler and

Sweller, 1991; Sweller, 1988) is generally discussed

in relation to learning. Problems that require many

items to be stored in short-term memory may con-

tribute to an excessive cognitive load. According to

Sweller (Sweller, 2010), some material is intrinsi-

cally difﬁcult to understand and this is related to the

number of elements that must be simultaneously pro-

cessed in the working memory. Experimental stud-

ies performed by Miller (Miller, 1956) have suggested

that humans are generally able to hold only seven plus

or minus two units of information in short-term mem-

ory. Such limit for information units can be applied

for software once the source code has an intrinsic

complexity.

The developers are frequently affected by cogni-

tive overload when they need to add a feature, ﬁxing

a bug, improve the design or optimize resource us-

age. Based on CLT and Miller’s works involving cog-

nitive complexity the principles for a method called

Cognitive-Driven Development (CDD) were formu-

lated (Souza and Pinto, 2020). The main idea of

our proposed method is to try to standardize the way

developers with different specialization degrees con-

sider the complexity of the code. However, each de-

veloper can assume different intrinsically complex el-

ements in the code. We suggest that such elements

can be deﬁned in common agreement between the

members of the development team, considering ba-

sic control structures, code branches, project’s nature

and etc (Souza and Pinto, 2020). From these deﬁni-

tions, it is possible setting a feasible constraint for the

cognitive software complexity.

This paper presents an experimental study for ver-

ifying the CDD effects in the early stages of develop-

ment compared to development without a complexity

constraint. This involved carrying out a static code

analysis through object-oriented metrics. For this,

we selected three real projects that Brazilian software

companies adopt for hiring Java developers. 44 expe-

rienced software engineers from the same company

attended this experiment, part of them were guided

a complexity constraint, as suggested by the CDD.

The resulting projects were evaluated with the fol-

lowing metrics: CBO (Coupling between objects),

WMC (Weight Method Class), RFC (Response for a

Class), LCOM (Lack of Cohesion of Methods) and

LOC (Lines of Code). The result suggests that CDD

can be useful in the early stages of software develop-

ment and its principles can help developers to keep

the software with lower dispersion for the values of

such metrics.

2 COGNITIVE-DRIVEN

DEVELOPMENT

Cognitive load represents the limit of what the work-

ing memory can process (Sweller, 2010). When you

experience too much cognitive load, you cannot prop-

erly process code. A considerable part of the software

development effort is focused on understanding code

from other team members to apply changes later, add

new features and ﬁx faults. Human ability does not

follow the same proportion of the continuous expan-

sion of the software size, which makes this scenario

even more challenging.

Suppose that we have a single feature to be devel-

oped and a team with distinct specialization levels. It

is likely that different solutions will be delivered by

each programmer. This would not be a problem if

the intrinsic complexity degree for the source codes

were not different. Regardless of the solution, how

can we make all solutions remain at the same level

of complexity? Usually, classes are simple and over

time they become complex. How to standardize the

people’s perspective for the same code regarding the

understanding? Each developer may have a different

way of accounting for the elements that make it difﬁ-

cult to understand in the code. We assume that if the

code can be understood, it can be evolved more eas-

ily. In this way, our attempt was to deﬁne a measure

for the understanding degree based on the presence

of basic control structures on the code. With this in

mind, we were able to derive a complexity constraint

and evolve the code keeping this rule.

These observations were fundamental for the in-

vestigations in cognitive psychology, speciﬁcally in

CLT and in an important work known as “Magical

Number 7” to propose a method for software devel-

opment focusing on understanding called Cognitive-

Driven Development (CDD). The main CDD princi-

ple is considering a reasonable limit for intrinsic com-

plexity points (ICP) (Souza and Pinto, 2020) for re-

ducing the cognitive load.

A satisfactory complexity constraint can be de-

ﬁned in discussions in the early stages of development

and calibrated later, considering the project’s nature

and level of team expertise. Although our proposal

is that the deﬁnition of this constraint includes code

branches (if-else, loops, when, switch/case, do-while,

try-catch-ﬁnally and etc.), functions as an argument,

conditionals, contextual coupling - coupling with spe-

ciﬁc project classes and inheritance of abstract or

Effects of Cognitive-driven Development in the Early Stages of the Software Development Life Cycle

concrete class (extends), developers can include other

elements as ICPs, such as SQL instructions and anno-

tations. As a suggestion, speciﬁc features of program-

ming languages and frameworks/libraries are not con-

sidered as ICPs, it is understood that such features are

part of common knowledge and under the domain of

the developers.

Figure 1 presents a piece of code from a Java class

called GenerateHistoryController. This class was im-

plemented for a project

called “complexity-tracker”

which tries to provide indications of how complexity

increases during the software evolution process. To

clarify how ICPs are accounted, at the top of the ﬁg-

ure is shown the number 6 corresponding to the total

of ICPs: 4 points are related to contextual coupling

(lines 17, 22, 26 and 37) and the remaining points re-

fer to passing a function as an argument (lines 29 and

42).

3 RELATED WORK

A taxonomy of cognitive load in software engineer-

ing was provided by Gonc¸ales et al. (Gonc¸ales et al.,

2019). Based on this classiﬁcation, recent advances

are related to programming tasks and machine learn-

ing techniques to identify the programmer’s difﬁculty

level and code-level comprehensibility. CDD can be

applied as a complementary design to mitigate the in-

crease in cognitive complexity regardless of the soft-

ware size.

Duran et al. (Duran et al., 2018) proposed a frame-

work for the Cognitive Complexity of Computer Pro-

grams (CCCP) that describes programs in terms of

the demands they place on human cognition. CCCP

is based on a model that recognizes factors when we

are mentally manipulating a program. The contribu-

tion made by this work is to concentrate on the cog-

nitive complexity present in program designs rather

than on how the developers could be guided to gen-

erate source code reducing the cognitive load, as sug-

gested by CDD.

Object-oriented cognitive complexity metrics

were proposed in the work of Shao and Wang in (Shao

and Wang, 2003) and extended by Misra et al. (Misra

et al., 2018). Theoretical and empirical validation

was carried out to evaluate the proposed metrics based

on Weyuker’s properties (Weyuker, 1988). The main

CDD principle is not the proposition of new metrics

but to provide an easy way to deﬁne a feasible com-

plexity constraint for the creation (and evolution) of

implementation units prioritizing the understanding.

https://github.com/asouza/complexity-tracker

The development team can use any quality metric or,

if they prefer, basic control structures in the code to

support their classiﬁcation. With this in mind, the di-

rective suggested by CDD is to keep the complexity

for implementation units under a feasible constraint

to promote their readability, even with software com-

plexity expansion.

4 EXPERIMENTAL

METHODOLOGY

The goal of this paper is to verify the effects of em-

ploying the CDD in the early stages of develop-

ment in comparison to the conventional practices.

For this, an experimental study was carried out in

the industry context involving two groups of expe-

rienced developers who developed different projects

from the same company. The ﬁrst group focused on

using CDD, i.e., coding without exceeding a cogni-

tive complexity constraint, and the second was free to

use conventional development practices. Both groups

attended training about quality metrics and their im-

portance for evaluating the code during development.

Resultant implementation units in this study were

compared through object-oriented metrics to iden-

tify the differences among the samples individually.

A complementary analysis was also carried out tak-

ing into account the distribution of complexity in the

projects. Such investigation could promote discus-

sions about the beneﬁts of slicing the software to ad-

just it better in our human mind, reducing the cog-

nitive load and improving quality metrics. To this

end, we framed our research around the following Re-

search Questions (RQs):

RQ1: Is there a difference between the projects

developed under a cognitive complexity constraint in

comparison to those generated using conventional

practices in terms of quality metrics? In practice,

a previous study (Pinto. et al., 2021) was carried

out considering refactoring scenarios using known

projects by the Java developer community. As a

result, refactorings guided by cognitive complexity

constraints were better evaluated in quality metrics.

These results led us to question whether the same ef-

fect would be noticed in the early development stages

since there are usually not so many changes at the be-

ginning of a software project. To answer this ques-

tion, all the units created by the subjects were evalu-

ated using the same metrics

RQ2: Do the implementation units from the

projects developed with the CDD have a distribu-

tion closer to the quality metrics than in projects that

followed the non-CDD methods? In addition to the

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

12 @Controller

13 public class GenerateHistoryController {

15 // Contextual Coupling

16 @Autowired

17 private GenerateComplexyHistory generateComplexyHistory;

19 @PostMapping(value = "/generate-history")

// Contextual Coupling

21 @ResponseBody

22 public ResponseEntity<?> generate(@Valid GenerateHistoryRequest request,

23 UriComponentsBuilder uriComponent) {

25 // Contextual Coupling

26 InMemoryComplexityHistoryWriter inMemoryWriter = new InMemoryComplexityHistoryWriter();

28 // Function as an argument

29 new RepoDriller().start(() -> {

30 request.toMining(inMemoryWriter).mine();

31 });

32 }

34 @PostMapping(value = "/generate-history-class")

35 // Contextual Coupling

36 @ResponseBody

37 public ResponseEntity<?> generatePerClass(@Valid GenerateHistoryPerClassRequest request,

38 UriComponentsBuilder uriComponent) {

40 InMemoryComplexityHistoryWriter inMemoryWriter = new InMemoryComplexityHistoryWriter();

41 // Function as an argument

42 new RepoDriller().start(() -> {

43 request.toMining(inMemoryWriter).mine();

44 });

46 generateComplexyHistory.execute(request,inMemoryWriter.getHistory());

48 URI complexityHistoryGroupedReportUri = uriComponent.path(

49 "/reports/pages/complexity-by-class?projectId={projectId}")

50 .buildAndExpand(request.getProjectId()).toUri();

51 return ResponseEntity.created(complexityHistoryGroupedReportUri)

52 .build();

}

...

}

Figure 1: Class GenerateHistoryController.

analysis of the implementation units in an individual

way, we believe that a high-level view for all projects

can support the discussions about the effects produced

when using a complexity constraint in favor of the de-

velopment. The distribution degree for metrics values

could indicate how much complexity has been sliced

among the implementation units. With this in mind,

we would like to identify the effects of adopting a

complexity limit in code quality and if this element

had some inﬂuence on the developers in the separa-

tion of concerns and complexity distribution.

4.1 Project Selection

Three real projects used for the technical evaluation

and hiring of software engineers by important Brazil-

ian software companies were chosen: (i) Lend of liter-

ary works (Virtual Library), (ii) Real Estate Financing

and (iii) Payment Service Provider. This choice was

motivated by the need to use real projects, the chal-

lenges of which could prove the difﬁculty in dealing

with complexity even in the early stages of software

development. It should be noticed that such projects

do not require knowledge about frameworks, speciﬁc

libraries, and APIs, the developers only need to con-

centrate on using Java language. When starting the

experiment, the subjects received one of the projects

with the required classes to develop a complete ﬂow,

i.e., a minimal project and its corresponding require-

ments document.

Book lend and returns ﬂow should be imple-

mented for Virtual library. In general, users request

a loan for a certain number of days and a particular

type of book. There are copies with unrestricted or

restricted circulation and two types of users: standard

and research users. The ﬁrst user proﬁle can only ac-

cess exemplars of free circulation, while the second

can request access to any copies. A complete ﬂow for

Virtual Library starts from book loans until its returns.

More detailed speciﬁcations and constraints were pro-

vided to the developers.

The requirements document for Real Estate Fi-

nancing describes that several messaging systems are

employed to integrate different microservices. A list

of events containing data on loan proposals, real es-

tate guarantees and proponents was provided to the

subjects. Based on the validation rules, developers

need to return valid proposals after processing all

events. Note that a proposal is a template that contains

the loan information, including multiple proponents,

Effects of Cognitive-driven Development in the Early Stages of the Software Development Life Cycle

who are the people involved in the loan agreement.

The main idea of the Payment Service Provider

is that transactions related to purchases of products

from shopkeepers are received and then they can

make their withdrawals on top of the available balance

(receivables). The project provided contains pieces of

code responsible for sending the necessary data to im-

plement a complete ﬂow of generation of receivables.

There were also test scripts to verify the resulting

code covering different execution scenarios in these

projects. A class called “solution” was provided;

more speciﬁcally, its method “run” is the main entry

point of the solution for these projects. Therefore, all

tests are performed from this method and the classes

available in the package called “ready” could not be

modiﬁed during the experiment.

4.2 Planning

The planning followed the Goal Question Metric

(GQM) (Van Solingen et al., 2002) model for deﬁn-

ing the goals and evaluation methods. The principles

formulated by Wohlin et al. (Wohlin et al., 2012) were

also adopted for the experimentation process. The

characterization of this study can be formally sum-

marized as follows:

Analyzing the effects of the CDD in comparison to

conventional practices focusing on early-stage of

software development with the aim of comparing the

quality of resulting implementation units through

object-oriented metrics, regarding the distribution

degree to such metrics from the standpoint of

software engineers in the context of the industry.

The hypotheses and objectives for the experimen-

tal study are described in detail as follows. It should

be noticed that the single difference when using CDD

here is determining the ICPs and imposing a feasible

limit to guide the development, assuming that it helps

reduce the cognitive load on the code.

We suggested a complexity constraint of 7 ICPs

(maximum value) for the group that used the CDD as

a design rule for the code to be produced. The plan-

ning phase has six parts described in the following

subsections.

4.2.1 Context Selection

The experiment was conducted involving full and se-

nior developers from the same company and it was

performed in a controlled way.

4.2.2 Formulation of the Hypothesis

The RQ

was formalized into two hypotheses. Null

hypothesis (H

): There is no difference between the

conventional practices (Non-CDD) and the adoption

of a complexity constraint, suggested by CDD, in the

early stages of software development when compar-

ing the quality metrics adopted in this study.

Alternative Hypothesis (H

): There is a differ-

ence between the conventional practices and the adop-

tion of a complexity constraint, in the early stages

of software development under the perspective of the

quality metrics adopted in this study. These hypothe-

ses can be formalized by Equations 1 and 2:

: (µNon −CDD

metrics

= µCDD

metrics

)

(1)

: (µNon −CDD

metrics

6= µCDD

metrics

)

(2)

Similarly, the RQ

was formalized into two hy-

potheses. Null hypothesis (H

): There is no signif-

icant difference between the conventional practices

(Non-CDD) and the adoption of a complexity con-

straint, suggested by CDD, considering distribution

degree for the quality metrics adopted in this study,

since they are equivalent.

Alternative hypothesis (H

): There is a differ-

ence between the conventional practices and the adop-

tion of a complexity constraint, taking into account

the distribution degree for the quality metrics adopted

in this study. The hypotheses for the RQ2 can be for-

malized by Equations 3 and 4:

: (µNon −CDD

distribution

= µCDD

distribution

)

(3)

: (µNon −CDD

distribution

6= µCDD

distribution

)

(4)

4.2.3 Variable Selection

The dependent variables are: “the values from static

analysis for object-oriented metrics (CBO, WMC,

RFC, LCOM and LOC)”. CBO (Coupling between

objects): this counts the number of dependencies for

a certain class, such as ﬁeld declaration, method re-

turn types, variable declarations, etc. For this experi-

ment, dependencies to Java itself were ignored. WMC

(Weight Method Class), so-called McCabe’s complex-

ity (McCabe, 1976), this counts the number of branch

instructions in a class. RFC (Response for a Class)

counts the number of unique method invocations in a

class. LCOM (Lack of Cohesion of Methods) calcu-

lates the LCOM metric. Finally, LOC (Lines of code)

counts the lines of code, when ignoring empty lines

and comments. Note that these metrics were selected

because they are considered important according to

the code quality concerns of the company.

The independent variables are the projects

adopted in this study: Virtual library, Real Estate

Financing and Payment Service Provider.

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

4.2.4 Selection of Subjects

The subjects were selected according to convenience

sampling (Wohlin et al., 2012). 44 software engineers

who took part in the experiment were working on the

development of web projects and they had a degree of

knowledge of the Java language.

4.2.5 Experimental Design

The experimental principle of assembling subjects

in homogeneous blocks (Wohlin et al., 2012) was

adopted to increase the accuracy of this experiment.

We looked for ways to mitigate interference from the

subjects’ experience in the treatment outcomes. One

pilot experiment were carried out with a restricted

number of subjects. It should be noted that they were

not included in the real experiment and the gathered

data were helpful in select proper projects and fea-

tures to be developed as a challenge. In addition, this

process enabled the groups to be rearranged for the

real experiment.

When separating the subjects into balanced

groups, we ﬁrst asked them to ﬁll out a Categoriza-

tion Form with questions about their experience in ar-

eas related to the experiment, a self-evaluation. Based

on the data that was obtained, we divided them into

two blocks with the same number of subjects. How-

ever, not all developers were invited and ﬁlled the

categorization form accepting the participation in the

date deﬁned attended the experiment. We had al-

most a hundred developers who attended the train-

ing about software quality metrics and how this could

guide software development. The main CDD prin-

ciples were taught for half of them. Finally, more

than 60 subjects attended the experiment but only

44 projects were considered valid, i.e., the solution

was completely developed and veriﬁed using the test

scripts provided in the study. From this set, one group

with 26 developers had to apply conventional devel-

opment practices focusing on quality and the metrics

explained during the training. In contrast, the second

group with 18 subjects attended a planned training

session about the CDD principles to generate high-

quality code without exceeding the complexity con-

straint for each software artifact.

The Categorization Form included questions re-

garding knowledge about: (i) Object-oriented pro-

gramming, Java, the number of books read about

software development (e.g., Java, Clean Code, Clean

Architecture, Domain-Driven Design, etc.) and the

number of real (corporate) projects with active par-

ticipation; (ii) professional experience in Java (More

than 3 years, 2 to 3 year or only 1 year); (iii) known

software metrics by them and that can eventually be

used to improve code cohesion and the separation of

concerns; (iv) programming practices and code de-

sign that they employ daily; Finally, (v) testing ac-

tivities and tools.

Figure 2 describes the results of the application

of this form in a grouped bar chart. The subjects

“S27-S15” (Part A) belong to the group that applied

CDD principles (“CDD group”) in their projects and

the subjects “S25-S80” (Part B) followed conven-

tional practices without a cognitive complexity con-

straint (“Non-CDD group”). This chart takes account

of numeric values (number of books, courses and

real/corporate projects) for each subject. The main

reason to use these elements is that the “time experi-

ence” is a relative measurement. For instance, likely,

a programmer with little time for development but

who has attended a higher number of projects can per-

form better than a person with more time experience

and attended a low number of projects. Nevertheless,

data related to professional experience were gathered

in terms of years of Java development. More than 3

years: 11 (CDD group) and 14 (Non-CDD group);

Only 1 year: 2 (CDD group) and 5 (Non-CDD group).

Finally, Between 2 to 3 years: 5 (CDD group) and 7

(Non-CDD group).

Figure 2: Gathered data with the Categorization Form.

Additional information was also obtained to de-

ﬁne this separation which can be described as fol-

lows, including corresponding percentages of an-

Effects of Cognitive-driven Development in the Early Stages of the Software Development Life Cycle

swers. Such answers were also crucial in determining

which subjects should develop which projects.

With regard to software metrics, we asked the

participants which one they use to generate code

thinking about readability, cohesion and separation

of concerns. The choices/answers where as fol-

lows: Fan-in/Fan-out (9.09 %), Cyclomatic Com-

plexity (27.27 %), KLOC (29.55 %), Number of root

classes (9.09 %), Coupling between objects (72.73

%), LCOM (47.73 %), Class size (47.73 %), Coupling

factor (43.18 %) or Software Maturity Index (SMI)

value (11.36 %).

As regards the programming practices and code

design, most subjects underlined the importance of

following principles from: Clean Architecture (52.27

%), SOLID (79.55 %), Domain Driven Design (DDD)

(38.64 %), (Test Driven Development (TDD) (45.45

%), General responsibility assignment software pat-

terns (GRASP) (6.82 %) and Conventional practices

for code cohesion (47.73 %). Finally, for testing

techniques they were as follows: functional testing

techniques (56.82 %), structural testing techniques

(31.82 %) and some subjects reported that they do not

perform testing activities in a systematic way (11.36

%).

4.2.6 Instrumentation

A document was provided to the subjects that de-

scribed constraints and guidelines to assist them in

both the development and the data submission pro-

cess, as follows:

• The initial package structure had to be kept;

• Automated tests must be kept working completely

without any changes;

• It is not allowed to modify the classes available in

an speciﬁc package (called “pronto”).

Concerning the guidelines, our suggestion was to

fork the corresponding repository from GitHub and

import it into IDEs. Each subject was assigned to de-

velop just one of the three projects; the researchers

made this deﬁnition considering the balance of groups

concerning projects. After the development, the sub-

jects were requested to submit the URLs of their re-

mote repositories using a web form.

4.3 Operation

Once the experiment had been deﬁned and planned, it

was undertaken through the following stages: prepa-

ration, operation and validation of the collected data.

4.3.1 Preparation

At this stage, the subjects were committed to exper-

imenting and were made aware of its purpose. They

accepted the conﬁdentiality terms regarding the pro-

vided data, which would be only used for research

purposes, and were granted their freedom to withdraw

by signing a Consent Form. In addition, other objects

were provided:

• Characterization Form: A questionnaire in which

the subjects assessed their knowledge of the tech-

nologies and concepts used in the experiment;

• Instructions: A document describing all the

stages, including the instructions about the sub-

mission process of the forked repository and

classes provided for each project;

• Data Collection Form: Document to be ﬁlled in

by the participants with the information about the

projects and their suggestions to improve future

experimental studies..

The platform adopted had Java as its implementa-

tion language and Eclipse or IntelliJ IDEA as devel-

opment environments. The groups attended 1-hour

training in a web meeting format separately (one for

Non-CDD and the other for CDD group). In addition,

the meetings were recorded and shared to clarify the

main goal for our study: producing source code us-

ing excellent practices focusing on readability. Com-

plementary materials were provided and a webchat

was created for settling doubts before the experiment,

which lasted one week.

For the CDD group, a class from a real-world

project was selected to illustrate the identiﬁcation pro-

cess of ICPs and deﬁne a complexity constraint to

keep a feasible understanding degree for all develop-

ers in a supposed team. The CDD fundamentals were

explained by highlighting the importance of deﬁning

a cognitive complexity constraint to guide the devel-

opment (Souza and Pinto, 2020).

The maximum time to be spent for all subjects

during the development activity was deﬁned as four

and a half hours. This includes the time to understand

the project speciﬁcations, create new classes, include

and ﬁx features and ﬁnally, execute the test scripts.

This time interval was deﬁned based on the average

time in a pilot study.

4.4 Data Analysis

This section examines our ﬁndings. The analysis is

divided into two areas: (i) descriptive statistics and

(ii) hypotheses testing.

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

4.4.1 Descriptive Statistics

The quality of the input data (Wohlin et al., 2012) was

veriﬁed before the statistical methods were applied.

There is a risk that incorrect data sets can be obtained

due to some error or the presence of outliers, which

are data values much higher or much lower than the

remaining data.

The metrics adopted in this study have different

scales and when taking note of the “resulting imple-

mentation units” we decided to be conservative and

analyze all the gathered data, in an individual way

per metric. When clarifying descriptive statistics and

making comparisons, it is essential to explain that the

raw data for the metrics were analyzed. We also ap-

plied the standard deviations to measure the amount

of variation or dispersion of a set of values.

Standard deviations were calculated for each

project per subject, considering the implementation

units created during our study. Table 1 includes these

kinds of data, respectively. The data were separated

considering the projects, subjects from CDD or Non-

CDD group and ﬁnally, the SD(s) that is the standard

deviation of the sample standard deviations (s) for val-

ues of the metrics. For instance, in the left part of the

Table, a version of “Payment Service Provider” was

developed by S40 and the standard deviations for the

values collected for the metrics: CBO, WMC, RFC,

LCOM and LOC were: 1.41, 1.87, 2.59, 1.52 and

8.88, respectively. From another perspective, the stan-

dard deviations for CDD group (SD(s)) were 0.84,

1.13, 3.86, 1.30 and 15.90.

Although it is difﬁcult to have a generalizable re-

sult, in most cases the standards deviations (SD(s)) for

the projects delivered by Non-CDD group are more

than the values for SD(s) considering the projects

developed by CDD group. This fact can raise sev-

eral discussions since all the projects were started

in this experiment, i.e., it was not expected to have

a difference between the dispersion of the metrics

for the projects developed by the two groups in the

early stages of software development. We assume that

adopting a cognitive complexity constraint, as sug-

gested by the CDD, enhances the possibility of slicing

the features. This contributes to achieving better val-

ues for the metrics adopted in this study.

Figure 3 presents a summarized view for the

SD(s), taking into account all versions created by sub-

jects from CDD and Non-CDD group. This chart is

helpful to observe that the subjects that followed a

complexity constraint were implicitly guided to im-

prove the code quality. This behavior of the subjects

could be expected but the existence of a restriction

forced the results.

For Virtual library (A) and Real Estate Financing

(B) it is clear that versions implemented by Non-CDD

group had dispersion measures higher than the ver-

sions created by CDD group. Nonetheless, for the

versions of the Payment Service Provider (C) this per-

ception is not the same because the dispersion mea-

sures between the groups were very close. This effect

can be justiﬁed because this project is less complex

than the others in terms of features/business rules to

be implemented. Thus, we can not observe a very

distant dispersion measure between the values of the

metrics for the implementation units.

Figure 3: Standard deviations considering all projects

(SD(s)).

4.4.2 Hypotheses Testing

Metrics - Since some statistical tests only apply if

the population follows a normal distribution, before

choosing a statistical test, we examined whether our

gathered data departed from linearity. This involved

conducting the Shapiro-Wilk normality test to check

if the samples had a normal (ND) or non-normal dis-

tribution (NND).

Effects of Cognitive-driven Development in the Early Stages of the Software Development Life Cycle

Table 1: Standard deviations for the metrics considering all versions of projects per subject.

Payment Service Provider Real Estate Financing Virtual library

CDD group CDD group CDD group

CBO WMC RFC LCOM LOC CBO WMC RFC LCOM LOC CBO WMC RFC LCOM LOC

S27 2.15 1.46 3.48 3.68 4.24 S13 0.93 3.23 1.13 4.0 10.27 S7 3.76 1.57 3.58 0 5.44

S28 0.00 4.00 13.00 0.00 46.00 S16 1.42 4.11 4.16 8.45 13.57 S10 7.00 9.00 13.00 3 26.00

S32 1.64 3.65 3.54 2.05 14.72 S17 2.73 3.06 3.62 7.84 12.16 S11 2.31 1.53 0.58 0 4.04

S40 1.41 1.87 2.59 1.52 8.88 S18 1.96 3.59 11.82 14.09 11.82 S12 3.87 1.91 4.36 1.5 10.47

S42 2.00 2.22 4.20 0.58 10.02 S19 1.59 5.20 4.61 0.33 12.89 S15 6.00 6.00 15.00 0 19.00

S81 2.30 1.35 5.71 2.23 3.82 S24 1.10 2.39 4.34 0.45 8.22

SD(𝑠)

1.88 3.37 6.31 1.34 9.34

SD(𝑠)

0.84 1.13 3.86 1.30 15.90 S79 0.60 1.92 3.48 5.0 7.25

SD(𝑠)

0.71 1.09 3.33 4.87 2.40

Non-CDD group

CBO WMC RFC LCOM LOC Non-CDD group Non-CDD group

S25 1.90 3.49 7.89 5.65 9.33 CBO WMC RFC LCOM LOC CBO WMC RFC LCOM LOC

S35 1.15 1.15 1.00 0.00 1.00 S53 1.82 4.24 6.01 9.08 15.29 S8 2.94 1.71 2.38 0.00 3.77

S64 2.01 1.05 2.15 1.32 4.32 S55 2.01 4.36 3.18 21.26 14.85 S46 3.35 3.95 4.22 0.00 15.62

S66 3.16 4.62 6.31 11.05 15.83 S57 1.00 12.00 12.00 6.00 44.00 S47 7.00 18.00 20.00 21.00 61.00

S69 2.00 1.00 1.53 0.58 3.46 S59 2.42 3.32 4.70 10.76 10.65 S48 7.00 29.00 8.00 15.00 66.00

S70 1.77 4.03 6.29 5.55 15.84 S61 1.92 2.77 13.86 29.47 15.82 S50 2.36 1.73 1.91 0.00 5.25

S71 0.89 3.13 2.88 7.28 14.34 S67 0.74 5.45 3.52 16.99 11.26 S54 7.00 5.00 20.00 1.00 29.00

S74 0.58 1.53 6.11 3.21 11.55 S73 1.29 6.55 11.53 15.93 27.98 S80 1.53 3.51 4.73 1.15 10.69

S76 1.72 0.90 3.05 0.49 5.77 S85 1.91 7.27 25.50 22.90 34.30

SD(𝑠)

2.45 10.48 7.93 8.76 26.10

S87 0.71 3.54 9.90 0.00 25.46

SD(𝑠)

0.57 2.95 7.50 7.84 12.24

S89 1.00 4.00 15.00 3.00 31.00

SD(𝑠)

0.76 1.45 4.21 3.57 9.34

Table 2 shows the results of the normality tests for

all samples, i.e., averages of the values for the metrics

in relation to the versions implemented by the sub-

jects. For instance, considering all metrics adopted in

this study for versions of “Payment Service Provider”

developed by Non-CDD and CDD groups we do not

reject the hypothesis that the data are from a normally

distributed population. This is different when consid-

ering the metric LCOM for “Real State Financing”

because both Non-CDD and for CDD group we do

not reject the hypothesis that the data are from a non-

normal distribution.

Variance testing was performed for all metrics

considering the solutions produced by Non-CDD and

CDD groups for “Payment Service Provider”. The

p-values were 0.235, 0.5766, 0.8666, 0.1007 and

0.02448 for CBO, WMC, RFC, LCOM and LOC

(based on α = 0.05, respectively). Unpaired Two-

Samples T-test (or unpaired t-test) can be used to com-

pare the means of two unrelated groups of samples.

This kind of statistical testing was conducted and

the results for p-values were 0.5386, 0.8331, 0.9524,

0.2708 and 0.6592 for CBO, WMC, RFC, LCOM and

LOC, respectively. Therefore, we can not reject the

null hypothesis for the difference between the ver-

sions implemented by Non-CDD and CDD groups,

in terms of the metrics (on averages) adopted in this

study.

The same testing was carried out for the solutions

of “Real State Financing” considering the following

metrics: CBO, WMC, RFC and LOC. The p-values

were 0.1959, 0.00376, 0.2256 and 0.004085. With

this in mind, Unpaired Two-Samples T-test was ver-

iﬁed and the p-values were 0.5753, 0.04231, 0.2091

and 0.03565. Therefore, it is possible to reject the null

hypothesis for WMC and LOC, considering α = 0.05.

Similarly, variance testing was performed for the

implementations of “Virtual library” considering just

CBO and LOC due to the values from the Shapiro-

Wilk normality test, as aforementioned. The p-values

were 0.7245 and 0.01444. Unpaired Two-Samples T-

test ware also veriﬁed and as a result, the p-values

were 0.8603 and 0.2184. Finally, we can not reject

the null hypothesis for CBO and LOC considering the

versions produced by Non-CDD and CDD groups.

The Mann-Whitney U Test is a nonparametric test

that can be used when one of the samples does not

follow a normal distribution. We applied this kind of

testing for LCOM considering the solutions for “Real

State Financing” and for WMC, RFC and LCOM for

“Virtual library”. Summarizing the results, the value

for p-value with respect to the LCOM samples was

0.005905. Thus, there is a difference between the ver-

sions for “Real State Financing” produced by Non-

CDD and CDD groups, i.e., it is possible to reject

the null hypothesis for LCOM is this project. On the

other hand, we can not reject the null hypothesis for

WMC, RFC and LCOM for “Virtual library”, the val-

ues for p-values were 0.8763, 0.8705 and 0.6647, re-

spectively.

Hypothesis Testing - Standard deviations: Simi-

larly, we applied statistical tests to determine if there

is a difference between the standard deviations for the

values of the metrics.

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

Table 2: Shapiro-Wilk normality tests for metrics samples

(averages).

Payment Service Provider

Metric Samples Results

CBO

Non-CDD p-value = 0.1604 ND

CDD p-value = 0.6543

WMC

Non-CDD p-value = 0.241 ND

CDD p-value = 0.8814

RFC

Non-CDD p-value = 0.1015 ND

CDD p-value = 0.242

LCOM

Non-CDD p-value = 0.2942 ND

CDD p-value = 0.4326

LOC

Non-CDD p-value = 0.06566 ND

CDD p-value = 0.06413

Real State Financing

CBO

Non-CDD p-value = 0.5138 ND

CDD p-value = 0.6742

WMC

Non-CDD p-value = 0.1902 ND

CDD p-value = 0.2505

RFC

Non-CDD p-value = 0.6314 ND

CDD p-value = 0.7724

LCOM

Non-CDD p-value = 0.01147 NND

CDD p-value = 0.006358

LOC

Non-CDD p-value = 0.1637 ND

CDD p-value = 0.575

Virtual library

CBO

Non-CDD p-value = 0.1153 ND

CDD p-value = 0.6922

WMC

Non-CDD p-value = 0.005702 NND

CDD p-value = 0.3644

RFC

Non-CDD p-value = 0.03518 NND

CDD p-value = 0.2551

LCOM

Non-CDD p-value = 0.002211 NND

CDD p-value = 0.04824

LOC

Non-CDD p-value = 0.0508

CDD p-value = 0.6462 ND

Variance testing was performed for CBO and

LCOM samples considering the solutions produced

by Non-CDD and CDD groups for “Payment Service

Provider”. The p-values were 0.724 and 0.03802. Un-

paired Two-Samples T-test ware also veriﬁed and as

results, the p-values were 0.9062 and 0.1571. There-

fore, it is not possible to reject the null hypothesis for

the measures of the dispersion of the set of values re-

fer to such metrics.

Similarly, we carried out the variance testing for

CBO, WMC, LCOM and LOC for “Real State Fi-

nancing” and the results for p-values were 0.63,

0.06206, 0.007702 and 0.04069. Therefore, it is pos-

sible to reject the null hypothesis only for the LCOM

and LOC samples. Finally, for “Virtual library” the

variance testing was applied only for LOC sample,

resulting in 0.2719 as p-value. This indicates that we

can not reject the null hypothesis for such metric in

this project.

Mann-Whitney U Test was applied for the WMC,

RFC and LOC samples with respect to the solutions

produced for “Payment Service Provider” and the p-

values were 0.9199, 1 and 0.8836, respectively. Thus,

it is not possible to reject the null hypothesis for such

WMC, RFC and LOC samples in this project. This

same test was carried out for RFC sample taking into

account the “Real State Financing” and the p-value

was 0.1206. Finally, CBO, WMC, RFC and LCOM

samples obtained for “Virtual library” were evaluated

using Mann-Whitney U Test and as p-values the re-

sults were: 0.9341, 0.4318, 0.7449 and 0.6647. Fi-

nally, both for “Real State Financing” and “Virtual

library”, it is not possible to reject the null hypothe-

sis concerning the difference between the dispersion

in the values for such metrics.

4.5 Threats to Validity

Internal Validity. Level of Experience of Subjects:

One can argue that the heterogeneous knowledge of

the subjects could have affected the collected data.

To overcome this threat, the participants were divided

into two-balanced blocks that accounted for their level

of experience.

During the training, the subjects that had to apply

the cognitive complexity constraint attended a train-

ing session on how to use this limit to guide the de-

velopment process. Thus, they adopted conventional

practices during programming like the other group but

following such limit;

Productivity under evaluation: the results may

have been affected because the subjects often tend to

think they are being evaluated during an experiment.

We attempted to overcome this problem by explaining

to the subjects that no one was being evaluated and

their participation would be treated as anonymous;

Validity by Construction. Hypothesis expectations:

the subjects already knew the researchers, a point

which is reﬂected in one of our hypotheses. This issue

could have affected the collected data and caused the

experiment to be less impartial. Impartiality was kept

by insisting that the participants had to keep a steady

pace throughout the study. The main challenge for

the researchers was to perform this experiment com-

pletely using a web meeting room due to the restric-

tions of social isolation and the pandemic caused by

COVID-19.

External Validity. Interaction between conﬁguration

and treatment: it is possible that the exercises car-

ried out in the experiment are not accurate for every

Java web application. To mitigate this threat, different

projects were selected based on the real-world crite-

rion, i.e., the complexity of the applications and the

Effects of Cognitive-driven Development in the Early Stages of the Software Development Life Cycle

Table 3: Shapiro-Wilk normality tests for standard devia-

tions samples.

Payment Service Provider

Metric Samples Results

CBO

Non-CDD p-value = 0.3137 ND

CDD p-value = 0.1119

WMC

Non-CDD p-value = 0.04006 NND

CDD p-value = 0.1895

RFC

Non-CDD p-value = 0.1956

CDD p-value = 0.01326 NND

LCOM

Non-CDD p-value = 0.1196 ND

CDD p-value = 0.9022

LOC

Non-CDD p-value = 0.4079

CDD p-value = 0.01003 NND

Real State Financing

CBO

Non-CDD p-value = 0.4938 ND

CDD p-value = 0.8474

WMC

Non-CDD p-value = 0.1584 ND

CDD p-value = 0.9514

RFC

Non-CDD p-value = 0.1098

CDD p-value = 0.01573 NND

LCOM

Non-CDD p-value = 0.921 ND

CDD p-value = 0.6014

LOC

Non-CDD p-value = 0.08716 ND

CDD p-value = 0.4502

Virtual library

CBO

Non-CDD p-value = 0.04983 NND

CDD p-value = 0.6808

WMC

Non-CDD p-value = 0.01113 NND

CDD p-value = 0.08483

RFC

Non-CDD p-value = 0.02475 NND

CDD p-value = 0.3184

LCOM

Non-CDD p-value = 0.002712 NND

CDD p-value = 0.04595

LOC

Non-CDD p-value = 0.08004 ND

CDD p-value = 0.4999

fact that the researchers have contact with real-world

projects of the company.

Conclusion Validity. Measure reliability: this refers

to the metrics used to measure the development effort.

To mitigate this threat, we only used the time spent,

which was captured in forms ﬁlled in by the subjects.

This was useful only to observe the Productivity of

the developers;

Low Statistical Power: a statistical test can reveal re-

liable data. Unpaired Two-Samples T-test and Mann-

Whitney U Test were adopted to analyze the metrics

for all the delivered versions statistically.

5 CONCLUSION

Human factors in software engineering impose sev-

eral challenges. The maintenance can consume more

resources than all the effort spent in the creation of

new software (Lenberg et al., 2015). Cognitive Load

Theory is a framework for investigating the effects

of human cognition on task performance and learn-

ing (Sweller, 1988; Sweller, 2010). Cognition is con-

strained by a bottleneck created by working mem-

ory, in which we humans can only hold a handful

of elements at a time for active processing; to the

best of our knowledge, the cognitive complexity con-

straint has not been applied previously to guide soft-

ware development. Thus, we proposed a method

called Cognitive-driven development (CDD) (Souza

and Pinto, 2020) in which a pre-deﬁned cognitive

complexity for application code can be used to limit

the number of intrinsic complexity points and tack-

ling the growing problem of software complexity, by

reducing the cognitive overload.

The main focus of this work was to assess the ef-

fects of adopting a complexity constraint in the early

stages of software development. Software Develop-

ment Companies in Brazil use the projects chosen for

this study for hiring new software engineers. 44 expe-

rienced developers attended our experiment, divided

into Non-CDD and CDD groups. Both groups were

aware of the importance of quality metrics and the

need to produce high-quality code for other develop-

ers to understand. The CDD group received different

training that included practices guided by a cognitive

complexity limit, including our suggestions for ele-

ments to set a constraint.

The main ﬁndings of our experiment showed that

in terms of quality metrics (on average) there was no

statistically signiﬁcant difference between samples of

CBO, WMC, RFC, LCOM and LOC, with or with-

out complexity constraint, i.e., projects developed by

Non-CDD and CDD groups. However, this is not true

for WMC, LOC, and LCOM samples regarding the

“Real State Financing” because the projects delivered

by the CDD group were better evaluated considering

such metrics. Regarding the standard deviations for

the samples, only LCOM and LOC for “Real State Fi-

nancing” had differences when employing a complex-

ity constraint. In addition, it was possible to note a

lower dispersion for the values of the metrics samples

gathered when analyzing the projects implemented

by the CDD group. Such results can be considered

positive since all projects were evaluated in the early

stages of development. A package containing the

tools, materials and more details about the experimen-

tal stages is available at https://bit.ly/3xUdsuo.

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

As future investigations, we intend to explore the

following factors: (i) deﬁning an automated refactor-

ing strategy employing search-based refactoring and

cognitive complexity constraints and (ii) carrying out

new empirical-based studies to evaluate restructured

projects with CDD principles, by exploring the num-

ber of faults and understanding development in the

medium and long term.

ACKNOWLEDGEMENT

This study was ﬁnanced in part by the PROPESP and

PROINTER/UFPA.

REFERENCES

Chandler, P. and Sweller, J. (1991). Cognitive load theory

and the format of instruction. Cognition and instruc-

tion, 8(4):293–332.

Clarke, P., O’Connor, R. V., and Leavy, B. (2016). A com-

plexity theory viewpoint on the software development

process and situational context. In Proceedings of

the International Conference on Software and Systems

Process, pages 86–90.

Duran, R., Sorva, J., and Leite, S. (2018). Towards an anal-

ysis of program complexity from a cognitive perspec-

tive. In Proceedings of the 2018 ACM Conference on

International Computing Education Research, pages

21–30.

Fraser, S. D., Brooks, F. P., Fowler, M., Lopez, R.,

Namioka, A., Northrop, L., Parnas, D. L., and

Thomas, D. (2007). “No Silver Bullet” Reloaded:

Retrospective on “Essence and Accidents of Software

Engineering”. In Companion to the 22nd ACM SIG-

PLAN Conference on Object-Oriented Programming

Systems and Applications Companion, OOPSLA ’07,

page 1026–1030, New York, NY, USA. Association

for Computing Machinery.

Gonc¸ales, L., Farias, K., da Silva, B., and Fessler, J. (2019).

Measuring the cognitive load of software developers:

a systematic mapping study. In 2019 IEEE/ACM 27th

International Conference on Program Comprehension

(ICPC), pages 42–52. IEEE.

ISO:ISO/IEC 25010 (2011). Systems and software engi-

neering – Systems and software Quality Requirements

and Evaluation (SQuaRE), System and software qual-

ity models. International Organization for Standard-

ization ISO.

Lenberg, P., Feldt, R., and Wallgren, L. G. (2015). Human

factors related challenges in software engineering–an

industrial perspective. In 2015 ieee/acm 8th interna-

tional workshop on cooperative and human aspects of

software engineering, pages 43–49. IEEE.

Liskov, B. and Zilles, S. (1974). Programming with abstract

data types. ACM Sigplan Notices, 9(4):50–59.

McCabe, T. J. (1976). A complexity measure. IEEE Trans-

actions on software Engineering, (4):308–320.

Miller, G. A. (1956). The magical number seven, plus or

minus two: Some limits on our capacity for processing

information. Psychological review, 63(2):81.

Misra, S., Adewumi, A., Fernandez-Sanz, L., and Damase-

vicius, R. (2018). A suite of object oriented cognitive

complexity metrics. IEEE Access, 6:8782–8796.

Parnas, D. L. (1972). On the criteria to be used in decom-

posing systems into modules. In Pioneers and Their

Contributions to Software Engineering, pages 479–

498. Springer.

Pinto., V., Tavares de Souza., A., Barboza de Oliveira., Y.,

and Ribeiro., D. (2021). Cognitive-driven develop-

ment: Preliminary results on software refactorings.

In Proceedings of the 16th International Conference

on Evaluation of Novel Approaches to Software En-

gineering - Volume 1: ENASE,, pages 92–102. IN-

STICC, SciTePress.

Shao, J. and Wang, Y. (2003). A new measure of soft-

ware complexity based on cognitive weights. Cana-

dian Journal of Electrical and Computer Engineering,

28(2):69–74.

Shepperd, M. (1988). A critique of cyclomatic complexity

as a software metric. Software Engineering Journal,

3(2):30–36.

Souza, A. L. O. T. d. and Pinto, V. H. S. C. (2020). Toward

a deﬁnition of cognitive-driven development. In Pro-

ceedings of 36th IEEE International Conference on

Software Maintenance and Evolution (ICSME), pages

776–778.

Sweller, J. (1988). Cognitive load during problem solving:

Effects on learning. Cognitive science, 12(2):257–

285.

Sweller, J. (2010). Cognitive load theory: Recent theoreti-

cal advances.

Van Solingen, R., Basili, V., Caldiera, G., and Rombach,

H. D. (2002). Goal question metric (gqm) approach.

Encyclopedia of software engineering.

Wang, Y. (2006). Cognitive complexity of software and its

measurement. In 2006 5th IEEE International Confer-

ence on Cognitive Informatics, volume 1, pages 226–

235. IEEE.

Weyuker, E. J. (1988). Evaluating software complexity

measures. IEEE transactions on Software Engineer-

ing, 14(9):1357–1365.

Wohlin, C., Runeson, P., H

ost, M., Ohlsson, M. C., Reg-

nell, B., and Wessl

en, A. (2012). Experimentation in

Software Engineering. Springer Berlin Heidelberg.

Yi, T. and Fang, C. (2020). A complexity metric for object-

oriented software. International Journal of Computers

and Applications, 42(6):544–549.

Zuse, H. (2019). Software complexity: measures and meth-

ods, volume 4. Walter de Gruyter GmbH & Co KG.

Effects of Cognitive-driven Development in the Early Stages of the Software Development Life Cycle