professionalismterminology
Can software development be considered engineering? If no, what are the things that it lacks in order to be qualified as an engineering discipline? Related to this is this question on Stack Overflow about the difference between a programmer and a software engineer.
There is the Software Engineering Institute at Carnigie Mellon University that prescribes and maintains the CMMI standards. Is this something that will turn development into engineering?
Great Question.
It is important to distinguish between 'Development' and 'R&D.'
R&D = experimenting with ideas/technology that may never actually become a product.
Software Development = working on a product/service desired by a real customer.
R&D is all about developing new solutions for a specific problem domain. The end result of this endeavor is something that I call "research toys".
To be a software product, the research toy has to be completely re-implemented. Failure to do so will result in a product that appeals to an increasingly elite and erudite user base. The problem here is that this elite and erudite user base typically has no money to spend.
To be a successful, the software product must be a faithful re-implementation of the research toy, accessible and loved by the commodity user. To be truely remarkable, the software product must simultaneously appeal to the elite and erudite user.
Research implies scholarly or scientific inquiry and tends to be aimed at the greater good of an industry or society at large. Product development has different motivations and outcomes: it is driven by the potential for profit. The state of product development is healthy. The state of lighting research is not.
We need a collective commitment to the greater good to answer such questions. But this is not just philanthropy; the answer would address a practical goal. Light sources that are spectrally tuned to the visual system will be more sustainable. They will use less energy by generating their output in regions of the spectrum where the visual system responds most strongly, resulting in better seeing for building users. This example reinforces the difference between research and product development.
All development of new products to be R&D. I think some of you are confusing pure, abstract science with R&D. They aren't the same. R&D can be very product oriented. Scientists may be looking for a vaccine to cure AIDs. That is a very specific task to create a product to sell and it is certainly R&D and not just guys sitting around messing about with whatever they feel like.
R&D in the technical world = finding ways to do something interesting or important, using known techniques and technology as a starting point.
Software development = finding ways to do something interesting or important, using known techniques and technology as a starting point.
Virtually all software development is the D part of R&D. Some times, there are very little R in Software 'R&D'. Some times, there are pretty large R in Software 'R&D'.
It depends on several measurement. For example,
Managing software development for various sized companies, R&D takes on different meanings depending on the size of the company, customer base, etc.
In a small software company, with only a hand full of employees, the line between R&D software and Production software is usually very small. What one day is a software R&D project, may the next day be shipping as production software to customers.
As software companies grow, and they have one or more production software lines, they tend to create greater separation between R&D software projects and Production software products (for obvious reasons). This R&D gap is typically created to create greater diversification in their software products for tomorrow, while allowing the production software development to continue to produce today.
This is not to say that the production software products won't get innovative new features. The production software developers are typically just as "sharp" as the R&D developers. In fact, at one company, we had an enrichment program that allowed production software developers to rotate in and out of R&D projects. This not only added fresh brain power to the R&D teams, but in many cases, the production developers came back with new ideas on producing better production level software.
D = "knowing where you want to be at the end", and R is because "at the beginning of the project, you don't know what will be required to get there"
R&D are the lucky folks who get to do anything they want without accountability.
Good research/resource on this topic :
In the opening sections of the paper that you quote, Boehm states:
There is very little agreement in the software field on the definitions of the terms "verification" and "validation."
Boehm defines the terms verification and validation as he intends to use them in the rest of the paper, in order to be able to clearly present the rest of the writing without ambiguity:
Verification - to establish the truth of the correspondence between a software product and its specification. (Note: This definition is derived from the Latin word for "truth," veritas. Note also that data bases and documentation are fit subjects for verification, as well as programs.)
Validation - to establish the fitness or worth of a software product for its operational mission. (Note: This definition is derived from the Latin word for "to be worthy," valere.)
I think that the Guide to the Software Engineering Body of Knowledge can provide some insight into this as well:
Classical treatments suggest that “verification” deals with static evaluation methods and that “testing” deals with dynamic evaluation methods. Recent treatments, including ISO/IEC draft 29119, are blurring this distinction, though, so testing standards are mentioned here.
What all of this says is that, at the time Boehm wrote his paper, there wasn't a widely accepted singular definition for what is "verification" and what is "validation". Even today, that's still true.
Now that we know that there is some ambiguity in the terms "verification" and "validation" (and how "testing" fits into these), we can look at the diagram that Boehm presented.
Something that Boehm didn't discuss, but I've seen in multiple sources (including ISO/IEC 12207), validation specifically requires that the validation activities occur in the operational environment and can achieve its intended purposes, from the user's perspective. This may be implied by Boehm's definitions, but it's not clearly stated.
Boehm also used the term "acceptance testing". You are interpreting this as "user acceptance testing". There are other kinds of acceptance testing, such as factory acceptance testing (FAT). In my experience, a FAT is performed by the developing organization at the developing organization's site, with the procedures reviewed and accepted by the customer. This is a check to ensure the complete system (all software and hardware) are fully functioning, meet the specification, and a final inspection prior to delivery to the customer's facility. Based on Boehm's definitions, this can be a verification activity the developing organization can not fully exercise the product within the operational context.
What you are considering "user acceptance testing" is likely "OT&E" - Operational Test and Evaluation. This is indeed a validation activity since the customer and user are able to see the product within the operational context and say if it does or does not meet their needs.
Best Answer
Yes, software engineering is an engineering discipline.
Wikipedia defines engineering as "the application of mathematics, as well as scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes, solutions, and organizations." The result of software engineering is a software system that can improve the lives of people, and it can involve some combination of scientific, mathematical, economic, social, or practical knowledge.
In terms of how it's viewed, academically and professionally, it varies. Software engineering programs can be accredited by ABET as engineering programs. Software engineers can be members of the IEEE. Some companies consider software engineering to be an engineering discipline, while others don't - it's a toss up, really.
The best book on this subject is Steve McConnell's Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers. It looks at software engineering as a profession, evolution from a craft to a profession, the science of software development, the difference between software engineering and software engineering (applying engineering practices to software versus engineers who happen to build software, with a case study that includes my alma mater), certification and licensing, and ethics.
Glenn Vanderburg has a series of talks called "Real Software Engineering" that has has given between 2010 and 2015 at a number of conferences, along with two related talks, "Craft, Engineering, and the Essence of Programming" (given in 2011 as a keynote at RailsConf) and "Craft and Software Engineering" (given in 2011 at QCon London). I think these talks are a pretty comprehensive argument for why software engineering is an engineering discipline.
One argument, which Vanderburg brings up briefly in his talks, is the one made by Jack W. Reeves in 1992 (and revisited again in 2005) on what software design is and how code is the output of software engineering design activities (this is also discussed on the C2 wiki). Once you get away from older schools of thought where specification and modeling is software design and into code being software design, some of the relationships between software engineering and other engineering disciplines become more readily apparent. Some differences and the reasons for those differences become even more apparent after you see that economics of software development are vastly different than many other disciplines - construction is cheap (almost free, in many cases), while design is the expensive portion.
No. CMMI is a process improvement framework that provides guidance to organizations on what kinds of activities are useful when building software. Engineering disciplines typically have an engineering process. Having such a process is important for the successful completion of high quality projects. That said, the CMMI (or any other process framework or methodology) is just a single tool - using it won't make you magically advance from a developer to an engineer. However, not following some kind of process is, in my opinion, a sign of a project that is not an engineering project.
It's only as much value as other people put into it. There are useful courses and there are useless courses. There are valuable certificates, and certificates that aren't worth the paper they are printed on. There are a lot of factors, from who is endorsing or accrediting the course or who is issuing the certificate to your current industry of employment to your current job and where you want to go.