Inventorying Systems: An Action Research

Vanessa Soares

, Rejane Figueiredo

, Elaine Venson

, Laís de Araújo

and Rafael Queiroz

ITRAC – Information Technology, Research and Application Center, University of Brasília, Brasília, Brazil

TU Darmstadt, Main University, Darmstadt, Germany

Keywords: Inventory, Maintenance, Documentation, Legacy Systems, Action Research.

Abstract: Maintainability, characterized by ease of understanding, is strongly related to the availability of correct and

update information about the system and the ease of maintenance staff in understanding it. The Brazilian

public administration has many legacy systems in maintenance whose documentation is non-existent or

incomplete. The main purpose of this work was to identify the inventorying attributes that have to be

recorded to support systems maintenance. The methodology applied was action research whose cycles

allowed identifying the attributes required by each one of the stakeholders, civil servants and providers to

inventory the systems, as well as how to register and access their attributes. As a result, the set of attributes

produced by the interaction between researchers and stakeholders was considered essential to the

infrastructure and systems areas, managers, and providers.

1 INTRODUCTION

Systems maintenance is held to be one of the

costliest stages of Software Engineering and a major

part of the effort is spent in understanding the

system. The ease in understanding it is strongly

related to the availability of information on the

system and to how easily it is understood by the

maintenance team (Anquetil et al., 2007; Cozzetti et

al., 2006).

Some works focus on the documentation for

software maintenance (Souza et al., 2006); some

offer support tools, such as the one that uses tools

based on the Wiki as a repository (Salvaneschi,

2011), or on categorizing software applications

(McMillan et al., 2011). Some other concentrate on

knowledge management, with the use of different

techniques such as post-mortem analysis and post-

partum analysis (Anquetil et al., 2007; Klint and

Verhoef, 2002).

However, Ben-Menachem and Marliss (2004;

2005) point the importance of understanding and

managing software assets in a collective way and

within the corporate domain. The authors point that

a system inventory is not simply a list of programs

by host for release or license management, but rather

a repository containing software items’ information

to support both management and program evolution.

Standards exist in this context that provide

support on the inventorying of systems. The

ISO/IEC 14764 (2005) standard deals with one of

the primary processes of the ISO/IEC 12207 (2008)

standard, namely Software Maintenance and

provides guidance on the planning, execution,

control, evaluation and closing of the maintenance

process. From these standards, the ISO/IEC 15289

(2015) aims to provide requirements for identifying

and planning the specific information items

(information products) to be developed and revised

during systems and software life cycles and service

processes.

Brazilian Public Administration (BPA) has many

legacy systems in maintenance whose

documentation is either non-existent or incomplete.

On top of that one also has the issue that a good part

of systems development and maintenance is

outsourced (Brazil, 2012a).

The inventorying of systems in Brazilian public

organizations is a requirement of prevailing

legislation (Brazil, 2014; 2012b) both during

systems development and maintenance, and in the

closing stages, and in the contractual transition of

suppliers.

In spite of defining the guidelines, the norms do

296

Soares, V., Figueiredo, R., Venson, E., Araújo, L. and Queiroz, R.

Inventorying Systems: An Action Research.

DOI: 10.5220/0006336602960303

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 1, pages 296-303

ISBN: 978-989-758-247-9

not specify the information that should be

inventoried. In this context, the research question is:

which inventory items should be used to build the

work was to identify the inventorying attributes that

will be registered to support the legacy system

maintenance of a Brazilian public organization,

named here as Ministry.

The methodology applied was action research,

from which a strategy was defined and executed to

determine the items in systems inventorying,

considering the needs of the many units contained in

the Ministry, as well as those of the suppliers

involved. The data was collected in interviews,

meetings, and through participant observation.

This article is structured in sections. Section 2

has a survey on Systems Inventorying. Section 3

presents the standard on information items. Section

4 lays the plan for action research. Section 5

describes the stages in action research. Section 6

