English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Tools annual

Global: Zendy Free Plan

Global: Zendy Tools monthly

Global: Zendy Plus monthly

A recent paper in SICPLAN Notices C1] criticizes the Halstea d Software Science approach to estimating program size and refers t o other papers in the same genre. This reply concerns several matter s that appear to have been overlooked by these authors : For one thing, if the Halstead length estimator is to b e considered robust, then it should exhibit additivity. I. e ., fo r a large program, the sum of the estimates for the function and sub-routine sizes should be compared to the overall size estimate an d naturally the measured sizes. In addition, to be fair to Maur y Halstead, any paper on the subject should certify that a conscientiou s effort had been made to ascertain the presence of, and remove, an y software " impurities". For software containing programmin g "impurities" (see Chapter 7 in E2] for the definition o f "impurities"), Halstead never guaranteed correct estimates. A similar problem occurs when software effort and projecte d error reports are estimated. It is very easy to make the mistake o f looking at a software project with a large proportion of re-used an d extremely reliable code, and simply applying the estimators to th e project without first deducting for the code that has already bee n developed and debugged. Common sense indicates that, in such cases , the contribution to overall project effort and software proble m reports by re-used code is a "second-order effect", and should onl y be included in the estimate as the effort to code a program whos e pieces are the modules of the developed system. It was my privilege to occupy the office next door to Mauric e Halstead at Purdue University for seven years. During that time, I watched his software science system develop on his blackboard and engaged in vigorous debates with him on the meaning of his system. W e were not in agreement on some matters, especially the additivit y property of his estimators, but my subsequent experience in industr y as a software development contract monitor confirmed to me th e validity of, e. g ., the length equation. On one occasion, I spen t several days going over software developed by a major contractor, estimating subroutine size on my pocket calculator, and finding ver y good agreement between the actuals and my estimates. I also estimate d project development times, …

A reply to “A note on metrics of Pascal programs"