TOWARDS E-GOVERNMENT SERVICES IN RUSSIA
Dmitrij Koznov
Software Engineering Department, Saint Petersburg State University, Universitetskji pr. 28, Saint Petersburg, Russia
Alexander Samochadin
Cybernetics Faculty, Saint Petersburg State Politecnical University, Politechnicheskay str. 29, Saint Petersburg, Russia
Alexey Azarskov
Committee on Informatization and Communication, St. Petersburg Government, Smolnay sqv. 2, St. Petersburg, Russia
Julia Chevzova
Software Engineering Department, Saint Petersburg State University, Universitetskji pr. 28, Saint Petersburg, Russia
Keywords: e-Government services, Business process modeling, Feature diagrams, Russia.
Abstract: Transition to e-government services is a worldwide tendency. However, each country possesses its own
specifics, which need to be taken into account. The given study is dedicated to transition towards e-
government services in Russia. A method for formal specification of Russian government services is
presented. This method can be used for e-government services optimizing, restructuring and checking,
design of e-access software, and semi-automatic producing services’ Web-content. We have adapted
OntoGov approach to specify domain ontology. Basing on the mentioned ontology separate services have
to be described: process model (customized BPMN notation), document model (based on Feature Diagrams)
and description model. An example of a Web-content generation under formal specifications is presented.
Pilot method deployment for specification of Russian government services, which required Russian and
Finnish citizen to communicate with each other, is described.
1 INTRODUCTION
Conversion of government services into e-services
allows increasing significantly efficiency of services
for citizens: the need to visits numerous institutions
is eliminated, the desired service is available from
home, online. Actively being developed both general
e-government services concepts (Shareef, 2011),
(Ajeeli, 2010), (Mitrakas, 2007) and multiple
research on adaption of such concepts in countries of
Europe (Hogrebe, 2009), Chile (Smith, 2001),
Tanzania (Kaaya, 2009), etc.
One of the main problems at transition to e-
government services in Russia lies in complexity
laws and regulations describing these services. The
given domain is objectively complicated: in Russia
there are many government services, they contain a
lot of “branches”, and for services obtainment a
large number of documents is required (the list
varies depending on applicant’s personal situation).
Government authorities specifying legal documents
for government services are synchronized
insufficiently. These documents contain a lot of
contradictions, identical concepts are named
differently. It frequently occurs that there are
different ways for service obtainment as government
institutions’ functions are often replicated.
Ultimately, apart from common citizens, the officers
themselves are not able to indicate precisely, which
steps are to be taken in various situations on order to
obtain a specific service. Moreover, at realization of
a single service a number of institutions may be
involved, consequently, each organization has its
own subprocedures. At last, presently the Russian
community lacks a unified classification of
government services: in various regions the same
294
Koznov D., Samochadin A., Azarskov A. and Chevzova J..
TOWARDS E-GOVERNMENT SERVICES IN RUSSIA.
DOI: 10.5220/0003627502940301
In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2011), pages 294-301
ISBN: 978-989-8425-81-2
Copyright
c
 2011 SCITEPRESS (Science and Technology Publications, Lda.)

1
http://sites.google.com/site/improvingsocialservices/home
procedure is listed under different names, and
diverse services contain same functionality.
Therefore, conversion to e-government services
in Russia demands a significant optimization and
ranging of the existing public services. One way to
reach the goal is creation of existing services formal
description, however, stricter than legal documents.
Such descriptions would have been a support at
inspections and optimizations of government
services, eliminations of contradictions and
replications in their specifications, and also be a
simplification of their maintenance and update. The
above is especially urgent in connection with annual
creation of hundreds of new services, and the
existing ones are being altered actively. Besides,
formal descriptions may be used at semi-automatic
Web-content development. This Web-content should
describe government services for citizens. In Russia
there is a problem of citizens’ lacking information
both on the spectrum of services available, and detail
of their realization. This leads to wasting a lot of
time at services obtainment. Amount of Web-
resources outlaying government services
information in the Russia is still limited.
In the given paper we are focusing on creation of
tools allowing describing Russian government
services. The study concentrates on an overview of
the present state of affairs in the Russia in the field
of government services, and formulates the
occurring difficulties. A method of formal
specification of Russian government services is
presented. The method implies choosing domain
(country, state, municipality, etc.), creation ontology
for domain selected in order to fix all the main
concepts. For that purpose we adapted OntoGov
approach (Tambouris, 2004). Basing on the
mentioned ontology separate services have to be
described. At that it is proposed to employ a
customized BPMN notation (BPMN, 2009) (process
model), extended with document and description
models. Document model is described by the means
of modified Feature Diagrams (Kang, 1990); for the
description model we proposed to use XML. An
example Web-content generation under formal
specifications is presented. Finally, a pilot method
deployment, at the Finnish-Russian cross-border
communication project «Improving social
services»
1
, for specification of Russian government
services, which required Russian and Finnish citizen
to communicate with each other, is described.
2 BACKGROUND
2.1 OntoGov Project
The given project is aimed for enhancement of e-
government services life cycle: creation of formal e-
government services description tools, maintenance
and update mechanisms as well (carrying out
changes starting with laws and regulations up to
corresponding software). Particularly, in the
framework of the project Meta Ontology approach is
employed, that is creation of a set of interrelated
ontologies in order to describe various aspects of e-
government services. This set of ontologies includes:
 Profile Ontology includes a service name,
