Why Software Engineering Isn't Like Other Engineering Disciplines and How it Changes the Game


Posted October 8, 2018 by stevewillson703

It is often estimated that there are over 11 million professional software programmers world-wide as of 2014.

 
It is often estimated that there are over 11 million professional software programmers world-wide as of 2014. When I started as a programmer inside 1973 one of the greybeards in the first company I worked well for gave me some advice. He said, "Learn the things which never change. "

When I started college six many years earlier in 1967 the school I attended didn't possess a major called Computer Science and so I did my undergrad and graduate work in Mathematics taking a few computer-programming courses along the way. This was the way many of us got started as applications developers back in the 70's.

The term Software Engineering was brand new at the time, being coined at the 1968 NATO Software Technological innovation Conference. The thinking back then was that we needed to use existing engineering methods to software development to address common spending budget, schedule and quality problems that were being referred to at the time since the "software crisis. " As a result, what most people have come to think about as Software Engineering involves activities which greatly look like other engineering disciplines including civil, mechanical, and electric engineering.

On the surface this idea seems to make sense. When you develop something using the other engineering disciplines (e. g. the bridge, a building, a specialized piece of hardware, the circuit board) you need to figure out the requirements, design a solution, apply it, and test it. All of these steps make sense for software as well. So one could certainly argue from this perspective which software engineering should resemble these other engineering disciplines. But when you look more closely at what we have learned regarding software development over the last forty years, as well as how we teach this to today's software developers, this analogy quickly stops working.

By the time the 1990's rolled around, because computer programming came into existence such a big part of what was called Computer Science, numerous Universities had added a course with a title of "Software Engineering" to their Computer Science curriculum. Popular textbooks which were used at that time to teach these courses included Ian Sommerville's textbook titled: "Software Engineering". From 1992 to year 1994 I used the Fourth Edition of this textbook to teach Computer software Engineering at Binghamton University. Today, Ian Sommerville's publication is still in use in many Universities around the world-now in its 9th Edition. This leads to a question:

Why do we need to revise a textbook approximately every 3-4 years that supposedly is training our students the fundamentals of Software Engineering?

If you look at books used in Civil Engineering, Mechanical Engineering, and Electrical Technological know-how the vast majority of these books do not require revisions nearly so often. To comprehend why this is the case we need to look more closely in what is being taught in most Universities around the world under the name regarding "Software Engineering. "

When you do look more closely you will discover that we are teaching our next generation of software program professionals whatever is currently popular in terms of software practices, in addition to methods. Popular software practices and methods today tend to be known by buzzwords such as Agile, Use Cases, Consumer Stories, RUP, XP, Scrum Lean, PSP, TSP and also the list goes on and on...

The problem with this approach to teaching Program Engineering is that software practices and methods frequently arrive and go and will continue to come and go which explains why Sommerville must continually update his textbook. This leads to an additional question:

What about that greybeard in the first company I actually worked for in 1973 who told me to learn what never change? Did he give me bad advice? Otherwise, what are we teaching our next generation of application professionals with respect to the things that never change about Software Engineering?

Before answering these questions, let's first step back and request a few different questions:

Does a set of things that never enhancements made on Software Engineering actually exist?

If they do exist, do we understand what they are?

If we do know what they are, are we teaching these questions consistent way to our next generation of software pros so when they come out of the University they are prepared to carry out themselves as software professionals?

Such a set of software architectural essentials does in fact exist. This belief has inspired an international group of volunteers to take on the task of codifying all those essentials. The intent is for these essentials to be coached to our next generation of software developers helping to get ready them as true software professionals.

The volunteers associated with this initiative (known as SEMAT - Software Anatomist Method and Theory) have been working on this task since the year 2010. This past year SEMAT achieved a major milestone with the announcement through the Object Management Group, an international standards consortium, that they have followed "Essence" as an official OMG standard.

So this leads to some more questions:

Just how different is the Essence standard from what exactly is being taught to our software developers today, and has been educated for the past 40 years under the name of Software Engineering?

As well as:

Will the differences really help with the problems that many believe nevertheless plague the software industry with respect to common budget, and routine over-runs and poor software quality?

From one perspective just what Essence captures is not new. The Essence standard includes typical words such as, Stakeholders, Opportunity, Requirements, Software System, Team, Function, and Way of Working. But from another perspective precisely what Essence captures is dramatically new. In fact , some are phoning it a "paradigm shift" that many of the "old guard" will have great difficulty even comprehending.

To give you an idea in the changes involved when using Essence I again think returning to my early days as a programmer in the late 1970's. In those days My spouse and i worked in the flight simulation domain developing software techniques to train pilots to fly high performance aircrafts. One of our areas of expertise was writing software to provide record/playback abilities to help instructors train young aircraft pilots in traveling skills.

