scispace - formally typeset
Search or ask a question
Journal ArticleDOI

Will there ever be software engineering

01 Jan 1998-IEEE Software (IEEE)-Vol. 15, Iss: 1, pp 36-39
TL;DR: In his opening essay, Ed Yourdon forecasts both a happy and an unhappy future; the dark cloud of Yourdon's bad future offers a silver lining: if it comes to pass, there might be demands for certification and licensing of software professionals and for a formal approach to software development.
Abstract: In his opening essay, Ed Yourdon forecasts both a happy and an unhappy future. His bright future promises challenging projects, exciting technologies, innovative applications, giant salaries, and lucrative stock options. His gloomy future warns of US federal and state government departments unable to solve their Year 2000 problem, a business revolt against expensive and troublesome software that delivers no apparent economic benefits, and a consequent drying up of money to buy new releases of COTS software or to finance new software development. The good news and the bad news are essentially commercial. But the dark cloud of Yourdon's bad future offers a silver lining: if it comes to pass, there might be demands for certification and licensing of software professionals and for a formal approach to software development. In a word, we might be expected to become serious software engineers. We won't, of course. Yourdon is confident that we have learned a lot about soft-ware processes, methods, and techniques; he says that we have a vast body of knowledge in requirements, risk management, metrics, testing, and quality assurance incorporated into the SEI Capability Maturity Model. So that's all right, then. We don't really need software engineering in the narrow academic sense.
Citations
More filters
Journal ArticleDOI
TL;DR: The main goal is to explore, from a multifaceted perspective, why SE's immaturity is where it is now and how it can move forward.
Abstract: A recognized engineering profession must have an established body of knowledge and skill that its practitioners understand and use consistently. After 30 years, there is still a wide gap between the best and the typical software engineering practices. To close this gap, we need a deeper partnership among industry, academia, and professional societies. We have spent some time considering the reasons for SE's immaturity. All of us are heavily involved in both industry and academia and have been active in professional societies that aim to promote SE as a profession. Promotion efforts are by no means limited to the US, but because our experience is primarily with US activities, that is our focus in this article. Our main goal is to explore, from a multifaceted perspective, why we are where we are now and how we can move forward.

61 citations

Journal ArticleDOI
TL;DR: Two extended papers from the workshop, an invited contribution from Jackson in which he positions problem frames in the context of the software engineering discipline, and this article, where a review of the literature are provided, where the literature is reviewed.
Abstract: It has been a decade since Michael Jackson introduced problem frames to the software engineering community. Since then, he has published further work addressing problem frames as well as presenting several keynote addresses. Other authors have researched problem frames, have written about their experiences and have expressed their opinions. It was not until 2004 that an opportunity presented itself for researchers in the field to gather as a community. The first International Workshop on Advances and Applications of Problem Frames (IWAAPF'04) was held at the International Conference on Software Engineering in Edinburgh on 24th May 2004. This event attracted over 30 participants: Jackson delivered a keynote address, researchers presented their work and an expert panel discussed the challenges of problem frames. Featuring in this special issue are two extended papers from the workshop, an invited contribution from Jackson in which he positions problem frames in the context of the software engineering discipline, and this article, where we provide a review of the literature. he literature.

35 citations


Cites background from "Will there ever be software enginee..."

  • ...Specialism Reflecting the specialism of engineers in traditional engineering disciples, in [52] it is asserted that some parts of software engineering lack an ‘essential ingredient’: the ‘thick...

    [...]

Journal ArticleDOI
TL;DR: An explanatory conceptual framework is derived, based on an extension of the “method-in-action” model, the application to WBSD has not been previously investigated in depth and it is proposed that this framework of WBSD issues is valuable in a number of ways to educators, researchers, practitioners, and method engineers.
Abstract: This paper reports the findings of a detailed study of Web-based systems design (WBSD) practices in Ireland based on data collected over a 3-year period (2002–2005), the objectives of which were to (1) contribute towards a richer understanding of the current “real-world” context of WBSD by characterising the profile of a typical project (team size, timeframe, nature of requirements, etc.) and identifying the key challenges, constraints, and imperatives (i.e. “mediating factors”) faced by Web-based system designers, and (2) understand how those contextual parameters and mediating factors influence the activity of WBSD as regards the selection and enactment of whatever design practices are therefore engaged (i.e. the use of methods, procedures, etc.). Data was gathered through a survey which yielded 165 usable responses, and later through a series of semi-structured qualitative interviews. Using grounded theory, an explanatory conceptual framework is derived, based on an extension of the “method-in-action” model, the application of which to WBSD has not been previously investigated in depth. It is proposed that this framework of WBSD issues is valuable in a number of ways to educators, researchers, practitioners, and method engineers.

27 citations


Additional excerpts

  • ...advancement of theory [6–8]....

    [...]

Proceedings ArticleDOI
01 Jan 2002
TL;DR: This research-in-progress paper provides an outline answer to how hypermedia systems differ significantly from ‘traditional’ information systems, by hypothesizing why specialized hypermedia design methods set forth in the literature are not being use in practice, and by suggesting a number of implications.
Abstract: Hypermedia systems design presents challenges that are not normally encountered with the development of orthodox ‘traditional’ information systems. In recognition of these challenges, and of the purported inadequacy of conventional software engineering techniques, there is much support in the literature for the view that new, specialized methods are needed. The question must therefore be asked: do we really need new methods for hypermedia systems design? This research-in-progress paper provides an outline answer by asking how hypermedia systems differ significantly from ‘traditional’ information systems, by hypothesizing why specialized hypermedia design methods set forth in the literature are not being use in practice, and by suggesting a number of implications.

24 citations

References
More filters
Journal ArticleDOI
TL;DR: A detailed investigation of the factors involved in the software-related overdoses and attempts by users, manufacturers, and government agencies to deal with the accidents is presented.
Abstract: Between June 1985 and January 1987, the Therac-25 medical electron accelerator was involved in six massive radiation overdoses. As a result, several people died and others were seriously injured. A detailed investigation of the factors involved in the software-related overdoses and attempts by users, manufacturers, and government agencies to deal with the accidents is presented. The authors demonstrate the complex nature of accidents and the need to investigate all aspects of system development and operation in order to prevent future accidents. The authors also present some lessons learned in terms of system engineering, software engineering, and government regulation of safety-critical systems containing software components. >

1,307 citations

Trending Questions (1)
Can we get a job in software company by doing electrical engineering?

We don't really need software engineering in the narrow academic sense.