short description, version, status, date of
creation, creator, etc.
 Process Ontology models describes process
flow and data flow
 Life-Event Ontology contains classification of
e-government services
 Domain Ontology describes “terminology”
used in the e-government domain
 Organizational Ontology describes roles and
areas of responsibility, capabilities within an
organization providing the service
 Lifecycle Ontology describes a decision-
making process at public administration to
support the transition from knowledge
acquisition to implementation
 Legal Ontology models the structure of legal
documents, which include paragraphs,
sections, amendments, etc.
 Legal-Federal Ontology is based on Legal
ontology and contains entities, representing
laws that are held at federal level
 Legal-State Ontology is a specification of
Legal-Federal extended with the information
related to federal state laws
 Legal-Municipal ontology extends the Legal-
State ontology with some regulations of
municipality
2.2 BPMN
At present, there are many approaches to business
processes formal description (for example, see
review (Ruopeng, 2007)). Among them, BPMN
stands out as, perhaps, the most mature formal
notation. An advantage of the BPMN is rich
graphical notation and presence of strictly
executable design semantics.
The basic constructions of the BPMN are listed
below:
TOWARDS E-GOVERNMENT SERVICES IN RUSSIA
295

1. Flows objects, which may be of the following
types: activity, gateway, and event
2. Connecting objects, which combine different
actions and data in a unified execution flow;
relations may be of following types:
sequence flow (transition from one activity to
another), message flow (message exchange
between the involved participants), and
association (aimed to define transitions
between activities, at exemption occurrence,
for instance)
3. Process swimlanes, which may be: pools
(external process environment, for example,
other various organizations involved in the
process), lanes (internal participants, such as
functional departments of organizations
involved in the process), artifacts (data
object, annotations, etc.)
2.3 Feature Diagrams
Feature diagram is a set of features and their
hierarchical relationships with clearly distinguished
hierarchy root, which is called “concept”. Feature is
a detached system property, recognized from user’s
or developer’s standpoints. Hierarchical relations
reflect the decomposition concept and/or
opportunities (and are the inclusion relations).
Options for inclusions are of two types: mandatory
and optional. There are also special properties for
group relations, emerging from one vertex: (1) any
subset of features selected, which is led by lines
having fell in this sector (black sector); (2) choice of
a single opportunity (blank sector, outlined in the
bottom). Feature diagram example is presented in
Fig. 1.
Figure 1: An example of feature diagram.
This figure proves that Feature 1 and Feature 2
can be included into the system in any combination;
Feature 3 and Feature 4 may be included, and may
not be; Feature 5 is always included when there is
Feature 1; Feature6 and Feature 7 are a part of the
system alternatively.
These diagrams have been proposed in the
context of software product lines (Frank, 2010).
Their main purpose is visual formalization of system
divergent properties. At employment, feature
diagrams must be resolved. For example, in case of
product lines, this means that at specification of a
certain system various features are selected
explicitly.
3 GOVERNMENT SERVICES IN
RUSSIA
Services provision for population is one of
government/state/municipal authorities’ major
functions. Services system development supposes
enhancement of interaction with citizens and
organizations, increase of state and local authorities’
activities efficiency, citizens and organizations
accessibility to the information on course of
execution of a government (municipal) service at
each level, control over its progress.
Government services in the Russian Federation
are provided basing on distinct regulations, created
by the conforming governmental authorities, and
contain a detailed description of service supply
processes. Presently the consolidated government
service register of the Russian Federation contains
information on 575 federal services, and over 8,5
thousands of state and municipal (Federal document,
2008).
In 2005 the Russian government has approved an
administrative reform concept (Nabibulina, 2010).
One of the tasks of that reform was creating of legal
and institutional mechanisms for development and
maintenance of government services portals,
providing free access to information about services
on-line.
Summarizing the administrative reform activities
of 2006-2010 the main remaining problems,
demanding urgent solution, were allocated as
follows (Nabibulina, 2010):
 Optimization of services classification,
