Recently I have been working on a project that I hope will be accepted as an independent case study and also eventually develop into a full fledged product. While I have been working on this project I've been constantly thinking to myself that I want to develop this in the best way possible. As a software engineer I know that there is much more to software than just code and that it is important to take those other things into consideration as well. From my internships at various companies I have seen the pit falls that many software projects can fall into without careful design and process to follow the project. In an attempt to develop my own process I hit a few road blocks.
There are three main types of process that I am aware of, mainly the waterfall, iterative, and ad hoc processes. Generally as a lone developer the ad hoc process is the most accepted. Since there is a single developer there is little to no dependencies on communicating the intentions of various code elements. I originally considered this approach, but I want to eventually develop this project into a product. So I need this project to be scalable, from just me working on it, to eventually a team of people working on it. Also, since the waterfall process is very spartan and I have very little idea of the path the project will take from start to finish, I'm choosing not to use this process.
This leaves me with one choice, an iterative approach to process. This works simply, because in my project and generally in any object oriented project, there is a clear distinction between the parts of the project. That means I can decide on the requirements, design, develop, and test a small portion of the system without worrying too much about how it will connect with the other pieces. Then I can repeat the process for each subsequent part and add on to what I have already built.
One of my biggest struggles with this initially, though, was that it was hard for me to decide on the requirements. I have some domain knowledge on what my project is intended for, but not enough to be able to lay out the specifics of exactly what the requirements for each of the various parts would be.
Prototyping, specifically operational prototyping, has become a necessity in my development process. Operational prototyping is a combination of throw away and functional prototyping. It uses throw away prototyping to help define requirements that are not well understood in the system. Once these throw away prototypes help define the requirements, functional prototyping is used to build a functional base to mirror those requirements. The functional base eventually becomes part of the system. I find this very helpful because it gives me a way to determine requirements that I don't fully understand and allows me to also build a fully functional system at the same time.
Some concerns I have for the future are how I am going to handle the integration of separate subsystem of the system. I still have not decided if I should build the system in layers, gradually adding on each new component, or if I should develop each part separately and then integrate them. Whichever method I do, I will also have to find a way establish the requirements for the relations between the subsystems, because there will be no easy way to prototype them.
There are three main types of process that I am aware of, mainly the waterfall, iterative, and ad hoc processes. Generally as a lone developer the ad hoc process is the most accepted. Since there is a single developer there is little to no dependencies on communicating the intentions of various code elements. I originally considered this approach, but I want to eventually develop this project into a product. So I need this project to be scalable, from just me working on it, to eventually a team of people working on it. Also, since the waterfall process is very spartan and I have very little idea of the path the project will take from start to finish, I'm choosing not to use this process.
This leaves me with one choice, an iterative approach to process. This works simply, because in my project and generally in any object oriented project, there is a clear distinction between the parts of the project. That means I can decide on the requirements, design, develop, and test a small portion of the system without worrying too much about how it will connect with the other pieces. Then I can repeat the process for each subsequent part and add on to what I have already built.
One of my biggest struggles with this initially, though, was that it was hard for me to decide on the requirements. I have some domain knowledge on what my project is intended for, but not enough to be able to lay out the specifics of exactly what the requirements for each of the various parts would be.
Prototyping, specifically operational prototyping, has become a necessity in my development process. Operational prototyping is a combination of throw away and functional prototyping. It uses throw away prototyping to help define requirements that are not well understood in the system. Once these throw away prototypes help define the requirements, functional prototyping is used to build a functional base to mirror those requirements. The functional base eventually becomes part of the system. I find this very helpful because it gives me a way to determine requirements that I don't fully understand and allows me to also build a fully functional system at the same time.
Some concerns I have for the future are how I am going to handle the integration of separate subsystem of the system. I still have not decided if I should build the system in layers, gradually adding on each new component, or if I should develop each part separately and then integrate them. Whichever method I do, I will also have to find a way establish the requirements for the relations between the subsystems, because there will be no easy way to prototype them.
Posts
