اشترك بالحزمة الذهبية واحصل على وصول غير محدود شمرا أكاديميا
تسجيل مستخدم جديدA Decision Support System to Choose Optimal Release Cycle Length in Incremental Software Development Environments
112
0
0.0
(
0
)
نشر من قبل
Avnish Chandra Suman
تاريخ النشر
2016
مجال البحث
الهندسة المعلوماتية
والبحث باللغة
English
اسأل ChatGPT حول البحث
ﻻ يوجد ملخص باللغة العربية
In the last few years it has been seen that many software vendors have started delivering projects incrementally with very short release cycles. Best examples of success of this approach has been Ubuntu Operating system that has a 6 months release cycle and popular web browsers such as Google Chrome, Opera, Mozilla Firefox. However there is very little knowledge available to the project managers to validate the chosen release cycle length. We propose a decision support system that helps to validate and estimate release cycle length in the early development phase by assuming that release cycle length is directly affected by three factors, (i) choosing right requirements for current cycle, (ii) estimating proximal time for each requirement, (iii) requirement wise feedback from last iteration based on product reception, model accuracy and failed requirements. We have altered and used the EVOLVE technique proposed by G. Ruhe to select best requirements for current cycle and map it to time domain using UCP (Use Case Points) based estimation and feedback factors. The model has been evaluated on both in-house as well as industry projects.
قيم البحث
اقرأ أيضاً
Context:Software Development Analytics is a research area concerned with providing insights to improve product deliveries and processes. Many types of studies, data sources and mining methods have been used for that purpose. Objective:This systematic
literature review aims at providing an aggregate view of the relevant studies on Software Development Analytics in the past decade (2010-2019), with an emphasis on its application in practical settings. Method:Definition and execution of a search string upon several digital libraries, followed by a quality assessment criteria to identify the most relevant papers. On those, we extracted a set of characteristics (study type, data source, study perspective, development life-cycle activities covered, stakeholders, mining methods, and analytics scope) and classified their impact against a taxonomy. Results:Source code repositories, experimental case studies, and developers are the most common data sources, study types, and stakeholders, respectively. Product and project managers are also often present, but less than expected. Mining methods are evolving rapidly and that is reflected in the long list identified. Descriptive statistics are the most usual method followed by correlation analysis. Being software development an important process in every organization, it was unexpected to find that process mining was present in only one study. Most contributions to the software development life cycle were given in the quality dimension. Time management and costs control were lightly debated. The analysis of security aspects suggests it is an increasing topic of concern for practitioners. Risk management contributions are scarce. Conclusions:There is a wide improvement margin for software development analytics in practice. For instance, mining and analyzing the activities performed by software developers in their actual workbench, the IDE.
There is growing acknowledgement within the software engineering community that a theory of software development is needed to integrate the myriad methodologies that are currently popular, some of which are based on opposing perspectives. We have bee
n developing such a theory for a number of years. In this position paper, we overview our theory along with progress made thus far. We suggest that, once fully developed, this theory, or one similar to it, may be applied to support situated software development, by providing an overarching model within which software initiatives might be categorised and understood. Such understanding would inevitably lead to greater predictability with respect to outcomes.
In finance, leverage is the ratio between assets borrowed from others and ones own assets. A matching situation is present in software: by using free open-source software (FOSS) libraries a developer leverages on other peoples code to multiply the of
fered functionalities with a much smaller own codebase. In finance as in software, leverage magnifies profits when returns from borrowing exceed costs of integration, but it may also magnify losses, in particular in the presence of security vulnerabilities. We aim to understand the level of technical leverage in the FOSS ecosystem and whether it can be a potential source of security vulnerabilities. Also, we introduce two metrics change distance and change direction to capture the amount and the evolution of the dependency on third-party libraries. The application of the proposed metrics on 8494 distinct libra
Industrial standards for developing medical device software provide requirements that conforming devices must meet. A number of reference software architectures have been proposed to develop such software. The ISO/IEC 25010:2011 family of standards p
rovides a comprehensive software product quality model, including characteristics that are highly desirable in medical devices. Furthermore, frameworks like 4+1 Views provide a robust framework to develop the software architecture or high level design for any software, including for medical devices. However, the alignment between industrial standards and reference architectures for medical device software, on one hand, and ISO/IEC 25010:2011 and 4+1 Views, on the other, is not well understood. This paper aims to explore how ISO/IEC 25010:2011 and 4+1 Views are supported by current standards, namely ISO 13485:2016, ISO 14971:2012, IEC 62304:2006 and IEC 62366:2015, and current reference architectures for medical device software. We classified requirements from medical devices standards into qualities from ISO/IEC 25010:2011 and architectural views from 4+1 Views. A systematic literature review (SLR) method was followed to review current references software architectures and a mapping of their support for the identified ISO/IEC 25010:2011 qualities in the previous step was carried out. Our results show that ISO/IEC 25010:2011 qualities like functional suitability, portability, maintainability, usability, security, reliability and compatibility are highly emphasised in medical device standards. Furthermore, we show that current reference architectures only partially support these qualities. This paper can help medical device developers identify focus areas for developing standards-compliant software. A wider study involving under-development medical devices can help improve the accuracy of our findings in the future.
Agile processes are now widely practiced by software engineering (SE) teams, and the agile manifesto claims that agile methods support responding to changes well. However, no study appears to have researched whether this is accurate in reality. Requi
rements changes (RCs) are inevitable in any software development environment, and we wanted to acquire a holistic picture of how RCs occur and are handled in agile SE teams in practice. We also wanted to know whether responding to changes is the only or a main reason for software teams to use agile in their projects. To do this we conducted a mixed-methods research study which comprised of interviews of 10 agile practitioners from New Zealand and Australia, a literature review, and an in-depth survey with the participation of 40 agile practitioners world-wide. Through this study we identified different types of RCs, their origination including reasons for origination, forms, sources, carriers, and events at which they originate, challenging nature, and finally whether agile helps to respond to changes or not. We also found that agile teams seem to be reluctant to accept RCs, and therefore, they use several mitigation strategies. Additionally, as they accept the RCs, they use a variety of techniques to handle them. Furthermore, we found that agile allowing better response to RCs is only a minor reason for practicing agile. Several more important reasons included being able to deliver the product in a shorter period and increasing team productivity. Practitioners stated this improves the agile team environment and thus are the real motivators for teams to practice agile. Finally, we provide a set of practical recommendations that can be used to better handle RCs effectively in agile software development environments.
سجل دخول لتتمكن من نشر تعليقات
التعليقات
جاري جلب التعليقات
سجل دخول لتتمكن من متابعة معايير البحث التي قمت باختيارها