elimination of redundancy and duplication,
commitment of lists in conforming registers
 Services regulation and standardization,
reengineering of the service provision scheme
itself
 Transfer to e-service upon a "one window"
principle
Additional difficulties of government services
KMIS 2011 - International Conference on Knowledge Management and Information Sharing
296

2
www.daml.org/services/owl-s/
in the Russia are the following:
 Present lack of a unified (which includes all
services) system of terms and definitions,
which would have served as a base for laws
and regulations, specifying government
services
 A large volume of services descriptions (laws
and regulations) hindering citizens’
comprehension of the latter
Complexness of legal information, on one hand,
leads to Russian Federation citizens’ ignorance in
the field of existence and execution of various
services. On the other hand, the providing of
services per se (in most cases there are no e-access!)
many unnecessary delays occur, quality of service
suffers. Both citizens and officials have difficulties
planning and estimating execution of one or another
service in a specific case, therefore, the only way to
discover the amount of time and efforts to be
consumed – is to follow the entire way directly.
4 METHOD
The proposed method is aimed for creation of formal
government services specifications in the frames of a
certain domain, basing on domain ontology and a
range of models.
The Russia government services have a large
branch structure aiming to cover various categories
of citizens. At applying, for instance, for a child’s
international passport the latter may both come with
a parent or with a person having a designated parent
entity. Parent’s last name may be the same as the
child’s, and may not. In all these cases a various
documentation package is needed in order to obtain
a child’s international passport. Complexity of
services description is precisely specification of
these cases and subcases. Exactly in such rare
branches mistakes lie. Therefore, a formal method
for public services description should be designed
for specification of these “branches”. For diverse
government services applicants the following may
differ:
 Steps order and quantity
 A list of documents submitted; it often appears
that a course of action is common for different
applicant groups, and only the documents to
be submitted differ
 Service rendering run-time; timeframes
depend on the amount of steps required for
completion by different categories of
applicants in order to receive the service, on
time period for processing of various input
document packages by the authorities, etc.
 Service price – e.g. depends on services run-
time
The method scheme of is shown in Fig. 2. It
should be noted that specifications, which created by
the means of the proposed method are not intended
for services’ users. Numerous studies show that
model-based visual specifications are difficult for
comprehension by the untrained people.
Government services targeted descriptions should be
produced on the base of these models in semi-
automatic mode, with employment of special
metaphors, denoted in Fig. 1 as WCMs (Web-
Content Metaphors).

Figure 2: Method scheme.
Below proposed kinds of models are descried in
more detail.
4.1 Domain Ontology
Our approach is based on the establishment of the
Domain ontology for the selected domain. The latter
shall contain a thorough specification of domain
general terms, which are to be used at modeling of
services as well as at preparation of regulations.
We have adapted OWL-S
2
for our needs.
Without going into the syntactic details, we shall list
the basic concepts. We have extended OWL-S with
characterizing typical domains of government
services in Russia (see Fig. 3): (1) a list of executive
bodies and organizations involved in service
providing, (2) recipients and applicants of a service,
(3) laws and regulations, defining this domain; (4)
documents used in services of the domain (5) results
of service rendering, (6) grounds for service
rejection, (7) various descriptions and concepts –
e.g., for housing and communal services there are
TOWARDS E-GOVERNMENT SERVICES IN RUSSIA
297

