Language architecture — obsolescence and deletions

Muxworthy, David

doi:10.1016/0920-5489(96)01006-9

Cited by 1 publication

(3 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The first article entitled "Language Architecture -Obsolescence and Deletions" [28], describes how a programming language develops (i.e. Fortran), and how some features become obsolete and unnecessary over the course of time.…”

Section: The Results Of the Systematic Literature Reviewmentioning

confidence: 99%

“…Finally, 25 articles were read thoroughly (step 3). Only three of these were identified to be partially relevant to OSRs and they are [26][27][28] …”

mentioning

confidence: 99%

“…The author decided that they are partially relevant to OSRs because the articles mention the notion of OSRs, or talk about it in general. Nonetheless, none of the articles is dedicated to OSRs.The first article entitled "Language Architecture -Obsolescence and Deletions" [28], describes how a programming language develops (i.e. Fortran), and how some features become obsolete and unnecessary over the course of time.…”

mentioning

confidence: 99%

See 2 more Smart Citations

Obsolete software requirements

Wnuk

Gorschek

Zahda³

2013

Information and Software Technology

View full text Add to dashboard Cite

Context. Requirements changes are unavoidable in any software project. Requirements change over time as software projects progress, and involved stakeholders (mainly customers) and developers gain better understanding of the final product. Additionally, time and budget constraints prevent implementing all candidate requirements and force project management to select a subset of requirements that are prioritized more important than the others so as to be implemented. As a result, some requirements become cancelled and deleted during the elicitation and specification phase while other requirements are considered not important during the prioritization phase. A common scenario in this situation is to leave the excluded requirements for being considered in the next release. The constant leaving of the excluded requirements for the next release may simply render them obsolete. Objectives. In this master thesis, a preliminary investigation is conducted to study the phenomenon of obsolete software requirements (OSRs). The major objectives of the thesis are:1. To find if OSRs exist in reality and how serious they are. 2. To define an OSR. 3. To propose processes to discover OSRs and to take possible actions against them when they are discovered. 4. To examine the effects of OSRs on project's type and size. 5. To insert/inject OSRs into the requirements engineering life-cycle. 6. To develop a classification for requirements that can help finding OSRs. 7. To find empirical evidence regarding OSRs in the industry about all the above mentioned objectives. Methods. A systematic literature review (SLR) is conducted to find relevant information about OSRs. The articles were retrieved from a number of sources including Compendex, Inspec, IEEE Xplore, and ACM Digital Library. Besides, a web-based questionnaire was distributed to experts from both of the industry and the academia in order to collect empirical information about OSRs. The data retrieved from the questionnaire was analyzed mainly using descriptive analysis and chi-square test of significance.Results. The phenomenon of OSRs exists in reality and is deemed serious by the questionnaire respondents. Moreover, the thesis suggests a definition for OSRs based on the results of the questionnaire. Another contribution is proposing several processes to find OSRs in the requirements' documents, as well as suggesting possible actions to be taken against them. Additionally, OSRs are found to have negative effects on software projects. These effects vary depending on the project's type and size. Conclusions. In conclusion, the phenomenon of OSRs does exist in reality, and is considered serious by the majority of the questionnaire respondents. The respondents also believe that OSRs have negative effects on software projects depending on the size of the projects (measured in number of requirements) and the type of the project (outsourced, market-driven, and bespoke projects). In addition to, this thesis presents the definition of OSRs based on the experience of the author a...

show abstract

Section: The Results Of the Systematic Literature Reviewmentioning

confidence: 99%

“…Finally, 25 articles were read thoroughly (step 3). Only three of these were identified to be partially relevant to OSRs and they are [26][27][28] …”

mentioning

confidence: 99%

mentioning

confidence: 99%

See 1 more Smart Citation