Knowledge-based system development for assisting structural design

The development of software systems that really assist engineering design requires an important modelling effort. Computational treatment of these problems is carried out through the application of software engineering and knowledge engineering techniques. Both fields have significantly evolved during the last few years, and now advanced methodologies for the development of conventional software systems and knowledge-based systems, emphasizing different modelling principles, are available. In particular, both object-oriented modelling and knowledge modelling present useful individual characteristics that are complementary. The article analyses the need for integration of those useful modelling aspects, and presents an integrated scheme for the development of knowledge-based design systems (KBDS’s). By way of illustration, the modelling scheme proposed is applied to the development of a KBDS in a specific domain of structural design.     

Software Considerations for Microprocessors

For computers of all sizes, software has become a critical element in systems design and implementation. As dramatically as the costs of hardware have dropped, the labor-intensive costs of software have risen. In addition, there are no widely accepted and practiced techniques for controlling and estimating software development and manufacturing (size) costs, or forecasting software capability and reliability. To be sure, these problems are being addressed by software engineering, but today that is still a very primitive discipline in comparison with other computer engineering fields.     

Are software engineers true engineers?

Software engineering is an often used term to describe the activities, methods, and tools of large scale software development. There is an ongoing discussion whether Software Engineering can be considered as an engineering discipline. In many respects the development of software shares common properties of other engineering disciplines. In contrast to “classical” engineering fields, theories, questions, and approaches from the social sciences are more important than those from the natural sciences. This is investigated here by comparing the situation found in software engineering with several concepts of engineering in general. Three viewpoints are used to guide this comparison: one is a social stereotype of engineers; the second is the organization of engineering profession organizations; and the third are capabilities which the engineers of the future will need. This revised version was published online in June 2006 with corrections to the Cover Date.     

基于软件过程的质量管理

随着信息技术的发展,软件在各行各业发挥了巨大作用,并形成了自己的产业。软件产品的功能度和复杂性要比制造业的产品高得多,它在投入使用后,所能发挥的功效也是其他任何形式的硬件产品所无法比拟的。目前,软件产品的质量问题主要来自开发过程。本文结合作者的项目经历就基于软件过程的软件质量管理做一些探讨。     

普通院校软件工程专业实践教学体系

从普通院校软件工程专业实践教学实际出发,在分析普通院校软件工程专业实践教学中目前存在的问题的基础上,提出了软件工程专业学生能力培养的路线图和把企业数据导入实验室建立模拟企业的观点,结合我院的软件工程专业实践教学实际,在实践中不断验证与改进,并取得了显著的效果。     

Commercial vs. aerospace worlds: comparing software engineeringcultures

Two and a half years ago, I retired from the aerospace and defense industry after 35 years. Of those 35 years, I spent the last 20 in software and system engineering, including the last 10 in software process improvement, quality, and related disciplines. I now work in commercial industry, in software quality for a company where that means process development, documentation, and improvement, rather than testing (as it means at many other companies). From this new perspective, I want to compare the software engineering cultures in these two different environments, examine specifics, and see if any general conclusions can be drawn     

Software — A performing science?

Technical issues are important for software work, but so are personal disciplines, teamworking skills, and application‐domain knowledge. Also, much like an artistic performance, first‐class software engineering requires constant practice, good technique, and effective coaching. The challenge of producing high‐quality large‐scale software products is substantial today and will be even more demanding in the future. Without concerted action, we cannot expect software organizations' capabilities to improve. To address these problems, the Software Engineering Institute (SEI) has developed the Personal Software Process (PSP) and the Team Software Process (TSP). This paper addresses the problems of software engineering and discusses the intellectual nature of software work. It then reviews the characteristics of this kind of work and describes the principal conditions for effective software performance. In the conclusion, the author makes some observations about the challenges ahead and the future actions required. This revised version was published online in June 2006 with corrections to the Cover Date.     

Editors' introduction: Comparative software engineering: Review and perspectives

