Software engineering (SE) is a very young field of study. The first computer science department (in the United States) was established in just 1962 (Rice and Rosen 2002) and it wasn’t until after a NATO conference on the “software crisis” in 1968 that the term “software engineering” came into common use (Naur and Randall 1969; Bauer 1972), and the first degree program for software engineers in the United States wasn’t established until 1978 at Texas Christian University.
Software engineering is more than just “coding,” it is applying “a tematic,disciplined,quantifiable approach to the development, operation,and maintenance of software” (IEEE 1990); it is also the engineering of software to meet some goal, and to see that the constructed software operates over time and that it is maintained during its expected life.
Such definitions of software engineering have led the way to a plethora of processes, paradigms, techniques, and methodologies, all with the goal of helping to make the process of engineering correct software repeatable and addressing the concerns raised at the 1968 NATO conference on the “software crisis,” where it was recognized that software was routinely late,over budget, and simply wrong. To enumerate a list of such processes,paradigms, techniques, and methodologies here would be too arduous,but for the most part it, is generally accepted that the construction or engineering of software involves:
· Need
· Craftsman
· Compensation
In other words, some individual or group in need of software obtains that software product from a programmer or group for some amount of compensation.This is nothing more, really, than the law of supply and demand,which has been tested throughout human civilization. Following such law,if there is no “need,” then there is no one to compensate the craftsman for their product, and hence no product.
Principles of software engineering
As such, nearly all defined processes for software engineering include some role for the end-user or defining-user in a software engineering process (such as requirements engineering (IEEE 1990) or “use cases” and “actors” in the Rational Unified Process (Jacobson, Booch, and Rumbaugh 1999)). Further, software engineering is concerned with the principles behind effectively organizing the team of engineers that craft the software, and also with how that craftsmanship is accomplished, in relation to:
1. Designing the software (its architecture, modules, and interactions)
2. Programming, or coding, the designed software
3. Testing the software against design and need
4. Documenting that which is designed, programmed, and tested
5. Managing those that design, program, test, and document
Through the short history of rationalizing the process by which software engineering is, or should be, accomplished, the members of the SE community have reached a fairly common understanding of what software engineering is, and how software engineering should be done. It is the apparent departure of free and open source software (F/OSS) from this understanding (or belief in that understanding), combined with the success (or perceived success) of many F/OSS projects, that has attracted the attention of many in the research community. In this section, anumber of authors have been selected to bring to the foreground specificobservations from various F/OSS projects.
Current trends in software engineering
Software engineering is a young discipline, and is still developing. The directions in which software engineering is developing include:
Aspects
Aspects help software engineers deal with quality attributes by providing tools to add or remove boilerplate code from many areas in the source code. Aspects describe how all objects or functions should behave in particular circumstances. For example, aspects can add debugging, logging, or locking control into all objects of particular types. Researchers are currently working to understand how to use aspects to design general-purpose code. Related concepts include generative programming and templates.
Agile
Agile software development guides software development projects that evolve rapidly with changing expectations and competitive markets. Proponents of this method believe that heavy, document-driven processes (like TickIT, CMM and ISO 9000) are fading in importance[citation needed]. Some people believe that companies and agencies export many of the jobs that can be guided by heavy-weight processes[citation needed]. Related concepts include Extreme Programming and Lean software development.
Experimental
Experimental software engineering is a branch of software engineering interested in devising experiments on software, in collecting data from the experiments, and in devising laws and theories from this data. Proponents of this method advocate that the nature of software is such that we can advance the knowledge on software through experiments only[citation needed].
Model-driven
Model Driven Software Development uses (both textual and graphical) models as primary development artifacts. By means of model transformation and code generation a part or complete applications are generated.
Software Product Lines
Software Product Lines is a systematic way to produce families of software systems, instead of creating a succession of completely individual products. This method emphasizes extensive, systematic, formal code reuse, to try to industrialize the software development process.
The Future of Software Engineering conference (FOSE), held at ICSE 2000, documented the state of the art of SE in 2000 and listed many problems to be solved over the next decade. The FOSE tracks at the ICSE 2000 and the ICSE 2007 conferences also help identify the state of the art in software engineering.