presents the process for the identification of the

inventorying attributes. Section 7 provides an

analysis of the results. Section 8 presents the

conclusions.

2 INVENTORYING OF SYSTEMS

Most organizations find it difficult to gather and

supply information for the management of their

software items. As most IT professionals understand

that the goal of the work to manage software

configuration is summed in individually managing

the software versions that have been and/or will be

delivered, it is common that these organizations

have no repository with data on what the existing

systems are, and their location, and who are the

parties responsible for them, or even the relation of

dependency that exist amongst them (Salvaneschi,

2011; Ben-Menachem and Marliss, 2004; Ben-

Menachem and Marliss, 2005).

Systems documentation is linked to the creation

of formal documents, with specific formats, geared

to the development and maintenance processes of

software systems. There is a discussion nowadays on

other options to record such data into documents,

such as the use of Wiki-based tools, as proposed by

Salvaneschi (2011). According to Salvaneschi

(2011) all the evolution documents whose goal is to

provide support to maintenance staff, are stored in a

Wiki-based tool.

One way to store information on systems is with

the construction of a system inventory that holds, in

a direct and concise way, their main technical and

management data. Ben-Menachem and Marliss

(2004) approach IT asset management, a process

that churns a massive volume of data and

information that has to be converted into data that is

meaningful for the organizations. Ben-Menachem

and Marliss (2004) also point at the importance of

the relationship between the assets for the control of

the organization. IT assets should include all the

system objects, or artifacts, such as specifications,

work plans, source code, and documentation.

Klint and Verhoef (2002) discuss the importance

of knowledge management to do business and

manage the hard and software infrastructures that

support the business processes. Klint and Verhoef

(2002) also investigate how the principles of

knowledge management can be applied, to allow the

continuous creation, consolidation, conservation,

and updating of the knowledge of the software assets

in the infrastructure. System inventorying is one of

the solutions put forward for the creation of

knowledge.

Systems inventorying starts with the extraction

of data from the source code, to produce a structured

and detailed list of the assets. Ben-Menachem and

Marliss (2005), present a methodology that allows

the optimization of software items as assets, based

on an enterprise software inventory, and the

streamlining of IT asset valuing, to allocate

development and evolution priorities.

3 ISO/IEC 15289:2015

The ISO/IEC 15289 (2015) standard – Systems and

Software Engineering – content of life-cycle

information items (documentation) is based on

ISO/IEC 12207(2008) and specifies the goal and

contents of the documentation for the entire lifecycle

of the systems, of the software, and of the

information items in service management.

According to ISO/IEC 15289 (2015) both a

project as an organization or service should keep the

relevant records on the information items required.

Such records hold structured data in a permanent

and legible way and can be generated from any

process in the life cycle, task or activity, including

data on requirements, policies, source code, orders,

issues, and historical data. These records should be

kept for record recovery, repositories or databases.

A number of record types is found, amongst

which the configuration register (record of assets,

record of changes) that are dealt with in this paper as

system inventory. From the context of this work we

can point at the configuration record (asset record,

Inventorying Systems: An Action Research

297

change record). With it, one can see the relevance

of system inventorying and the ways to organize it,

making it useful for a project or organization,

through the many moments of a system's life cycle.

4 MATERIALS AND METHODS

The goal of this paper was to identify the attributes

of the configuration items in legacy systems to build

a systems inventory, and from this experience

propose a process to update this inventory. A

strategy was devised and executed to inventory

legacy systems as set in the standards (ISO/IEC,

2008; 2015) and the processes for Systems

Configuration Management and Software

Documentation Management, as contained in

ISO/IEC 12207 (2008).

Having identified the attributes, we sought to

present the entire set to the stakeholders, as well as

evaluate the adequacy of each attribute.

The object of this study is a Brazilian public

organization, named here simply as Ministry. The

approach is qualitative and we used the action

research technique.

Action research is done by the research members

and by those involved in the problem, in a

