[ad_1]
It is estimated that there are over 11 million professional software developers around the world as of 2014. When I started as a programmer in 1973, one of the gray guards of the first company I worked with gave me some advice. He said, "Learn things that never change."
When I started my college studies six years ago in 1967, the school I attended did not have a major called Computer Science, so I did my work at undergraduate and graduate studies in mathematics, taking a few courses in computer programming. This was how many of us started out as program developers in the 1970s.
The term software engineering was new at the time, as it was coined at the NATO Software Engineering Conference in 1968. The thinking at that time was that we needed to apply existing engineering methods to software development to address the common budget, schedule, and quality problems that were being referred to. At the time, it was called "Software Crisis". As a result, what most people think of software engineering includes activities very similar to other engineering disciplines including civil, mechanical, and electrical engineering.
On the surface, this idea makes sense. When building something with other engineering specialties (like a bridge, building, specialized piece of hardware, or circuit board) you need to know the requirements, design a solution, apply it, and test it. All these steps make sense for programs as well. So one can definitely argue from this perspective that software engineering should resemble these other engineering disciplines. However, when you look closely at what we have learned about software development over the past forty years, as well as how we teach it to software developers today, this metric is rapidly collapsing.
By the time it takes place in the 1990s, computer programming has become a large part of what was called computer science, and many universities have added a course called "Software Engineering" to their computer science curricula. Common textbooks that were used at the time to teach these courses included Ian Sommerville's book: "Software Engineering". From 1992 to 1994, the fourth edition of this textbook was used to teach software engineering at Binghamton University. Today, Ian Sommerville is still in use at many universities around the world – in its ninth edition. This leads to a question:
Why do we need to review a textbook about every 3-4 years that is supposed to teach our students the basics of software engineering?
If you look at textbooks used in civil engineering, mechanical engineering, and electrical engineering, the vast majority of these books require almost no revision. To understand the cause of this situation, we need to look closely at what is taught in most universities around the world under the name "Software Engineering".
When you look closely you will find that we know the next generation of software professionals all that is currently popular in terms of program practices and methods. Common practices and methods in today's programs are known by buzz words like Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP and the list goes on and on …
The problem with this approach to teaching software engineering is that program practices and methods often come, go, and will continue, which is why Somerville must constantly update his book. This leads to another question:
What about Grape Bird in the first company I worked for in 1973 who told me to learn things that never change? Did he give me bad advice? If not, what are we teaching for the next generation of software professionals regarding things that never change in software engineering?
Before answering these questions, let's go back first and ask a few different questions:
Are there really a bunch of things that never change in software engineering?
If they exist, do we know what they are?
If we know what it is, do we teach them in a way that is consistent with the next generation of software professionals, so when they graduate from college they are ready to do themselves as software professionals?
This is a set of software engineering fundamentals that actually exist. This belief motivated an international group of volunteers to take on the task of writing down those basics. The intention is to teach these basics to the next generation of software developers who help prepare them as real software professionals.
Volunteers participating in this initiative (known as SEMAT – Software Engineering Curriculum and Theory) have been working on this task since 2010. Last year, SEMAT achieved a milestone with the announcement of the Object Management Group, an international standards group, that it has adopted "Johar" as the official standard OMG .
So this leads to a few other questions:
How is the Essence standard different from what is taught to our software developers today, and has been taught over the past forty years under the name of Software Engineering?
And:
Would the differences really help solve the problems that many still believe the software industry faces in relation to the general budget, excessive schedule and poor software quality?
From the perspective of what is not the essence of what is new. The Essence standard includes common words like, stakeholders, opportunity, requirements, software system, team, work, and way of working. But from another perspective, what Essence picks is completely new. In fact, some describe it as a "paradigm shift" which many "old guards" will have a great difficulty understanding.
To give you an idea of the changes involved when using Essence, think again about my early days as a programmer in the late 1970's. In those days, she worked in the field of flight simulation, where he developed software systems to train pilots to drive high-performance aircraft. One of my areas of expertise was writing a program to provide registration / employment capabilities to help trainers train young pilots in aviation skills.
I remember a specific project I worked on and a client pilot that I worked with. After explaining to him how he could use my recording / playback software to help him illustrate to the student pilots where they made mistakes, he enthusiastically wrote a number of flaws requesting changes to my program.
I highly discussed with my program manager that none of these problems were actually flaws. Since it took me a while to explain what's possible with the recording / playback program, the groundbreaking trainer began to visualize additional features that could make his work easier. He wrote his ideas in the form of a defect although they are all enhanced capabilities that we did not plan to deliver and were not part of the requirements.
But my project manager did not want to discuss with the client whether these requests were in range or out of range. His view – like many programs that were watched and still watched today – was that it was easy to change the program rather than involve the customer in a discussion.
Since the software is weak, we tend to easily watch it change. It is not like hardware. The metal does not bend easily. This perspective changes the entire game when it comes to the program.
This ability to quickly change the program icon and in endless ways completely changes the dynamics between software developers and residents including program managers and clients. One of the ways this difference explains is that users are familiar with the program, and they often see new ways that changes to the program will facilitate their work as did my pioneering trainer colleague in the late 1970s.
We now know from experience that there are other dimensions of software engineering that are essential to effective professional software engineering practices. These other dimensions make us far beyond just the ease with which you can change the code. So far, these additional dimensions have not received anywhere near the attention they deserve.
When you change the icon, it may also affect requirements, and may also affect other capabilities in the pre-tested software system. Changing the code means additional work, additional testing, and possibly changes to support user manuals, etc. … all this affects the budget and schedule, and leads to additional risks to the quality of the program.
While on the one hand, the ability to change program code quickly brings great strength to the software industry, and this also means that software professionals must be more in line with their agreed upon way of working, the impact and time taken to do additional work, and risks when making unplanned rapid changes . The agile movement over the past ten years has provided a great service to help the software community understand this major difference related to software engineering, including the importance of early and continuous interaction with stakeholders and the importance of software developers estimating the cost of their work.
Although the software engineering community has learned a lot from other engineering disciplines, they have also learned the critical importance of these other dimensions that make differences from previous engineering experiences. These differences mean that software developers need to be trained in new and different ways to be effective software professionals.
Soon after the SEMAT initiative was launched in March 2010, one of the first two SEMAT signers sent me a draft copy of a book he was working on reviewing. Watts Humphrey, who had intended to be very active early in SEMAT's work, fell ill just as SEMAT's work was getting ready and I was asked to help him continue his planned efforts. In late August of the same year, Watts sent me the following email message a few months before his death. I agree that I can share this email with others:
Paul, from your comments, it seems like you've got a point in my book, and I'm grateful to him …. the correct answer and the answer that I was most interested in following up with SEMAT, relates to how to ensure program professionals are properly trained and have an appropriate set of professional attitudes and skills Before they got to the industry. I hope SEMAT's efforts will ultimately lead the campaign to make the academic community refocus its programs on teaching program professionals to work as professionals and manage themselves.
When they do that, their graduates will be able to negotiate with their management and do a superior job …. This is what professionals should do … A good start in this direction will be to convince them of the need for software people to measure their work. Since software work is, as we said, epistemic work, program professionals themselves must take any really precise measures. … Watts Humphrey
It is noteworthy that Watts Humphrey is the father of software quality. After completing his distinguished career at IBM, he became a Fellow of the Software Engineering Institute who founded the Software Process Program. In 2003 he was awarded the National Medal of Technology.
Today WhatsApp was pleased to be SEMAT's work in the academic community. The first full university course based on the new Essence standard was developed and is offered to students this year by Dr. Carlos Zapata of the National University of Colombia in Medellin, Colombia, and Essence is used in the first and second years of software engineering courses at the Royal Institute of Technology KTH in Sweden under the supervision of Dr. Mira Kajo Matson. Fundamental field studies were conducted with students by Dr. Cecil Pearier at Carnegie Mellon West University in the United States. The next step for the SEMAT community is to demonstrate how Essence can help the industry by publishing case studies of actual use and measured results in industrial projects.
[ad_2]&