types of housing, benefits and preferential categories
of citizens, etc.
Authtorities
Receivers
Applicants
Documents
Terms
Legaldocuments
Results
Reasons
forrejection
Domain
ontology
Figure 3: Domain Ontology.
Inlike OntoGov, we chose not to employ a Meta
ontology approach, as we are oriented at smaller
domains so far, for example, committee of regional
government (for instance, housing committee). In
the meantime, for instance, Saint-Petersburg
government committees are actively creating
numerous regulations; so according to our
preliminary experiments for the housing committee,
our proposed approach fits well to their data
domains. However, unconditionally, if the domain
turns out to be noteworthy – for instance, all Saint
Petersburg government services – a more complex
ontology is necessary. It would seem, in this case,
we minimize costs and efforts for specification
development getting an opportunity for reuse. But
on the other hand, number of concepts grows and
there is a problem of additional structuring.
Furthermore, using of the approach in that context
requires more institutional support, which is not easy
to provide, and so far we don’t have any experience
in the field.
Another distinction from OWL-S/OntoGov is
that information on government services we have
partially removed from the ontology into the models:
process and document models.
4.2 Process Model
For each service we propose to create its description,
defining user’s steps, which he/she is to follow in
order to receive the given service, and also
authorities’ steps. Besides, a specific service process
model is oriented a certain way in order to receive
the service, as it is supposed to describe particular
(and not abstract) steps. In the Russia for same
services there are often several ways of receipt. For
example, one can act independently, obtaining all
the necessary documentation and turning to all of the
correlating institutions. However, now in Russia
increases establishment of unified centers
undertaking cooperation with separate government
services and providing numerous services. As an
example of such centers is a Unified Documents
Center (UDC) in Saint Petersburg, which delivers
various services: passports issuance/exchange, car
registration at the purchase, international passports
issuance, etc. As an example, we shall consider a
procedure of international passport obtainment at the
UDC. A simplified model of documents delivery
process for an international passport in the UDC is
presented in Fig. 4.
Arrival to
the UDC
Procedure
consultation
receipt
InfoBlock:
UDC.Gen_Info;
UDC.Contacts;
UDC.How_to_Get;
UDC.Working_Hours;
Risks.Doc_Preparation
DocBlock:
Input_Documents
Takean e-ticketand
wait forone’sturn
Consultation
ondocuments
Receive
formsfrom
theoperator
Paymentofservicefees;
Paymentofstatefees;
Takeaphotograph
Takean e-
ticketand
wait forturn
GotoUFMS
InfoBlock:
UFMS.Working_Hours;
Risks.UFMS_Submitting_Doc
UFMS:documents
receiptand
inspection
InfoBlocs:
Risks.Passport_obtainment
[Ok]
[Documents
are wrong]
[Documents
are wrong]
DocBlock:
UFMS_output1
[Ok]
Figure 4: A process model example.
The user is needed to bring all the required
documents, arrive to the UDC, and receive a
consultation regarding the international passport
obtainment procedure, which he/she accomplishes
after that: take an e-ticket; wait for a turn to
approach an appropriate operator’s window to check
the documents. If the documents are not in order,
then the user leaves the UDC. He/she is required to
obtain/update all the necessary documents and return
again. In case all the documents are correct, he/she
collects a receipt for state fees and services payment
from the operator, makes the payment, and takes
photographs as well. Having completed these steps
he/she moves to the next room, where a UFMS
branch office is located (state agency for registration
of international passports, while the UDC is a
private commercial organization) and submits the
KMIS 2011 - International Conference on Knowledge Management and Information Sharing
298

documents.
This procedure contains a large amount of
additional information, which the user should know
beforehand in order to accomplish it successfully. In
the first place, this is an accurate list of documents to
be submitted for international passport obtainment.
Secondly, it is information about the UDC: general,
contacts, route, working hours, etc. In the third
place, possible risks should be described. In this
case, the user risks to fail submition of documents
set in one visit (the documents brought are
incomplete, or he/she simply arrived too late).
BPMN has data object construction that can be
used for documents specification and assigning to
the process activities. For additional information
BPMN annotations may be used. However, in our
case both documents and additional information turn
out to be voluminous and elaborately arranged.
Therefore, we propose additional modeling tools for
their specification. Thus, to the process model we
introduce additional structures denoting references
to fragments of document model (DocBloсk) or
description model fragments (InfoBloсk).
In addition, we append the ability to place
several similar actions into a BPMN-activity. In Fig.
4 the fourth object is such an activity, which
includes fees payment to the UCD and state fees,
production of photographs.
At creation of a process models it is important
not to overload it with basic information, which user
can easily receive at the spot. For instance, there is
no need to define such activities as «Go to the
operator’s window», «Attach a photo to the
application», etc. On the other hand, there is also no
need to achieve complete algorithmic accuracy of
the process model. For example, after mistakes in
the application package were discovered at
«Consultation on documents» activity execution and
after having exited it (in our case this is performed
with deletion), the user is still able to cover the UDC
services, pay state fees, and take photographs,
however, this option is not present in the current
model. Such accuracy complicates the specification
greatly, but does not make it more informative for
the user.
4.3 Document Model
Depending on individual features (special attributes’
values) the user should provide various
documentation packages in order to obtain the same
service. To define all possible options we propose a
document model, based on Feature Diagrams. It
represents a forest of trees. Presenting attributes’
values, a user receives a selection out of many and
obtains a documents package suitable for one’s
situation.
Fig. 5 shows a fragment of such model for the
process model introduced in Fig. 4. We consider an
«Input_Documents» tree (as follows from Fig. 3,
there is one more tree – «UFMS_output1») that is
presented in Fig. 5. This only a fragment of real
model: for example, the situation of citizens whose
age is below 18 is not considered.
Each tree in a document model contains:
 A root (darker oval at the diagram)
 Intermediate vertices (lighter ovals)
