Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Kazuo Matsumura

dblp:80/6620 · DBLP profile ↗
← Back
4ranked-venue papers
2as first author
0since 2021 · last 1991
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 3 · 2 first-authorSystems, architecture and hardware · 1Applied, interdisciplinary, general and emerging computing · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
2 papers
Requirements engineering and software design · 54% Software maintenance and evolution · 46%

Topics — the 3 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Software maintenance and evolution
software reuse
0.011991
Software Reuse: is it delivering? · ICSE 1991
Requirements engineering and software design
requirements analysis
0.011987
An Application of Structural Modeling to Software Requirements Analysis and Design · IEEE Trans. Software Eng. 1987
Requirements engineering and software design › software modeling
structural modeling
0.011987
An Application of Structural Modeling to Software Requirements Analysis and Design · IEEE Trans. Software Eng. 1987

Methods — techniques the papers use, named apart from their topics

structural modeling · 0.0
YearPublicationVenuePosition
1991 Software Reuse: is it delivering?
William B. Frakes, Ted J. Biggerstaff, Rubén Prieto-Díaz, Kazuo Matsumura, Wilhelm Schäfer
ICSE4
1990 Modeling of software reusable component approach and its case study
abstract
A technique to reuse standardized software components is presented which features a component development process and component-oriented object layers together with validity demonstrated through applications. The approach is called the 'standardized components and their composition approach.' The technique, on the condition that the architecture of a product family is fixed for a certain period of time, has the following features: (1) development of software components and that of software products are performed independently, and (2) guidelines for software component analysis/design can be obtained using an object layer which is based on shared software resources (called objects). This software component development approach has been applied to three different cases: process monitoring and control software (mainly Fortran); distributed information processing system software (Cobol); and microcomputer embedded product control software (C and assembler). Excellent results have been obtained.>
Kazuo Matsumura, Akihiro Yamashiro, Ikumune Takahashi
COMPSAC1
1989 An Application of Structural Modeling and Automated Reasoning to Real-Time Systems Design
Shinichi Honiden, Naoshi Uchihira, Kazunori Matsumoto, Kazuo Matsumura, Masahiko Arai
Real Time Syst.4
1987 An Application of Structural Modeling to Software Requirements Analysis and Design
abstract
In software development, it has been pointed out that software engineers must pay attention to software requirements definition. One of the important problems in software engineering is to rationalize the processes from requirements definition to design. Computer tools are most useful and efficient for this purpose. This paper proposes a computer-aided software design system (CASDS), which supports software engineers with a series of structural modeling. As is well-known in systems planning, structural modeling helps to extract concepts from many fuzzy requirements. This system contains three structural modeling methods. They are used 1) to determine functional terms from fuzzy software requirements, 2) to obtain modules by structuring the functions with respect to the data flows, and 3) to make a program skeleton by imposing control flows on the functional elements obtained by breaking down the modules.
Kazuo Matsumura, Hiroyuki Mizutani, Masahiko Arai
IEEE Trans. Software Eng.1