participatory manner (Petersen, 2014). According to

(Petersen, 2014), the stages adopted in action

research included: Diagnosis, focused on the

description and understanding of the problem;

Action Planning, to identify alternatives on how to

solve the problem and eventually point the best

alternative; Action Taking, where the action planned

is then implemented; Reflection, where the results of

the action are gathered and studied.

The Diagnosis stage was carried out in meetings

and informal interviews with those involved, leading

to the definition of the problem: a lack of

documentation for the systems and the negative

effect on the maintenance activity of the systems.

The Action Planning and Action Taking stages

had interactive cycles with the research members

and the members of the organization involved. Three

cycles were needed to yield a stable instrument. The

process of data collection entailed document

research and interviews. The last step, Reflection,

included the evaluation and led to the instrument

being validated in the organization.

4.1 Characterization of the Ministry

The Ministry uses part of the Information

Technology Infrastructure Library (ITIL) to support

the management of their IT services. Development

demands and change requests (correction or

evolution aimed) are dealt with as services and have

to comply with the procedures for the management

of demands for services as placed by third parties,

both for systems development and maintenance.

The Ministry customized the Open-Source

Ticket Request System (OTRS) tool to manage IT

services, amongst which the management of systems

maintenance chores. They were going through a

period of supplier transition, with systems inventory

being an important element to produce an alternation

of suppliers that could take place with the least

impact possible on the provision of the services for

systems maintenance.

The Ministry has a coordination office, the

General Office for Information Technology (CGTI)

in charge of planning, conducting, and monitoring

the IT services in the body. It consists of a Projects

and Processes Division (DIPRO), a Systems

Development Division (DISIS), and a Division for

IT Services Infrastructure (INFRA). The Ministry

does not have a large number of employees, each

division being represented by only one head

employee and some analysts.

DISIS maintained a spreadsheet with a minimum

set of information items, based on a management

view of the systems under their control. Even that

the fields that were deemed as minimal by the

Ministry, many were empty or had outdated

information. On the other hand, systems analysts of

the suppliers had another set of spreadsheets and text

documents with no shared information. With the

supplier transition it was necessary to execute a

detailed survey of the data, rating and providing it to

the different stakeholders.

5 ACTION RESEARCH

5.1 Diagnosis

The Diagnosis stage had many meetings and

interviews with the analysts concerned, developers,

managers, and some users, apart from the analysis of

secondary sources such as documents and legacy

systems. This survey allowed us to forward to high

management a diagnosis report, showing the

precarious condition of the documentation of their

systems. The lack of some basic information was

unknown to the managers, such as that of libraries

and system development environments.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

298

5.2 Action Planning and Action Taking

Four cycles were defined for the next Action

Planning and Action Taking stages in action

research: Data Spreadsheet for the Ministry’s

Configuration Items; Wiki Tool; Adequacy of the

OTRS Tool; and Evaluation of the Inventory's

Attribute Usefulness. The first three cycles are

shown in Figure 1.

Figure 1: Planning of Inventory Process with the first three

cycles and the information sources.

5.2.1 Systems Data Spreadsheet

In Cycle 1 we planned collecting the maximum

information items from the existing systems and

recording the data on the Spreadsheet then in use in

the DISIS. For that, a survey was done of all the

Ministry’s systems, with the updating of all the data

then held for each system where many times the

only information found was that provided by the

analysts in charge (of the suppliers), apart from their

status, if active or idle.

Of the 54 legacy systems identified, 35 were

picked to have their data updated and recorded. All

the other systems were replicated or were inactive.

5.2.2 Wiki Tool

In Cycle 2, similar to the proposal of a Semantic

Wiki (Gonçalves et al., 2010), a collaborative

creation of knowledge took place, where a Wiki was

defined and refined with documentation items from

the different views and needs of the many parties

involved.

This solution was necessary to define which

system items would be registered, pursuant to the

needs of each of those involved, something that

