Software engineering, in the developer's hand?

Last updated May 5, 2024 Published Dec 7, 2015

The content here is under the Attribution 4.0 International (CC BY 4.0) license

If you’re a programmer, analyst or something related to IT (Information Technology) you probably already have heard about software engineering. What is that? What can engineering do for software? A great part of people who heard “engineering” thought about numbers, equations, formulas and crazy people. Therefore software engineering is about practices, and techniques to build great software with quality, and security. maintainability and so on.

Software engineering is the study and application of engineering** to the design, development and maintenance of software [1]. Software engineering is the study and application of engineering to the design, development and maintenance of software [2]. Software engineering (SE) is concerned with developing and maintaining software systems that behave reliably and efficiently, are affordable to develop and maintain, and satisfy all the requirements that customers have defined for them.

Inside of Software engineering, we have a couple of subjects Requirements Engineering 3, software design, configuration management, tests, deployment management, and architecture to name a few. Modeling also is a subject of software development and is where UML comes up [4]. Since I started my software engineering degree I’ve been thinking about how we can make software development painless, I found two amazing topics: planning and Modeling.

Use case diagram

A use case diagram is one of the UML diagrams used to help understand scenarios of the software, this diagram has the main purpose of exposing the user’s point of view.

Above we can see the simplest use case possible. On the left side, we have an actor that can represent a regular user or even another system and on the right side, we have the use case, in other words, what the actor does. Our first step is to get into the software rules and in the minds of our users (it is a good deal, isn’t it?).

It is not just about images

Going further with the use case diagram we can document each use case. Here I present a standard document to use thus you can adapt it to satisfy your needs.

Use case name	Do something
Actor	Actor
Resume	An actor should do something when he is asked for
Pre-condition	The actor should be registered
Main-flow	Actor click on the button to do something System shows up a popup with the response, it is possible to go to alternative-flow 1 if something goes wrong System close the popup and close the window
Alternative-flow	1) Display an error message
Post-condition	The actor should have done at least one thing

The problem with this approach is time. Below we have a graph comparing creating a diagram before code and not creating a diagram.

As we can see it takes longer but as you can imagine the quality grows. Why should we start to draw or plan before doing code?

It improves quality
It improves maintenance
It makes it easy to integrate a new member into the code base
As time goes it’s cheaper to maintain the source code

This is not to say that we don’t need any planning at all, but extensive planning is expensive and rarely reflects what will happen in reality.

Start to think then act

The conclusion here is don’t wait for someone to do the right thing in your project. Here we have an example of how to use a simple UML diagram for our project and start to think about software engineering and everything made by a developer. As a regular developer, we always want to get our hands dirty but if you want to step up in your career stop doing and start thinking. We have thousands of sites that try to explain why software fails to be successful

The most common are bad management, lack of knowledge about the business, stakeholders not interested, lack of time, pressure and so on. But let’s have a look at Dr. Paul Dorsey’s paper he has more to tell us about it.

If a bunch of electricians, plumbers, carpenters and contractors meet in a field, talk for a few hours and then start building, the building will be unstable if it ever gets built at all. At one of my presentations, an audience member shared the quip that “If building engineers built buildings with the same care as software engineers build systems, the first woodpecker to come along would be the end of civilization as we know it” (Dr. Paul Dorsey). Indeed it’s true, in the IT industry, as usual, project managers or any member of the management team think that is like manufacturing to build software, just like adding one more on the team if the deadline is close and then making it on time, Unfortunately, it is not. Another good point he gave to us is about developers who just got interested in programming or related subjects.