Rabu, 13 November 2013
When writing program code in the context of a comprehensive project, which is estimated to be over the size of 10.000 LOC (lines of code), frequently a process Software Development Process manifests as shown in Figure 1.
The process shown is greatly simplified compared to the full ITIL Software Development Life Cycle recommendation. Additionally the software developer will likely not be burdened with the larger context of project management, which for instance includes project planning and project maintenance, but will rather focus on the project from a developer's perspective.
For smaller projects such as a simple plugin, the process that comes most naturally is actually an agile one (not shown).
Software Development Process:
The development process generally begins with an idea, such as the wishes of a client. These are gradually carved out and put into tangible goals, with the ulterior objectives being laid out in a specification sheet. Complex goals which are not an integral part of the project and/or goals that may not be feasible in a given budget or time-frame should be dropped and put aside for possible future improvements. Otherwise the project would likely incur unreasonable financial risk.
The better defined the project specification the more solid the base concept becomes, and the more accurate the overall project's performance can be measured towards full-filling the targeted objectives or minimum requirements.
Code Design is a critical stage. In the worst case, developers may need to completely rewind at this point, admit made mistakes and may even have to start anew from scratch, upon admitting and assuring themselves that a fresh start would be the best way forward. Here is an example scenario: Say you dear reader, are a software developer about to implement a complicated algorithm along with a suitable user interface. You re-search the web in an onset of lingering frustration, only to find an already similar and well-maintained open source project, with years of experience behind it, multiple contributors and a suitable licence for your own project. In other words, the stern realization is that by learning to adopt to adapt all project goals would be satisfied. This happens to me once in a while. There is an upside to such an code-scratching predicament though: It shows the overall changes in software culture towards sharing and caring.
In Figure 1, the connections in the figure are bolder the more a given path will be traveled. The clocks indicate a time consuming process. Stop signs indicate a stage where a code review is in order.
At some point the software will be almost ready for release, undergo a final testing phase, and ideally entailing a final code review . The final stage can however be radically different, for instance when the testing happens in co-dependence with the client, upon mutual agreement. The client's terms may not permit you natural access to its software infrastructure or even a virtual machine image thereof.
As for unit testing in general, a colleague once told me, implement unit testing as long as the project benefits from it. This may not always be the case. When toying around with code-ideas, for instance unit-testing at such an early stage may be a hindrance. Unit testing is highly beneficial in large projects with multiple contributors, coming in at later project stages.
Finally the choice of using a good framework is a pricey one. It takes motivation and time to master it. However a good framework will implement loose coupling of components, making life as a developer much easier.
Illustrations Note: All current and future illustrations herein can be downloaded as svg, and graphml in this github repository. To correct or improve the graphics, fork and edit them accordingly, then make a pull request, so that I can included the improvements for other's to always have the most up-to-date graphics from the master repository.
The process shown is greatly simplified compared to the full ITIL Software Development Life Cycle recommendation. Additionally the software developer will likely not be burdened with the larger context of project management, which for instance includes project planning and project maintenance, but will rather focus on the project from a developer's perspective.
For smaller projects such as a simple plugin, the process that comes most naturally is actually an agile one (not shown).
 |
| Fig 1: Shown is a frequently used software development process. licence: CC-BY-SA 3, author: Lorenz Lo Sauer, 2013 |
Software Development Process:
The development process generally begins with an idea, such as the wishes of a client. These are gradually carved out and put into tangible goals, with the ulterior objectives being laid out in a specification sheet. Complex goals which are not an integral part of the project and/or goals that may not be feasible in a given budget or time-frame should be dropped and put aside for possible future improvements. Otherwise the project would likely incur unreasonable financial risk.
The better defined the project specification the more solid the base concept becomes, and the more accurate the overall project's performance can be measured towards full-filling the targeted objectives or minimum requirements.
Code Design is a critical stage. In the worst case, developers may need to completely rewind at this point, admit made mistakes and may even have to start anew from scratch, upon admitting and assuring themselves that a fresh start would be the best way forward. Here is an example scenario: Say you dear reader, are a software developer about to implement a complicated algorithm along with a suitable user interface. You re-search the web in an onset of lingering frustration, only to find an already similar and well-maintained open source project, with years of experience behind it, multiple contributors and a suitable licence for your own project. In other words, the stern realization is that by learning to adopt to adapt all project goals would be satisfied. This happens to me once in a while. There is an upside to such an code-scratching predicament though: It shows the overall changes in software culture towards sharing and caring.
In Figure 1, the connections in the figure are bolder the more a given path will be traveled. The clocks indicate a time consuming process. Stop signs indicate a stage where a code review is in order.
At some point the software will be almost ready for release, undergo a final testing phase, and ideally entailing a final code review . The final stage can however be radically different, for instance when the testing happens in co-dependence with the client, upon mutual agreement. The client's terms may not permit you natural access to its software infrastructure or even a virtual machine image thereof.
As for unit testing in general, a colleague once told me, implement unit testing as long as the project benefits from it. This may not always be the case. When toying around with code-ideas, for instance unit-testing at such an early stage may be a hindrance. Unit testing is highly beneficial in large projects with multiple contributors, coming in at later project stages.
Finally the choice of using a good framework is a pricey one. It takes motivation and time to master it. However a good framework will implement loose coupling of components, making life as a developer much easier.
Illustrations Note: All current and future illustrations herein can be downloaded as svg, and graphml in this github repository. To correct or improve the graphics, fork and edit them accordingly, then make a pull request, so that I can included the improvements for other's to always have the most up-to-date graphics from the master repository.