Publications

(This is not a complete list. The majority of my Russian publications are not presented).

S. Diev, A. Rubin. Ensembles: A method for activity description.
"Programmirovanie". Moscow, Russia, 1997, N 2, pp.27-38.
Distributed worldwide by Plenum/Consultant Bureau as "Programming and Computer Software". ISSN 0361-7688.

See Activity modeling.
S. Diev, A. Rubin. One approach to similar word matching.
"Programmirovanie". Moscow, Russia, 1994, N 6, pp. 61-70.

See Phonetics-based word search in databases.
S. Diev. A tool for knowledge-based front-ends for scientific applications. The Ph.D. Degree Dissertation (Computer Science). Keldysh Institute of Applied Mathematics, Russian State Academy of Sciences, Moscow, 1986, 112 pp.
L. Bass, S. Diev, A. Dubinin, V. Levchenko, A. Pyshko, L. Uhov. Basic principles of a dialog system for numerical evaluation of nuclear power plants' protection system.
"5th Russian Conf. on Protection against Radiation of Nuclear Power Plants", Serpukhov, USSR, 1989, 4 pp.
L. Bass, S. Diev, et al. RADUGA-4.0 - Two-dimensional transport code.
"Advances in Mathematics, Computations, and Reactor Physics. Int. Topical Meeting, 1991, April 28 - May 2, Green Tree Marriott Pittsburgh, PA USA". University of Pittsburgh, USA, April 1991. vol.5, 4 pp.
S. Diev, A. Rubin. Ensembles of hyperelements: A notion base for activity representation.
Keldysh Institute of Applied Mathematics, Russian State Academy of Sciences, 1996, Preprint N 61, 22 pp.
Sergey Diev. Software estimation in the maintenance context.
ACM SIGSOFT Software Engineering Notes. 2006, Vol. 31, Issue 2 (March), 8pp.

This article describes an extension of the Use Case Points method of software estimation. The main goal of this extension, called UCPm, is to reflect the specifics of the maintenance phase of software life cycle. UCPm takes into consideration the complexity of the base system. Then, UCPm does not consider the environmental factor as size-contributing entity and defines product size only via unadjusted use case points and technical factor. UCPm also applies four technical factors at the use case level, rather than at the level of the overall product.

The method has been applied to more than 100 projects in the course of work on achieving CMM/CMMI Level 4. It was found that even when requirements are not produced in the use case style, it is relatively easy to build a use case model for the purpose of estimation. It is also believed that the relatively high level of UCP/UCPm reduces the amount of work on estimation. In our preliminary estimates, one use case point maps to approximately four function points.
Sergey Diev. Use cases modeling and software estimation: Applying Use Case Points
ACM SIGSOFT Software Engineering Notes. 2006, Vol. 31, Issue 6 (November), 4pp.

This article discusses software size/effort estimation by the Use Case Points method (UCP). It is based on the experience accumulated during deployment of the UCP in a software development department of a major financial institution. Typical for such an environment is that software is developed on top of existing ap-plications, and that there are significant differences between pro-jects in business domains, scope, size, complexity, project management details, etc. In a previous article [3] an extension of the Use Case Points method, called UCPm, was described that addresses these issues.

Due to their level, use cases make high-level estimation easier. However, this article, presenting a number of real world situa-tions, demonstrates that to obtain reasonably accurate estimates we need to reflect in use case models some aspects of the existing application and of the current project. It also suggests some clari-fications of the concept of use case transaction and outlines some ways to support use case models consistency within and across projects.
Sergey Diev. Requirements development as a modeling activity.
ACM SIGSOFT Software Engineering Notes. 2007, Vol. 32, Issue 2 (March), 3pp.

Considering requirements development as a modeling activity, this paper outlines our view of what a requirements model is. It then introduces some techniques useful in requirements development: concept-based requirements and requirements molecules.
Sergey Diev. Structuring complex requirements.
ACM SIGSOFT Software Engineering Notes. 2007, Vol. 32, Issue 2 (March), 5pp.

Sets of requirements that analysts are dealing with are often big and complex. That makes requirements structuring one of the most important activities in requirements engineering, because of how requirements are structured and presented directly impacts the requirements development process and the quality of requirements. In this methodological paper we argue that a requirements analyst has to build a requirements architecture that fits the properties of the problem. In particular, the requirements analyst should create a clear vision of the principles governing how requirements are being defined, built and presented. We review some of the instruments that an analyst can use to structure requirements: requirements sets, views, levels and links. Among static views we emphasize concepts view, and also consider functions view, application architecture view, and other views; among dynamic views we consider use cases view, operational scenarios view, events view, and others. We specifically notice the importance of individual requirements sets, the purpose of which is to reveal the requirements for a particular element (concept, function, action, etc.). We argue in favor of differentiating between requirements model and requirements representation. We demonstrate on examples how requirements architecture is needed in complex contexts.
Sergey Diev. Querying complex requirements.
ACM SIGSOFT Software Engineering Notes. 2009, Vol. 34, Issue 1 (January), 7pp.

For large and complex projects the structure of requirements becomes a factor of utmost importance. This paper suggests a small set of primitive constructs that allow requirements to be expressed and structured in various views. Among ways to increase the quality of requirements this paper considers (i) the network metaphor and (ii) conceptual modeling, which includes requirements crystallization activity. Then query types that follow the suggested meta-model are introduced and discussed. These queries operate at several levels: text, element, diagram, and model. This paper has a methodological flavor at two levels: First, it suggests a specific way of developing requirements; second, it aims to demonstrate the relationship between the meta-model we choose and the set of query types we build for it. A visual editor VR (Visual Requirements) has been developed to support the approach and queries described here. Among other applications, VR has been used in the maintenance context to estimate, on the base of use cases models, the size of more than a hundred of software initiatives, including multi-million-dollar projects.