I recall one specific project I labored on and a customer pilot instructor I worked with. After trying to explain to him how he could use my record/playback software to assist him demonstrate to his student pilots where they had created mistakes, he excitedly wrote up a number of defects asking for changes to my software.

I argued vehemently with this program manager that non-e of these issues were really defects. Because I had taken the time to explain what was feasible with my record/playback software the pilot instructor started to envision additional features that could make his job easier. This individual wrote his ideas up on a defect form even though they had been all enhanced capabilities we never planned to deliver plus were not part of the requirements.

But my project manager did not want to discuss with the customer whether or not these requests were in-scope, or out-of-scope. His view was-- as many viewed computer software then and still view it today-- that it is easier to change program than engaging the customer in a discussion.

Because software is smooth, we tend to view it as easy to change. It's not like hardware. Metallic isn't easily bent. This perspective changes the whole video game when it comes to software.

This ability to change software code rapidly and in endless ways completely changes the dynamics which exist between software developers and their stakeholders including program administrators and customers. One way this difference exemplifies itself is really as users become familiar with the software they often see new ways that changes to the software could make their job easier as my preliminary instructor customer did back in the late 1970s.

We now understand from experiences that there are other dimensions to Software Architectural that are critical to effective professional software engineering methods. These other dimensions take us beyond just the ease which the code can be changed. To date, these additional sizes have not received anywhere near the attention they deserve.

Whenever you change code you may also be affecting the requirements, and you may also generally be affecting other capabilities in the software system previously tested. Altering code means additional work, additional testing, possibly becomes supporting user manuals and so on... All this affects budget and even schedule, and introduces additional risk to the quality on the software.

While on the one hand the ability to change the software program code rapidly brings great power to the software industry, it also implies that software professionals must be increasingly attune to their agreed method of working, the impact and time that it takes to do the extra work, and the risk when making unplanned rapid changes. The actual agile movement over the last ten years has provided a great service to ensure that the software community understand this major difference related to Software Executive including the importance of early and ongoing interaction with stakeholders and the importance of software developers estimating the cost of their own do the job.

While the software engineering community has learned a great deal through the other engineering disciplines, they have also learned the crucial importance of these other dimensions that bring differences from earlier engineering experiences. These differences mean that software developers have to be trained in new and different ways to be effective software professionals.

Soon after the kickoff of the SEMAT initiative in March involving 2010, one of SEMAT's initial signatories sent me a write copy of a book he was working on to review. Watts Humphrey who had planned to be very active in the early SEMAT operate fell ill just as the SEMAT work was making ready and I was asked to help him get his prepared effort going. In late August that same year W sent me the following email just a few months before their passing. He agreed that I could share this e-mail with others:

Paul, From your comments, it sounds as if you do get the point of my book, for which I am thankful.... the correct answer and the one that I was most interested in going after with SEMAT, concerns how we can ensure that software authorities are properly trained and have a suitable set of professional behaviour and skills before they even get to industry. It really is my hope that the SEMAT effort eventually will be able to spearhead the drive to get the academic community to refocus their own programs on teaching software professionals to act like industry experts and to manage themselves.

When they do, their graduates can negotiate with their management and to do superior work.... Which is what professionals should do... A good start in this direction would be to persuade them of the necessity of having software people measure their own deliver the results. Since software work is, as we said, knowledge give good results, any truly accurate measures must be taken by the software package professionals themselves.... Watts Humphrey

Watts Humphrey has been known as the father of software quality. After completing a distinguished profession at IBM he went on to become a fellow of the Software package Engineering Institute founding the Software Process Program. In the year 2003 he was awarded the National Medal of Technology.

These days Watts would have been heartened by the SEMAT work which is going on in the academic community. The first full University training course based on the new Essence standard has been developed and is becoming delivered to students this year by Dr . Carlos Zapata in the Universidad Nacional de Columbia in Medellin, Columbia, together with Essence is being used in first- and second-year software executive courses at KTH Royal Institute of Technology throughout Sweden under the guidance of Dr . Mira Kajko-Mattson. Generally there have also been Essence field studies conducted with students through Dr . Cecile Peraire at Carnegie-Mellon West in the United States. The next phase for the SEMAT community is to demonstrate how Essence will help in industry by publishing case studies of real use and measured results on industrial projects.

visit: https://www.crestsoftware.co.uk
-- END ---
Share Facebook Twitter
Print Friendly and PDF DisclaimerReport Abuse
Contact Email [email protected]
Issued By steve
Business Address texas
austin
Country United States
Categories Advertising
Tags construction document management software
Last Updated October 8, 2018