correspond to values of users’ attributes, for
example, «Age over 18» or «Age below 18»;
attributes are depicted in square brackets (for
example, «Age» and «Military service
relation») and connected to groups, which
would be defined below
 Terminal vertices – documents (document
name and underlined with a thick line)
Documents can be attached to any intermediate
vertex, as well as to the root of the tree. If the
documents are connected with a vertex that has a
subtree of situations, it indicates that all the
documents are necessary for the situations located in
the its subtree. For instance, in Fig. 5 attached to the
root is a list of documents – and these documents are
mandatory for all citizens wishing to obtain an
international passport. Depending of applicant’s
specification this list may be extended with other
documents in accordance with the
«Input_Documents» tree.
Intermediate vertices, having a common parent,
gather into groups, marked with attributes. Within a
group vertices are alternative: i.e. must be chosen
only one of them (simple group) or, as in the
«Military service relation» group – one or neither
(this kind of group is marked by double circular
segment of a circle that encompasses all the lines
leading from the node to the group). A vertex would
have more than one group, for example,
«Input_Document» has two groups, which are
marked with attributes «Kind of passport» and
«Age».
If we have selected any value of the attribute and
fallen into a certain vertex, then all the groups of this
vertex are necessary. That is, for example, for the
«Over 18» vertex it would be also important is the
person works, and his relation with military services.
Finally, documents may be marked with a circle,
which means that they are advisable, however, not
mandatory. InfoBloсks, providing additional
information about the situation/document, may be
TOWARDS E-GOVERNMENT SERVICES IN RUSSIA
299

connected with tree nodes.

Figure 5: A document model example.
4.4 Description Model
This model is designed to structure diverse useful
information, which the service user may need. We
suggest packing this information in separate
thematic blocks (InfoBlocks). InfoBlock is an XML-
text. Here's an example.
<service name = “International
passport_registration “>
<InfoBlock name = “Center”>
<section name = “General_Information”>
Saint Petersburg Unified Documents Center is
designed to accelerate registration of various
documents – international passport, vehicle
registration, vehicle purchase agreement,
driver's license registration and exchange,
etc. For more information visit Center’s
website http://www.7771000.ru/
</section>
<section name = “General_Information”>
Address: Krasny Tekstilshik St. 10-12
191124 Saint Petersburg
Tel: [phone]
Web: http://www.7771000.ru
</section>
…………
</InfoBlock>
………
</service >
Process and document models may refer not only
to entire InfoBlock but also to its sections, as shown
in Fig. 4 and 5: for example, in Fig. 4, at the
«Arrival to the Center» activity there is a link to
various sections of the «Center» InfoBlock.
4.5 Transition
Formal specifications of government services can be
used for automatic generation of Web-description
for these services, making such knowledge explicit
and understandable. Various metaphors and
approaches are to be used in order to make
information accessible for the different kinds of
users.
As an example let’s view how we can
automatically generate windows forms to specify the
exact document package to submit. These forms can
suggest the user some questions with predefined
answers. Basing on these answers the final
document list will be formed. All information for
these forms can be provided by a document model.
Each group of forms corresponds to one document
tree. Questions are names of groups (attributes),
answers are names of situation of these groups
(attributes’ values). Documents, which the user has
selected, are attached to the vertices attending user
answering the questions. An example one of the
forms that correspond to the document tree from Fig.
5 is presented on Fig. 6.
Figure 6: An example of generated dialog window.
5 CASE STUDIES
We have applied the method presented for
specification of government services in Finnish-
Russian project «Improving social services» in
cooperation with Saint Petersburg government. The
overall objective of the project is to contribute to
social development of St. Petersburg (Russia),
Imatra and Lappeenranta (Finland) regions through
improving access to on-line social services for
Finnish and Russian citizens by developing and
testing of a new customer friendly Web-based
approach.
Up to now we have created specifications for
KMIS 2011 - International Conference on Knowledge Management and Information Sharing
300

