The goal of this post is to discuss a simple software development process model. Hmmm let’s see. A simple software development process. There are many software development process models.
And
I will be discussing the difference between agile processes and waterfall Process….
Naaaah! Not that old crap. Yeah I know agile/iterative is good and waterfall is baaaaaaad.
We all know that nobody is using waterfall process model anymore. Indeed, no one is using any process model at all. Everyone is using the natural software development process model.
And that is you got the task and you have to write code. This is the natural model. There could be exceptions-maybe large organizations use process model- but they are EXECPTIONS.
The only place I have used software development process is in my university class and that was for completing my assignment. Writing the pros and cons of different software process models was a task during my undergrad studies.
So what is the point of writing this article?
Well, let me admit one thing. There are a few good things that I have adopted from all the process models that I have studied.
I have applied these things personally in my projects and yes they are helpful. They are helpful if you are having a very small team. Or you are developing a software just by yourself.
These things will aid you in programming. Help you understand the benefits of object oriented design.
This will help you when you are sitting in an interview sharing your practical experiences of applying good software development life cycle practices in front of your interviewer.
There you will not sound like a fresh graduate who has studied process model in their class only.
So,
What is a simple process?
I will lay out a process that will focus object oriented design.
Here are the steps:
1)Requirements, 2) Design, 3) code ,4) test ,5) deliver
Pretty much like the BAD WATERFALL process model. Well, pretty much every process model has these steps. What makes them distinct — The Best Practices. Every process model has these steps and a set of best practices.
Rational Unified Process(RUP) model has different best practices. One best practice is that it does not consider above steps as something separate. In each iteration, all things are done in different proportion.
During the initial iterations of RUP, we do a lot of requirement gathering, some designing, a little bit of coding, a little bit of testing and so on.
At the end of RUP, we do a lot of coding and testing and a little bit of requirements gathering and designing.
Similarly, Extreme Programming process methodology offers some unique best practices which are a different than SCRUM.
Haaaah. It looks like I am writing my university assignment. But I believe you got the point.
So I will share 1 or two best practices for each step with respect to object-oriented analysis and design.
Why object-oriented analysis and design. Well, the obvious reason is that top programming languages in use are object-oriented programming languages.
But let me explain one key benefit OOP with respect to process model:
Overlapping of Real World and Engineering World
Object-oriented analysis and design(OOAD) methodology will provide a platform where you can connect the engineering world with the real world.
This is like programming the real world scenarios in a way that anybody would describe them using their own language. For example, consider the following code listing:
aUser = MyGame.RegisterUser() aUser.Play(); aUser.CheckIfWinOrLose(); MyGame.GiveReward(); MyGame.UregisterUser();
This is the source code of a simple game. This is how anyone would describe how a game would be played in plain English. I have compiled a free report that shows a real life and detail example here.
Using OOAD you can design your code right from the description of real world scenarios.
Now, let’s move to the first step of simple software development process model.
Requirements Gathering
As you know object oriented technology bridge the gap between real life and programming world.
So, when developing a software you will have to start from the real life and then ease into the programming world.
The best way to describe our real world is using stories. There are stories all around us. Hence the best way to gather requirements is to get stories from users about their problems.
There is an advanced form or more detailed form of a story and that is called use cases. Use-case is like a novel. Here you have to define roles and their interaction.
Now, from the text of stories, you have to bring out names of the classes. Mostly nouns will be the name of the classes.
Design
Now from user stories you have got classes. Currently, they are just names. You don’t know what they do. How to they interact and how will you write code for them.
In addition to that, not everything is in the user story. There are things which are implied. Or your user may have used other names for that. For example, your user may have said I want to store the record and have some reports.
You know what the user is talking about. The user is talking about the database. So you will have to include classes related to that functionality.
O.k. Next step in designing is the interaction of classes. You know, in reality, classes don’t exist. Only objects exist. They exist in a secret place called RAM.
So the next step is to define the interaction of these objects. Questions like who will have what information. Who will create this object? How will all of these objects work together to fulfill one user story?
You can design this interaction yourself or you can look up to the good practices of old developers. These good practices are called design patterns.
Do I follow all this?
Hmmm, NOPES. Not all things. Sometimes I just start writing code. Sometimes I just bring out the code from my personal repository or from some other project and start developing from there.
The idea is simple– follow as much as you can. There is no restriction. Software design is mostly heuristic. It all depends upon you and you get better by designing more and more.
Construction
The only part that matters. This should consume the major part of your development effort.
The construction or coding is not a linear activity. It’s not like after the development of design you just have to code it and then run it.
This is the part where you have to think. Think a lot. Solve a lot of problems. Learn a lot. And the outcome is a beautiful software.
One suggestion is design for testability. Write a code module in a way that is easier to test.
I am not going to beat the drum about “TEST FIRST DEVELOPMENT”. But writing you code in this manner will help you in debugging. Which is an integral part of software development 🙂
Testing
This could be a professional level testing. White box and black box and [insert any sophisticated term here].
This could be a functional test with a customer. Or a performance test. Or a UI/UX test. Or a deployment test.
After development, testing and deployment are the two most effort consuming activities.
Deliver and Repeat
Iterative development is one attribute of software development. Each iteration main focus point should be a user story. Each iteration should complete one user story. And test that with the end user and then move onto the next story.
That is the whole point for which the waterfall model is frowned upon. In waterfall, there was no way that one can find out if they are on the right track. There was no customer integration within the development process.
Each iteration also gives you the opportunity to refine and improve your object oriented design. In initial iterations, you can focus on providing the functionality(or use GRASP). In later iterations, you can refine your object oriented design by refactoring and utilizing design patterns.
So what process do you follow in your organization? Is there any critical step that you think should be part of this simple process[please don’t tell me to include documentation– I hate it ].
Write them in comments or email me.
nice one