There are many levels to the software development process. The process defines many parts of the development cycle. There are a few stages that occur when software is being developed. The basics of the stages can be broken down into three basic questions that should be asked by the primary developers: what, when, and how (Fayad, 101).
Developers need to answer the basic questions when developing software to make sure that the software is going to meet the needs of the clients. The what satisfies the basics of what a project does. The project or software has to serve a set purpose. It is up to the developers to make sure that the software behaves as intended.
The when is answered by a timeline for the project. There needs to be a guideline when creating the project that shows the steps that are going to be completed with the project. These steps include dates and times, maybe sometimes even landmarks, that show specific goals of the project. These include the development cycle and the testing and production work of the project.
The how is the actual backend implementation of the project. How are the tasks going to be completed, are there going to need to be additional plug-ins or features added by subsequent projects or already established projects? Are the goals going to be able to be satisfied by the software programming tools that are already in place?
The manager is responsible for making sure that the project is answering each of these basic three questions. Does the project complete the tasks that it is supposed to be able to complete? Is the project meeting each of its landmarks on time? Is the project able to be designed however is possible to create a working project? The manager will assure these goals are being met my using metrics that are measurable. The manager needs to make sure that the process indicators are being met and that the performance of individuals on the project are meeting their individual goals.
Documentation is the most valuable part of the software development process that can help managers and team members stay on track when developing software. It is also still one of the most overlooked and neglected parts of software development. Some people assume that documentation gets in the way of programming, or hinders creativity. Some others think that by using a process based development cycle the project will take on an assembly line type approach that will take out the rest of the creativity involved when programming.
Documentation will help take your software development process to a new level of productivity. Documentation will help keep your software transparent, so that stakeholders can look into the project at all times and be reassured that goals are being reached. Proper documentation helps developers find and solve bugs, and takes the guesswork out of problems that other developers might have already solved.
Processes in software development help breakdown each part of the development cycle into easy understandable parts. This makes the software development cycle much smoother. Using smaller processes might make it seem as though you are breaking things into an assembly line, but the design team and others will still have their own processes to inject creativity into the project. In fact, when starting a project, the beginning will be set aside for making sure the overall design and feel of the project are on par with what the basic questions are that are being asked to be solved by the software. This makes the backend programming part of the project easier as they do not have to focus on such details and hopefully can program without having unexpected features added in at a later time.
Software development processes help make sure that a software project remains on task and completes all of its goals. It makes sure that the projects meet and answer all of the basic questions that were the reason why the project was started in the first place. Documentation helps keep the development cycle moving along by helping with expansion or troubleshooting. This process do not suck the creativity out of a project, but instead creates a flexible guideline that helps a project succeed.
Solving Common Cases of Failure
Software development takes time and flows through many cycles. Over these cycles, many different programmers read and modify the code within the program. These individuals may not know certain parts of the program that they are even modifying. They might only be trying to fix crippling bugs. These changes could affect another part of the program that will go unnoticed because they are not actively testing the other section. This is why software development is set up for failure. It doesn’t have to be. The software development cycle can go through processes designed to help keep the cycle on task and meeting its goals.
There are many horror stories about computer glitches or bugs ruining a system. There is a very funny movie called Office Space from the nineteen-nineties about a group of employees who introduce their own glitch into a software payroll system. Away from the big screen, this could be a major issue. With so many hands in the development cycle, processes can be used to help standardized the programming procedures.
Since software is becoming more and more common across industries, systems being designed are becoming more and more streamlined. Hardware and software alike are becoming more similar each year. This is good for programmers and consumers alike. The downside to this is that there are greater amounts of devices in use with a slimmer margin for error. If a piece of software does not execute as expected, negative reviews will follow and consumers will not purchase the software. To a greater extent, security becomes a focal point. With a large number of devices in use, personal data is at great risk for damage or malicious use. This has been seen with the amount of data breeches over recent years. Large corporations that use faulty software have been the target of security breeches. This makes software failure a very expensive problem.
There are many reasons that software projects fail. Most of these can be solved with an aggressive software development process plan. The reason that these projects fail is because they do not have clearly defined goals. Stakeholders do not clearly articulate the goals to the programmers or the programmers interpret things slightly different from one another. Due to this these to projects come in with bad designs. There could be a shortened timeline which means that the programmers take short cuts making the development sloppy. There can also be a problem regarding poor communication with all parties involved (Charette, 45).
These are all problems that be solved with an aggressive software development process. The first thing that needs to be created is a plan. The plan should be based off of the requirement needed for the project. It should answer the basic questions: what, when, and how. Once the plan is in place, the design of the overall project can begin. This can include designers or developers, based on the company, that help turn the plan into a workable piece of software based on the goals of the stakeholders. These goals should also be included in the plan so that all parties are on the same page. Documentation should be written outlining the basics of the project and giving a guideline to future programmers who may be brought in. The programming then begins so that the project can begin to be implemented. This is the start of a solid process that helps prevent failure.
By having all parties work closely together, the level of failure is lowered because everyone is aware of what is at stake. The plan is created to help solve all problems ahead of time and give a realistic timeline for the project. One of the biggest problems I have seen in the field, is the incorrect assumption on the time that it should take to complete a task. By having everyone involved, the schedule can be correctly implemented giving everyone ample amounts of time to complete their tasks. Once all of the tasks have been completed, individuals can begin testing the project to make sure that all of the features are implemented. Once they verify everything is up to code, they can release the project. Proper documentation at the beginning is a big life saver once a project moves from its initial release to maintenance mode. The proper documentation helps programmers solve unexpected bugs as well, as each variable and its use can be documented for example.
Using a tight software development process, such as the one defined here, can help a project be delivered on time and under budget. Without proper planning and documentation it is hard to keep a project going, which can lead to project failure. A proper process with frequent check-ins can help prevent these unfortunate failures.
Prescriptive Process Models
When developing software, it is best to follow a model to keep a project moving and meeting its goals. It helps when preparing a project to make sure that it is developed in a way that is easy to benchmark and can be tested regularly. By using a prescribe process, one can define the way a piece of software interacts with the different steps to a complete programming project. These processes help with efficiency and are control oriented. One of these models is the waterfall model.
The waterfall model is a model that is based on an order of separate processes. These processes occur in order which helps when preparing or designing a project. These processes cannot occur without each other, and fall in an order that helps further refine what the previous process accomplished.
The first step of the waterfall process is the communication step. This occurs when the leaders of the project or the stakeholders want to define the processes for the project. They first have to define the goals of the project and list out an outline which should be the basis of the first documentation. This communication step also gets all of the programmers and other key individuals on board with each of their goals defined. Once the project has been communicated to all involved parties, the next step begins.
The next step of the waterfall process is planning. This is when the documentation of that project begins to take its complete form. The plan should be in written form, incase a programmer leaves or joins in the middle of the project. The plan needs to be a complete plan so that the development process is not being thrown together after the project is started.
After the plan has been created, the next step of the project is modeling. The modeling should include a design of the finished program so that it can be analyzed for design flaws. This is the last step of initial design review before the creation or the programming of the final product. The modeling can be created with any design and can also be included inside of the documentation.
After the model is created, the construction of the finished project begins. The construction includes the actually writing of the code for the project. Once the program is created, the testing of the project begins. The code will also have to be rewritten so that it works correctly.
Once the code has been thoroughly tested, the deployment of the final project begins. The final project needs to be deployed in a way that guarantees successfully delivery. The project has to be able to be used by the consumer. Once the consumer receives the project, they need to have support on hand. It also helps if there is a way to give feedback for modifications and fixes.
The waterfall model is great because it allows for a strict development cycle that enforces correct procedures. Each phase builds off of the last phase and continues when the other ends. This allows for less lost time as everything needs to be in place before the next part begins. This means there is also no wasted manpower because programmers are not sitting around waiting for other departments to make planning decisions.
A downside to the waterfall model is that everything needs to be planned out before the actual programming begins. If a company does not have an exact plan on what the program does, the program can never get to the design phase. Also, once the program gets to the design phase, if programmers are not involved designs can include things that are not feasibly created.
The waterfall method is a great prescribe process because it allows for everything to be planned out before the beginning of the actual programming. This means that the programming will have direction when it is created. This can sometimes lead to projects never leaving the design phase, but it will cut down on the wasted costs of buggy programs.
- Fayad, M. E. (1997). Software Development Process: A Necessary Evil. Communications of the ACM, vol 40 no 9, pages 101–103.
- Charette, R. N. (2005). Why Software Fails. IEEE Spectrum, September 2005, 42–49.