Software engineering, in the developer's hand ?
If you're a programmer, analyst or something related to I.T (Information Technology) you probably already have heard about software engineering. What is that ? What can engineering do for software ? Great part of people who heard "engineering" thought about numbers, equations, formulas and crazy people. Therefore software engineering is about practices, techniques to build a great software with quality, security. maintainability and so on.
Software engineering is the study and an application of engineering to the design, development and maintenance of software. (Webopedia)
Software engineering is the study and an application of engineering to the design, development and maintenance of software. (Wikipedia)
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. (Computing Degrees & Careers)
Inside of Software engineering we have a couple of subjects Requirements engineering, software design, configuration management, tests, deployment management, architecture to name a few. Modeling also is a subject of software development and is where UML comes up.
Since I started my software engineering degree I've been thinking in how we can make the software development painless, I found two amazing topics : Planing and Modeling.
Use case diagram
Use case diagram is one of the UML diagrams used to help to understand scenarios of the software, this diagram has a main purpose to expose the user point of view.
Above we can see the simplest use case possible. On left side we have an actor that can represents a regular user or even another system and in the right side we have the use case, in other words what the actor does.
Our first step to get into the software rules and in the mind of our users (it is a good deal, isn't it ?)
It is not just about images
Going further with use case diagram we can document each of use case. Here I present a standard document to use thus you can adapt it to satisfy your need
|Use case name||Do something|
|Resume||An actor should do something when he is asked for|
|Pre-condition||The actor should be registered|
|Alternative-flow||1) Display a message within error|
|Post-condition||The actor should have done at least one thing|
The problem with this approch is time. Above we have a graph comparing between creating a diagram before code and not create a diagram
As we can see it takes longer but as you can imagine the quality grows. Why should we start to draw or planing before do code ?
- It improves quality
- It improves maintenance
- It makes easy to integrate a new member to the code base
- As the time goes its cheaper to maitain the source code
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 a example in how to use a simple UML diagram to our project and start to thing in 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 who try to explain why software fails being successful
The most commons are bad management, lack of knowlegde about the business, stakeholders not interested, lack of time, pressure and so on. But let's have a look at Dr. Paul Dorsey paper he has more to tells us about it.