demanded intense interactions between those in the

Ministry and the suppliers, as led by the researchers.

5.2.3 Customizing the OTRS Tool

From the coming to life of the Wiki contents by the

DISIS and the registration of the data, we considered

the guidelines set in standard (ISO/IEC, 2015) that

provide on the access to information and also

considered some needs of the Ministry, such as:

visibility of information; traceability amongst the

data assets; ease of inventory maintenance.

The OTRS is a Web based ticketing system used

in Customer Service, Help Desks, and IT Service

Management. The service tool was adopted by the

Ministry to manage IT services. With this, we

decided to replace the Wiki solution by the OTRS

one. With this, Cycle 3 got under way: customizing

the OTRS tool to concentrate the register for all the

systems' data and the remaining configuration items,

especially the databases and virtual machines, which

are directly related to the systems.

It was in such a scenario that the lines of this

new solution started to appear. Meetings were held

to refine and validate it. After an agreement had

been reached, the customization solution, with its

defined attributes, was placed in development by the

infrastructure team and after that it was

implemented.

5.2.4 Evaluation of the Inventory's Attribute

The attributes of the inventory were surveyed

according to the needs of the stakeholders with the

use of the standard (ISO/IEC, 2015) as a parameter.

Following the definition of the attributes of the

inventory and the customization of the tool we

started Cycle 4 where we managed to gauge the

actual usefulness of the attribute of each

configuration as registered in the Inventory.

This evaluation was necessary to verify the

adequacy of the information on the items as

registered in the Inventory and whether it had

contributed to the work of maintenance and IT

management in the Ministry.

5.3 Reflection

At the end of six months at work the Ministry

already had nearly 90% of their systems accounted

for as well as all the databases and blade servers also

registered. Apart from this, a set of minimum

configuration items was produced, adequate to the

needs of the Ministry.

In Cycle 1, related to the collection of systems'

data and other configuration items in a spreadsheet,

we found it rather difficult to keep this spreadsheet

Inventorying Systems: An Action Research

299

updated, given that editing the data was the

responsibility of just one person, due to the

limitations of the tool itself. However, using it was

necessary and allowed a quick survey of the

information in the systems and of the other

configuration items that are directly related to them,

such as the databases and the virtual machines.

The use of the Wiki tool in Cycle 2 proved more

adequate to the specific needs of the body and

received a greater number of adepts of its use. Due

to the possibility of a more harmonious structuring

of the data, it served as an object to identify the

items and of how it could be organized in the

inventory. However, the Wiki would be another data

storage technology, not associated to the services

management tool, not allowing different roles to

access it, and under the due control of the Ministry.

In Cycle 3 it was chosen to customize the

services management tool then in use, allowing the

inventorying work to continue and, later, the

management of traceability amongst the assets.

In many moments the absence and a high rate of

rotation amongst the civil servants of the Ministry

contributed to the dispersion of information and the

delay in data collection. Despite that, the creation of

the Inventory in an interactive manner allowed

responding to the demands voiced by the

stakeholders, the Ministry and the suppliers.

6 INVENTORYING

The collection of data for inventorying started with

the active systems of the body, that is, the systems

that were then in use and the databases then under

test, with the need after that, to also register the

remaining configuration items as well as the inactive

systems.

When the OTRS tool was customized, it was

necessary to transfer the collected data. With the

completion of the initial inventory, a need was

identified to also register the virtual machines (VMs)

with the OTRS tool. For that, a form was provided

with the VMs of three environments (production,

homologation, and testing) for each system active in

the body, which allowed registering the associations

between the systems and the VMs. This way it was

possible to identify the traceability amongst the

body's assets in the OTRS tool. The work lasted

some three weeks.

All the configuration items directly related to the

systems were inventoried and the work was revised,

with only the registration of indirectly related items

remaining, such as the blade servers and the frames.

The inventorying these last two items has been

postponed and will be done at a later stage by the