Engineering is a set of disciplines seeking solutions for complicated problems and systems that could not be done by individuals. The aim of engineering is to repetitively produce complicated artefacts in an efficient way. This paper describes a set of generic engineering principles and an engineering maturity model. With the engineering principles and model, the nature and status of software engineering are analysed. Interesting findings on what software engineering can learn from generic engineering principles are presented. This paper intends to show the nature, status and problems of software engineering, as well as its future trends, based on the comparative studies between the generic engineering principles and software engineering practices. This revised version was published online in June 2006 with corrections to the Cover Date.     

Industrial Applications of Software Synthesis via Category Theory—Case Studies Using Specware

Over the last two years, we have demonstrated the feasibility of applying category-theoretic methods in specifying, synthesizing, and maintaining industrial strength software systems. We have been using a first-of-its-kind tool for this purpose, Kestrel's Specware^TM software development system. In this paper, we describe our experiences and give an industrial perspective on what is needed to make this technology have broader appeal to industry. Our overall impression is that the technology does work for industrial strength applications, but that it needs additional work to make it more usable. We believe this work marks a turning point in the use of mathematically rigorous approaches to industrial strength software development and maintenance.It is interesting to note that when this technology is applied to software systems whose outputs are designs for airplane parts, the design rationale that is captured is not only software engineering design rationale, but also design rationale from other engineering disciplines (e.g., mechanical, material, manufacturing, electrical, human factors, etc.). This suggests the technology provides an approach to general systems engineering that enables one to structure and reuse engineering knowledge broadly.     

Software “engineer”? Time will tell

A discussion is given on the legal and policy aspects of information technology use and development in the US. There is a continuing proliferation of individuals and companies who portray themselves as being or employing software “gurus”, “experts” and “engineers”-titles that imply the knowledge and capability to resolve programming problems. Many of these individuals either lack these skills and experience or are applying their knowledge in environments where it has no value. This problem is particularly acute in the area of telephony or data/software/telecommunications convergence. There are signs, however, that your ability to describe yourself as an engineer or your company's services as engineering, without proper training and certification, may be coming to an end     

Motivated humans for reliable software products

This paper focuses on the software engineer, as opposed to some software engineering discipline. The author's worldwide experience in software development has resulted in concluding that the vast majority of problems encountered while developing software are more people oriented rather than technology based. Therefore, for there to be any improvements in the reliability of software, it may be wise to revisit some of the people issues, otherwise, even the best methods, tools and techniques will not make an impact on the software development process so as to result in higher levels of software quality. Many are the problems which the software engineer is faced with while trying to piece together the complex information systems that the current global market dictates. Lack of office space and engineer concentration, unpaid overtime, non-productive meeting cultures, performance appraisals and absence of team work all contribute to the demotivation of the software engineer. Trying to introduce a new tool or a new technique to a demotivated staff is simply a waste of time. Thus, it is of paramount importance to realize that in the labour intensive software development world, the focus must first be on the human factor. Basic human nature has not changed over the years, therefore, the author sought out solutions from the past regarding the management of people, so as to be applied today in the development of software. This paper concludes with a ‘euphoria quadrant’ so as to provide a simple means for software producing units to gauge their management style and their overall working environment.     

Software is different

The reliability notions that have worked so well for hardware do not work for software. It is not just reliability issues that makes software engineering different than most traditional engineering disciplines, but fundamental, usually unrecognized paradigms. Twelve assumptions that are rarely questioned in traditional engineering fields are explored and each is shown not to hold in software engineering. These differences between software engineering and traditional engineering are often at the core of misunderstandings between their practitioners. This revised version was published online in June 2006 with corrections to the Cover Date.     

A reference framework for process-oriented software development organizations

In this paper, a proposal of a generic framework for process-oriented software development organizations is presented. Additionally, the respective way of managing the process model, and the instantiation of their processes with the Rational Unified Process (RUP) disciplines, whenever they are available, or with other kind of processes is suggested. The proposals made here were consolidated with experiences from real projects and we report the main results from one of those projects.     

