Papers by Saurabh Dhupkar
International Journal for Research in Applied Science and Engineering Technology
This paper focuses on studying 'Technical Debt' from the perspective of trade-offs between variou... more This paper focuses on studying 'Technical Debt' from the perspective of trade-offs between various system components and Software Quality Attributes, assuming that taking a technical debt is an involuntary action by stakeholders under unavoidable circumstances. For example, instead of considering lack of knowledge as a human factor for Technical Debt, this paper considers that lack of schedule and resources to gain the knowledge is the actual factor. This paper also considers the impact of Technical Debt on Life Expectancy of the software and its various factors.
International Journal of Computer Sciences and Engineering
Requirement gathering is one of the most crucial phases in the software development life cycle an... more Requirement gathering is one of the most crucial phases in the software development life cycle and the change life cycle. Any discrepancy in requirements leads to Technical Debt , has comparatively more impact than other phases of the software development life cycle and has an adverse impact on the software life expectancy. Most of the times, requirements discussed are very superficial that leads to architects and developers assuming so many details. These assumptions mostly end up being discrepancies. Therefore, having precise complete and unambiguous requirements in the initial phase makes the design and development less error prone due to reduced or minimized surprises. Thus, adequate and unambiguous requirements are the key elements of software success. Along with un-ambiguity and completeness, correct prioritization is vital. Incorrect or misleading prioritization results into inaccurate estimation and unmanageable scope. Therefore having a common vocabulary for prioritization along with precise and detailed requirements can help keeping Technical Debt minimized and longer life expectancy of the software. There are many techniques of the requirement gathering. In this paper, this author proposes a method for requirement structuring and prioritization.
International Journal of Modern Trends in Engineering & Research, 2016
This Any software generally goes roughly through following phases in its life 1. Birth 2. Learnin... more This Any software generally goes roughly through following phases in its life 1. Birth 2. Learning 3. Earning 4. Retiring From the business perspective, the software that stays in earning phase for longer time, can roughly be considered as a successful software (well, there can be some exceptions). Keeping this in mind, everyone who works with the software at any point of time in the life of software (irrespective of the role and responsibilities) should focus on working in such a way that software will stay in earning phase as long as possible. Even though we accept the fact that no software can stay in earning phase forever, it can certainly be tried to manage to provide optimum result. Everyone who works with the software at any point of time in any role leaves a mark on the software and contributes to increase or decrease in the overall life expectancy of the software. Therefore, this paper tries to study the software life expectancy, factors affecting it, its relation with different software quality attributes and processes to improve the software life.
International Journal of Computer Sciences and Engineering, May 2019
Requirement gathering is one of the most crucial phases in the software development life cycle an... more Requirement gathering is one of the most crucial phases in the software development life cycle and the change life cycle. Any discrepancy in requirements leads to Technical Debt , has comparatively more impact than other phases of the software development life cycle and has an adverse impact on the software life expectancy. Most of the times, requirements discussed are very superficial that leads to architects and developers assuming so many details. These assumptions mostly end up being discrepancies. Therefore, having precise complete and unambiguous requirements in the initial phase makes the design and development less error prone due to reduced or minimized surprises. Thus, adequate and unambiguous requirements are the key elements of software success. Along with un-ambiguity and completeness, correct prioritization is vital. Incorrect or misleading prioritization results into inaccurate estimation and unmanageable scope. Therefore having a common vocabulary for prioritization along with precise and detailed requirements can help keeping Technical Debt minimized and longer life expectancy of the software. There are many techniques of the requirement gathering. In this paper, this author proposes a method for requirement structuring and prioritization.
This paper focuses on studying 'Technical Debt' from the perspective of trade-offs between variou... more This paper focuses on studying 'Technical Debt' from the perspective of trade-offs between various system components and Software Quality Attributes, assuming that taking a technical debt is an involuntary action by stakeholders under unavoidable circumstances. For example, instead of considering lack of knowledge as a human factor for Technical Debt, this paper considers that lack of schedule and resources to gain the knowledge is the actual factor. This paper also considers the impact of Technical Debt on Life Expectancy of the software and its various factors.
Any software generally goes roughly through following phases in its life 1. Birth 2. Learning 3. ... more Any software generally goes roughly through following phases in its life 1. Birth 2. Learning 3. Earning 4. Retiring From the business perspective, the software that stays in earning phase for longer time, can roughly be considered as a successful software (well, there can be some exceptions). Keeping this in mind, everyone who works with the software at any point of time in the life of software (irrespective of the role and responsibilities) should focus on working in such a way that software will stay in earning phase as long as possible. Even though we accept the fact that no software can stay in earning phase forever, it can certainly be tried to manage to provide optimum result. Everyone who works with the software at any point of time in any role leaves a mark on the software and contributes to increase or decrease in the overall life expectancy of the software. Therefore, this paper tries to study the software life expectancy, factors affecting it, its relation with different software quality attributes and processes to improve the software life.
In this author's opinion, following are the most important software quality attributes - Reliabil... more In this author's opinion, following are the most important software quality attributes - Reliability, Usability, Performance and Availability. As said wisely, "Things that count most, can not be counted mostly." This paper tries to suggest how 'Reliability' can be measured from end user's perspective.
For any software system, end user is the most important actor. Measuring ‘Reliability’ is a way to quantify the usefulness of the software for and end user. Therefore, measuring Reliability from an end user's perspective is very important. Unfortunately, there doesn't seem to be much discussion about how much reliable the software is for end user
There is always an intention behind any task or activity we do in our day to day life. This princ... more There is always an intention behind any task or activity we do in our day to day life. This principle is also applicable behind building as well as using a software system or application. The stakeholders have some of their own intentions to provide certain functionalities through software systems and the users have their own intentions behind using the functionalities. The 'Intent Driven Design' suggests focusing on the intention of both, the stakeholders and the users.
Intent-driven development is an approach that simplifies and standardizes the process of getting detailed technical requirements from non-technical business decision makers so you can develop more complete and consistent requirements as well as design and implement it in such a way that you can keep track of development as well as the usage and also make it more close to end users.
In Software Systems where different types of multiple activities can be performed by users (e.g. ... more In Software Systems where different types of multiple activities can be performed by users (e.g. – ERP), it is generally seen that all the links are dumped on the home page. UI designers have to balance between number of links shown at any page Vs minimum number of clicks to reach any page from any other page. If a novice user comes to access, it becomes difficult for him/her to understand the system. Training becomes crucial and probability of mistakes increases as the software is less than helpful if tried to use without guidance. If a large scale Software System like discussed above, is
designed based on ‘Intentions’ by which users can use them,
it will become a lot of simpler and well-organized
Drafts by Saurabh Dhupkar
Average life of a software is generally about a decade or two. It mostly depends on quite many fa... more Average life of a software is generally about a decade or two. It mostly depends on quite many factors. If we consider just the technical factors that decide the life span of a software, we will realize that absolutely every phase through which a software goes, plays some role in deciding the life span of the software. How good are the requirements identified and understood, how good is the design and architecture, how good it is developed and tested, how well it is monitored and understood during its life, how well the changes are forecasted, designed, planned and implemented to keep the software in line with the current trends and changing requirements and finally how and what knowledge and wisdom is fetched from the software during it's life and retirement phase and how well that is transferred to the new application and many more...
Uploads
Papers by Saurabh Dhupkar
For any software system, end user is the most important actor. Measuring ‘Reliability’ is a way to quantify the usefulness of the software for and end user. Therefore, measuring Reliability from an end user's perspective is very important. Unfortunately, there doesn't seem to be much discussion about how much reliable the software is for end user
Intent-driven development is an approach that simplifies and standardizes the process of getting detailed technical requirements from non-technical business decision makers so you can develop more complete and consistent requirements as well as design and implement it in such a way that you can keep track of development as well as the usage and also make it more close to end users.
designed based on ‘Intentions’ by which users can use them,
it will become a lot of simpler and well-organized
Drafts by Saurabh Dhupkar
For any software system, end user is the most important actor. Measuring ‘Reliability’ is a way to quantify the usefulness of the software for and end user. Therefore, measuring Reliability from an end user's perspective is very important. Unfortunately, there doesn't seem to be much discussion about how much reliable the software is for end user
Intent-driven development is an approach that simplifies and standardizes the process of getting detailed technical requirements from non-technical business decision makers so you can develop more complete and consistent requirements as well as design and implement it in such a way that you can keep track of development as well as the usage and also make it more close to end users.
designed based on ‘Intentions’ by which users can use them,
it will become a lot of simpler and well-organized