Ministry.

6.1 Attributes Identification

The attributes of each configuration items (systems,

databases, and virtual machines) were identified

after the proposal of Ben-Menachem and Marliss

(2004), based on the management and technical

perspectives. The needs of information of the

Ministry were taken into account, such as the

presence of physical and functional features, the

versions of the tools, etc. These attributes contain

the source and provision as contained in the standard

(ISO/IEC, 2015) for each one of them.

As for the systems, it is possible to identify items

on a management level such as the state of system

implementation, its business value, the

administrators in charge, what the documentation

repository is, and technical items such as the

language, the version of the system's language,

whether the architecture used is that named as

standard, and the Entity and Relationship Model

(MER).

The attributes identified for the databases (DBs)

totaled 15 attributes and contained especially

management data. The attributes surveyed for the

VMs, differently from the remainder, have a larger

volume of technical data such as, for example, the

machine's operating system and version, network,

and number of processor cores, amongst other

information necessary to guide the use of these

machines during the work of systems' maintenance

and development in the body.

6.2 Attributes Utility Evaluation

The set of attributes related to each configuration

item was submitted to the evaluation, which

consisted of a measure of the usefulness of each

attribute for each IT role in the body. The replies

could range from indispensable to dispensable. The

attributes rated as indispensable for any one of the

roles interviewed are named essential for the

inventory.

Due to the low number of Ministry employees,

the data was collected from the 5 professionals,

namely: head of the DIPRO, head of the DISIS,

DISIS analyst, INFRA analyst, and maintenance

members.

The data was gathered according to such

perspective in order to obtain data that could better

reflect the actual usefulness of such attributes, for

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

300

each professional of the body.

6.2.1 Attributes of the Systems

The set of attributes that was surveyed for systems is

the most voluminous set, with a total 27 attributes.

From this total, 17 are markedly management, 6 are

technical, and 4 include both perspectives. Figure 2

shows the number of points received by each

attribute, according to each professional interviewed

where 1 means the attribute is indispensable and 0

means it is dispensable.

Figure 2: System Attribute Scores.

The DIPRO head considers 11 attributes

indispensable for one's work routine in the body, all

of them related to the management angle; the other

16 were rated as dispensable, being resorted to only

in the event of an incident. The DISIS head

considers 22 attributes indispensable, amongst

which 15 from a management perspective, 3 from a

technical angle, and 4 with both. The 5 remaining

attributes were considered as dispensable, that is, not

used during one's work routine. It was possible to

evaluate that, in general terms, almost half of these

attributes, around 49%, are deemed as indispensable,

with only 12% as dispensable. The technical

attributes for Systems are indispensable for the

DISIS analysts and for the maintainers, while for the

infrastructure analysts these are dispensable for the

execution of their work.

6.2.2 Attributes for Database (DB)

The attributes surveyed for databases totaled 15, and

8 of them were of a management kind, 5 were

technical, and 2 had both perspectives. The score for

each attribute can be seen in Figure 3.

As regards the management perspective, it was

found that the DISIS head considers 7 of the 8

attributes as dispensable, using them only in the

event of an incident, for the purpose of an

investigation. Amongst the attributes related to a

management view, only 1 was rated as indispensable

by the DISIS head.

Figure 3: DB Attribute Scores.

The infrastructure analyst considers 6

management attributes as indispensable, and 2 are

not used by this professional. For the maintainer

there are 7 indispensable attributes and one that is

dispensable.

The technical attributes are widely used by the

infrastructure analysts and by the maintainers. They

had 5 and 4 attributes considered as indispensable,

respectively. The DISIS head, in one's turn,

considers only 1 technical attribute as indispensable

for one's work.

The attributes that are both of management and

technical kind are only 2 and are considered as

indispensable for both the infrastructure analysts as

Inventorying Systems: An Action Research

301

for the maintenance agents.

The DIPRO head and the DISIS analysts

considered all the attributes as dispensable as they