Using group support systems for software inspections

Software engineering sometimes appears to be years behind other disciplines in terms of predictability and quality. But we like to argue that the software industry is facing problems now that other industries have yet to face. Constructing a high-quality, million-line program is daunting. Fortunately, progress is occurring and merging two important areas: software process improvement and technological support. The authors describe their experience implementing a group support system (GSS) for software inspections in an industrial environment. The results confirm their belief that such support can improve the efficiency and effectiveness of inspections, provided the inspections are properly conducted     

The difficulties of building generic reliability models for software

The Software Engineering research community have spent considerable effort in developing models to predict the behaviour of software. A number of these models have been derived based on the pre and post behaviour of the development of software products, but when these models are applied to other products, the results are often disappointing. This appears to differentiate Software from other engineering disciplines that often depend on generic predictive models to verify the correctness of their products. This short paper discusses why other engineering disciplines have managed to create generalized models, the challenges faced by the Software industry to build these models, and the change we have made to our process in Microsoft to address some of these challenges.     

面向航空航天领域的工业CFD软件研发设计

工业CFD (computational fluid dynamics)软件属于计算机辅助工程(computer-aided engineering, CAE)软件的一种, 在航空航天等领域有着广泛的应用. 其开发过程强烈依赖于流体力学、数学、计算机以及其他领域学科知识模型, 涉及大量理论推导、模型构建、算法优化、验证...     

Schlanke Produktionsweisen in der modernen Softwareentwicklung

This paper shows that Extreme Programming (XP) is rooted in the principles of Lean Production. XP drastically slims down the development process, but adds extreme customer orientation and extreme ways of quality assurance to the process. The fact that XP and other agile methods in modern software development are based on lean principles explains why agile methods can produce high-quality software in a cost-effective way. The paper also contains a discussion of problems that come up when using XP in practice, and raises important questions about lean methods in software development; for example, whether lean methods scale to large software projects and large software organizations. When trying to answer such questions, software engineering could draw from experience with lean production and lean development in other fields.     

Graphical representation of models and results in the finite element system COSAR

The finite element method has become one of the most-used calculation procedures in various fields of engineering in recent years. Due to progress in hardware architecture and computer graphics, the efficiency of its application could increase decisively. Notably, the solution of complex problems would be unthinkable today without the availability of powerful graphic processors.

In connection with the development of the finite element system COSAR at the Technical University Magdeburg, various graphic processors were created. In this paper, these processors are introduced. Information is given about interactive techniques for the generation of finite element models, about checking procedures for complex 3D structures by graphical means, and about possibilities for result presentation with colored pictures. Requirements for hardware architecture and software tools in the field of graphical input and output are discussed.     

Visualization viewpoints: beyond geovisualization

The cartographic community realizes that the problems presented by the need to understand complex data can't be solved with maps alone, although they are convinced of their visual strength in complex circumstances. The community, and especially the commission on visualization and virtual environments of the International Cartographic Association, has taken a different approach to mapping. In practice, we should view geovisualization activities in the context of the geoprofessional's working approach. Geodata and software from all types of sources are now linked in geodata infrastructures established on local, national, and international levels. Users solve their problems with services and data available via the infrastructure and no longer need to have all data and software locally available. We should keep reaching to other technology-oriented disciplines, but we need to strive to make geovisualization knowledge common in application fields.     

Artificial intelligence and software engineering: a tutorial introduction to their relationship

This article is a tutorial introduction to artificial intelligence for software engineers, and a similar introduction to software engineering for artificial intelligence workers. Software engineering and artificial intelligence are compared and contrasted in terms of the problems they attempt to solve, the methods they employ, and the tools and techniques that are used. It is argued that a fusion of the two disciplines will be needed for many new software demands. The evidence for this is examined briefly and some of the steps that are needed for an alliance of the two disciplines are mentioned.