five Russian government services: international
passport obtainment, foreign citizen registration,
foreign citizen work permit obtainment, car accident
analysis, obtainment/renewal of Russian visas for
foreign citizens. Generally, the process model
occupied one or two A4-format sheets, document
model (one А4-sheet), description model (5-10
pages). A relatively small amount of specifications
contrasts with intricacies of official regulations. The
created specifications were inspected by the Saint
Petersburg authorities’ specialists and corrected
under their remarks. Basing on the models we have
also created several pilot Web-sites in order to
present model information with an interface
convenient for end users.
We have also noticed that not all the information
concerning government services, the users require, is
possible to formalize in models. In the future, we’ll
intend integrate Web-descriptions of government
services with Internet forums, where people would
be able to share their experience of relevant services
obtainment.
6 CONCLUSIONS
The paper discusses some preliminary steps, which
can be done for transition to e-government services
in Russia because it is not possible to create IT
services basing on incomplete and contradicting
information. One of the ways to solve this problem
is to use formal specification method. We have
presented such method that takes into account
Russian specifics, and the main one is an urgent
need for a uniform formal description of government
services. We believe that even within small domains
(for example, Saint-Petersburg house committee),
this activity may be beneficial, especially since
implementation of such methods is often held step-
by-step. However, we also believe that the described
method can be applied outside of Russia as well,
since difficulties organizing government services
and provision of additional informational resources
for usual people are, on different scale, characteristic
for each country.
Directions for future the method development are
as follows.
1. Method employment for specification of
voluminous and complex public services (yet
it had been employed for relatively small
ones).
2. Model expanding with timing and pricing, in
order to execute various users’ requests
basing on that data.
3. Search for effective Web-metaphors for end
user Web-content generation under the
models.
4. Basing on a certain standard CMS-system,
development of a site builder, allowing in a
semi-automatic mode construct Web-sites
with services description from standard
blocks, grounded on models.
5. Solving problem of Web-content
maintenance and update.
6. Using the method for design and
development of e-services.
REFERENCES
Shareef M., Archer N., Dutta S. 2011, E-Government Ser-
vice Maturity and Development: Cultural,
Organizational and Technological Perspectives,
Information Science Pub.
Ajeeli A., Abid Ajeeli T., and Al-Bastaki Y. 2010,
Handbook of Research on E-Services in the Public
Sector: E-Government Strategies and Advancements.
Mitrakas A., Hengeveld P., Polemi D., Gamper J. 2007,
Secure E-Government Web Services.
Hogrebe F., Blinn N., Nüttgens M. 2009. Survey of E-
Government Portals in European Capitals and Large
Cities: A Benchmarking Study of G2B-Services. In
EGOV 2009.
Smith M. 2011. Limitations to building institutional
trustworthiness through e-government: a comparative
study of two e-services in Chile. In JIT 26(1).
Kaaya J. 2009. Determining Types of Services and Targe-
ted Users of Emerging E-Government Strategies: The
Case of Tanzania. In. IJEGR 5(2):16-36.
Tambouris E., Gorilas S., Kavadias G., et.al. 2004.
Ontology-Enabled E-gov Service Configuration: An
Overview of the OntoGov Project. In. KMGov.
BPMN. 2009, Business Process Model and Notation
(BPMN). Version 1.2. OMG formal/2009-01-03.
http://www.omg.org/spec/BPMN/1.2
Kang K., Cohen S., Hess J., Novak J., et al. 1990. Feature-
Oriented Domain Analysis (FODA) Feasibility Study.
Technical Report, CMU/SEI–90-TR-21, Software
Engineering Institute, Carnegie Mellon University,
Pittsburgh.
Ruopeng L., Sadiq S. 2007. A Survey of Comparative
Business Process Modeling Approaches. In. BIS.
Frank J. van der Linden, Klaus Schmid and Eelco
Rommes. 2010, Software Product Lines in Action:
The Best Industrial Practice in Product Line
Engineering. Springer.
Nabibulina E. 2010. Results of administration reform
2006-2010. (In Russian).
Federal document. 2008. The concept of administration
reform in Russia 2006-2010. 09.02.2008 N 157-р. (In
Russian).
TOWARDS E-GOVERNMENT SERVICES IN RUSSIA
301