do not deal with the body's database.

6.2.3 Attributes for Virtual Machines (VMs)

Virtual Machines, as much as the databases, are

configuration items under the responsibility of the

infrastructure team. This way, the infrastructure

analysts are the one that use the attributes of this

item the most. In second place lie the maintainers

who make wide use of some attributes when

performing their work in the body's systems.

The total score each attribute had as

indispensable can be seen in Figure 4.

Figure 4: VM Attribute Scores.

As regards the management attributes, the

infrastructure analysts consider them all as

indispensable. The DISIS head, in one's turn,

frequently uses only 1 of the attributes, the other 7

being deemed as dispensable. All of the

management attributes are deemed as dispensable by

the maintenance agents.

The 8 technical attributes are indispensable for

the infrastructure analysts. The maintainers consider

only 4 of these attributes as indispensable. The

DISIS head, who has a management profile,

considers only 1 attribute as indispensable, with the

remaining 7 being used only in the event of an

incident, in an investigative task.

Only one attribute was rated both as management

and technical. The attribute was deemed as

indispensable for the DISIS head, for the maintainer

and for the infrastructure analyst, as seen in Figure

The DIPRO head and the DISIS analysts

considered all the attributes as dispensable as they

do not deal with the body's database.

7 ANALYSIS OF THE RESULTS

It was possible to identify and validate, with the use

of action research, a set of inventorying attributes for

the legacy systems, with the technical and

management needs as premises. The identification

was done based on the needs of the different

stakeholders. Attributes were identified for the

legacy systems, databases, and virtual machines.

With the evaluation of the attributes done in

Cycle 4, it was possible to observe some unused

items during the evaluation period, for example, the

State of Incident attribute, found in all

configuration items. For the DIPRO head, however,

this information will be used to monitor the

operating impact in the event of an incident, i.e., an

indispensable attribute that should remain in the

inventory.

Still along this line, there is the attribute that

should advise whether the item is a Security Asset.

This attribute was requested by the head of the

Division of Information Security of the Ministry for

the management of the security assets of the body,

being an indispensable attribute for that division.

When asking about the need of additional

information the DIPRO head requested a system's

attribute that would contain the URL for system

monitoring.

As regard the virtual machines, a management

need to link them to the databases was identified. All

remarks found will be assessed and forwarded to the

Ministry’s Services Management area.

In general terms, it is possible to observe that

most of the attributes is being used by at least one of

the stakeholders. The inventory reflects the needs of

the IT professionals of the Ministry, providing

support to both the systems' maintenance process

and for the work of IT management, as pointed by

Ben-Menachem and Marliss (2004; 2005), reaching

the technical and management goals.

8 CONCLUSIONS

The team of researchers was able to take part, advise

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

302

and execute inventorying strategies for a public body

that was going through a period of supplier

transition and relied strongly on the information on

the legacy systems as held by the suppliers that were

on their way out.

With the use of action research we found that the

main needs related to the creation of the inventory,

and the definition of which items it would contain,

according to the different needs of those involved

(from roles in the Ministry and those of the many

suppliers), and also to how store, access, and

maintain them.

With simple strategies such as the use of a Wiki

to register the data during the collection and after

that with the customization of a tool that was already

in use in the body, the inventorying of the legacy

systems took place. The redocumenting of the

legacy systems and the mapping of their inter-

relationships was done from the perspective of each

one of those involved, taking into account the

different roles of the Ministry and of the suppliers.

With this work it was possible to define a set of

inventorying attributes that would meet both the

management and the technical perspectives of the

body, as proposed in the works of Ben-Menachem

and Marliss (2004). With the evaluation of the

attributes for each configuration item in the

inventory it was possible to conclude that all the

attributes in use are essential for the inventory and

that they meet the needs of all the stakeholders,

whether holders of a management or technical view.

For the Ministry, what is sought is to periodically

evaluate and update, and keep the inventory always

