In my development experience I have seen lots of development projects struggle with problems during the middle or end of development phase.They would not have a focus as to what should be done to resolve. This
occurs either due to the lack of knowledge, experience and expertise in the technology of the resources. The resources
either after the code is developed and the required functionalities are fixed
don’t put any efforts to re factor the code and the focus would be to fix defects and move the code to production.The reasons for this may be many stringent time lines, lack of knowledge of resources or resources are already burned out, to name a few.This causes issues in next coming
releases. It may even happen that in the next releases other than the scope of
the current releases the development team would be busy fixing defects
occurring due to code which was developed in the previous releases. This just
doesn't waste time and effort but also cost and the quality, affects the focus
required in the current release. As a result the development team may skip
deadlines and may have contractual obligations along with loosing reputation
with the client which will affect future deals also.
The methodology here describes a process to stabilize the code by
creating frameworks. The advantage of this methodology is better code quality,
code re usability and code maintainability. There will be no duplicate codes and
the application which will be developed is a loosely coupled application. As
there will be focus on frameworks the developers don’t have to change too much
of code. The lesser the code, less defects and obvious the more code is written
the more chances of getting defects.
The advantage of the methodology is that it can be used
along with any software development methodologies. It can be used after the
release of the project as in figure 1 or during the release as in figure 2.
figure 1
figure 2
The methodology is only applicable and only beneficially
only after the project development is done for a module or the application. Another
advantage of the methodology is that there won’t be too much of
documentation or process for the development team to follow as a result the
development team will be able to focus completely on development of a high quality
software end product.
The methodology is as follows:-
The methodology has 4
phases.
Phase 1:- Identification
Phase 2:- Implementation and Deployment
Phase 3:-Testing
Phase 4:- Closure
The following tasks will be performed in the Identification
Phase
1.
Identifying the duplicate codes and documenting
the duplicate codes.
The developer will identify the duplicate codes in the code
base. The developer may or may not document the duplicate codes. The documentation would be mandatory if the
code base is huge or else depends on the management to decide if the
documentation is required.
figure 3
2.
Implementation of the frameworks, Re-factoring,
Unit testing and Deployment
The following tasks will be performed in the Implementation and
deployment phase
Design a framework
The developer will come up a suitable framework with the
effective design patterns implemented.
The focus will be to see make the maximum use of the code and keeping
the point in mind that the existing functionality should be achieved using the
least lines of code. The framework which serves the purpose with least number
of lines of code would be considered for implementation.
The designed framework would also be implemented with the
performance factor in mind.
Implement the framework.
In the implementation phase the framework
would be implemented and the required unit testing and functional testing would
be done. The implementation would be aggressive and the required functional testing
would be done. The bugs if any would be fixed till the existing functionality is
working as expected.
Once all the functionalities are working as
expected then the next task would be to do code changes for performance
tuning if required. The framework would
be performance friendly, code re-used, maintainable and flexible.
Re-factor any other code or algorithm.
Once the framework is implemented then the
developer will check if any other algorithm or code re-factoring is required. If
any the developer feels any other code re-factoring is required then the
developer will do the necessary fix.
For example: A for loop may be doing
additional iterations even after the required matching key word is found or the
functionality is achieved. The developer can put a return once the key word match is found and the functionality is achieved.
These kind of small re-factoring which were
missed out in the implementation and which would make a difference in the performance
would be implemented.
Deploy the application
The deployment of the application would be
done in the respective environments. So that it can be handed over to the
testing team for further testing.
figure
4
3.
Testing
Once all the phases are done the application would be handed
over to the testing team for testing. The testing team would focus only on
functional testing and any defects found would be noted in a excel spread sheet
or share point or any other means of defect management.
Any noticeable performance issue would also be reported.
The defect sheet would be shared across to the development
teams and development manager.
The following tasks will be performed iterative after the
testing
1.
Test
2.
Document the defects
3.
Defect Fix
The developers will fix all the high priority defects and
then move towards medium and low priority defects. This process will be iterative
till the code is found to be stable and all high and medium priority defects
are fixed. The developers are expected to fix at least 10 defects a day as this would be aggressive and makes sure the defect fix is faster.
figure 5
4.
Closure
The following tasks will be performed during the Closure.
Document the frameworks and the implementation details.
All the changes will be clearly documented including the
framework details and other re-factoring details in a structured document format.
The same will be transferred to other developers or maintenance teams and
required knowledge transfer would be done subsequently.
The whole process can be performed iterative till the code
becomes stable. The number of lines of code versus the number of defects will be the measure on which the
benefit/ quality factor will be calculated. Here it is assumed The number of lines of code versus the no of defects is
directly proportional to the quality of the code achieved or benefits achieved.
The code quality will be measured in the form of a graph with the number of lines
of code versus no of defects before and after the release/ Iteration. The number of functionality versus lines of code will be used in the
report to showcase the benefit obtained from the releases.
figure 6
The whole process represented as a diagram.
figure 7
No comments:
Post a Comment