in line with the needs of information on the

configuration items of the Ministry, avoiding the re-

establishing of a chaotic work scenario, as regards

management, the maintenance and the evolution of

legacy systems.

The process to identify inventorying attributes

for legacy systems, and databases, and virtual

machines, with the use of action research, and the set

of defined attributes can help other organizations in

the processes to inventory their legacy systems.

REFERENCES

Anquetil, N., de Oliveira, K. M., de Sousa, K. D., & Dias,

M. G. B., 2007. Software maintenance seen as a

knowledge management issue. Information and

Software Technology, 49 (5), 515–529.

Ben-Menachem, M., & Marliss, G. S., 2004. Inventorying

information technology systems: supporting the

paradigm of change. IEEE software, 21 (5), 34 – 43.

Ben-Menachem, M., & Marliss, G. S., 2005. IT Assets

Control by Importance and Exception: Supporting the

Paradigm of Change. IEEE Software, 22 (4), 94 – 102.

Brazil. 2012a. Informações Gerenciais de Contratações

Públicas de Bens e Serviços de Tecnologia da

Informação. Available in:

<http://www.comprasnet.gov.br/ajuda/Manuais/0401_

A_12_informativo%20comprasnet_ComprasTI.pdf>.

Brazil, 2012b. Inventário e Mapeamento de Ativos de

Informação nos Aspectos Relativos à Segurança da

Informação e Comunicações nos órgãos e entidades da

Administração Pública Federal. Presidência da

República, Casa Militar. Available in: <

http://dsic.planalto.gov.br/documentos/nc_10_ativos.p

df >.

Brazil, Ministério do Planejamento, Orçamento e Gestão,

2014. Secretaria de Logística e Tecnologia da

Informação. Instrução Normativa No. 04. de 11 de

setembro de 2014. Available in:

<https://www.cti.ufu.br/sites/cti.ufu.br/files/IN_SLTI_

04-12Set2014.pdf>.

Cozzetti, S., de Souza, B., Anquetil, N., & de Oliveira, K.

M., 2006. Which documentation for software

maintenance?. Journal of the Brazilian Computer

Society, 12(3), 31-44.

Gonçalves, J. J., Lima, F., & da Nóbrega, G. M., 2010.

Construção e manutenção de um Repositório de

Experiência Docente baseado em Wiki Semântico. In

Anais do Simpósio Brasileiro de Informática na

Educação.

ISO/IEC, 2008. International Standard ISO/IEC/12207.

Information technology – Software life cycle

processes,” International Organization for

Standardization/International Electro-Technical

Commission.

ISO/IEC, 2006. International Standard ISO/IEC/14764.

Software Engineering - Software Life Cycle Processes

- Maintenance. International Organization for

Standardization/International Electro-Technical

Commission.

ISO/IEC, 2015. International Standard ISO/IEC/15289.

Systems and software engineering – Content of life-

cycle information items (documentation) International

Organization for Standardization/International Electro-

Technical Commission.

Klint, P., & Verhoef, C., 2002. Enabling the creation of

knowledge about software assets. Data & Knowledge

Engineering, 41 (2-3), 141 – 158.

McMillan, C., Linares-Vasquez, M., Poshyvanyk, D., &

Grechanik, M., 2011. Categorizing software

applications for maintenance. in: 2011 IEEE 27th

IEEE International Conference on Software

Maintenance (ICSM), pp. 343-352.

Salvaneschi, P., 2011. The evolution of Information

Systems a case study on document management, in:

2011 IEEE 27th IEEE International Conference on

Software Maintenance (ICSM), pp. 428-437.

Petersen, K., Gencel, C., Asghari, N., Baca, D., & Betz,

S., 2014. Action research as a model for industry-

academia collaboration in the software engineering

context, in: 2014 ACM Proceedings of the 2014

international workshop on Long-term industrial

collaboration on software engineering, pp. 55-62.

Inventorying Systems: An Action Research

303