چکیده
ما تجربه خودمان را در استفاده مجدد موثر نرم افزار در تیم مهندسی که با استفاده از یک روش توسعه ناب در سطح جهانی به اشتراک گذاشته ایم. این مقاله به تشریح طرح کلی مراحل کار، با شروع از شناخت پتانسیل برای استفاده مجدد، اقدامات انجام شده برای فعال کردن استفاده مجدد نظام در پروژه ها، با چالش های مواجه شده، و اقدامات اصلاحی انجام شده برای اطمینان از اثر استفاده مجدد سیستماتیک، می پردازد. دروس اصلی به دست آمده عبارتند از: ) شناسایی حوزه مربوطه برای استفاده مجدد، II) مسئولیت های صریح اختصاص یافته برای توسعه کامپوننت های استفاده مجدد، III) تهیه زیرساخت های موثر، IV) تعریف فرآیندهای دقیق تر توسعه نرم افزار برای استفاده مجدد قطعات ، و V) ایجاد یک تیم متمرکز برای اجزای توسعه استفاده مجدد. نتایج حاصل از طرح استفاده مجدد موفق ما از جمله افزایش قابل توجه در کیفیت و استفاده مجدد از 12 درصد از کل کد توسعه داده شده، ارائه شده است.
1.مقدمه
ما تجربه خودمان را در استفاده مجدد موثر نرم افزار در تیم مهندسی که از 1000 مهندس در آمریکای شمالی، اروپا و آسیا، به اشتراک گذاشته ایم.
2. پیش زمینه
سازمان ما محصولات در یک صنعت بسیار کنترل شده را توسعه می دهد. ما در حال توسعه سخت افزار، نرم افزار و سیستم عامل به عنوان محصول برای خانواده های مختلف هستیم. با توجه به ماهیت این صنعت، این محصولات دارای چرخه حیات طولانی هستند و انتظار می رود که به طور مشخص برای چند دهه به کار روند. علاوه بر این، محصولات باید الزامات قانونی را که مستلزم انطباق با استانداردهای صنعت هستند را نیز داشته باشند. از این رو، برای محصولات ما، کیفیت غیر قابل مذاکره است.
برای اطمینان از تحویل به موقع، این تیم بر روش توسعه نرم افزار ناب تکیه کرده است [1،2]. این تیم بیش از 10 سال مسئله ای را که با توسعه نرم افزار جهانی [3،4] ارائه شده بود را خطاب کرده بود (طرح کرده بود).
3. رویکرد اولیه برای استفاده مجدد نرم افزار
پتانسیل استفاده مجدد نرم افزار در سازمان ما بلافاصله زمانی به رسمیت شناخته شد که ما توسعه نرم افزار را آغاز نمودیم. در آن زمان، استفاده مجدد صرفا با کپی کردن قطعات منبع از یک پروژه به دیگری، بدون فرآیند حاکم به دست می آمد. ما به زودی شاهد یک افزایش سریع در تلاش برای تعمیر و نگهداری و رشد ناسازگاری بین محصولات خواهیم بود. متوجه شدیم که ما نیاز به یک رویکرد سیستماتیک برای سازماندهی استفاده مجدد هستیم [5].
پس از آن، راه هایی برای بهره برداری از پتانسیل استفاده مجدد نرم افزار بررسی شد و رویکرد مدیریتی با اهداف زیر ارائه شد: 1) کاهش زمان و هزینه های توسعه با استفاده مجدد قطعات موجود، 2) اطمینان حاصل کردن برای کامپوننت هایی با رفتار یکسان و نگاه و ظاهر مشابه، و 3) افزایش کیفیت توسط استفاده مجدد و سیستماتیک اجزای نرم افزار.
A. حوزه مرتبط برای استفاده مجدد
با در نظر گرفتن تفاوت های استفاده مجدد در حوزه های فنی مختلف، ما دامنه های استفاده مجدد مربوطی که با توسعه فن آوری های و سیستم عامل های کالا همراستا و مرتبط بودند را شناسایی کرده ایم. این موارد در جدول I لیست شده اند. رویکرد ما شناسایی حوزه های مختلف و تجزیه و تحلیل دامنه ها می باشد [6] در حالی که عملی دور از فرمالیسم بودن وجود خواهد داشت.
B. سازمان برای استفاده مجدد
برای هر یک از از دامنه های مربوط به پروژه و برای وظایف استفاده مجدد - برای، ما اعضای تیم های پروژه های مختلف، که نقش دوگانه قرار گرفته اند را شناسایی کرده ایم. ما همچنین دو نقش جدید را تعریف کردیم: صاحبان دامنه معماران و یا کارشناسان موضوع. صاحبان دامنه معمولا معمار و یا کارشناسان موضوع هستند که انتظار می رود استفاده مجدد در دامنه ی خود را مد نظر داشته باشند. آن ها برای دامنه ی خود مسوول موارد زیر هستند: 1) ارزیابی پیشنهادات برای هر دو اجزاء قابل استفاده مجدد جدید و پیشرفت های قابل توجهی در قطعات موجود، 2) تعریف یک نقشه راه استفاده مجدد، و 3) معماری اجزاء قابل استفاده مجدد. از سوی دیگر، صاحبان اجزا مسئول موارد زیر نیز هستند: 1) طراحی، 2) اجرا، 3) تست، 4) انتشار، و 5) نگهداری از جزء استفاده مجدد (شکل 1 را ببینید).
C. بودجه، و حصول اطمینان از استفاده مجدد
بودجه تمام فعالیت های پروژه ها بر اساس نیاز تامین شده است (شکل 1). علاوه بر این، برای اطمینان از پشتیبانی برای استفاده مجدد، تیم معمار یک هدف به منظور کاهش هزینه را از طریق استفاده مجدد از نرم افزار ارائه داده است. علاوه بر این، آن یک درک نانوشته است که کل سازمان به صاحبان دامنه و صاحبان اجزا را در دستیابی به اهداف استفاده مجدد حمایت می کرد.
D. فعال کردن زیرساخت ها و فرایندهای به منظور تسهیل استفاده مجدد
برای حمایت از استفاده مجدد نرم افزار سیستماتیک، ما در زیرساخت ها سرمایه گذاری کردیم: 1) مدیریت پیکربندی و ردیابی نقص اجزاء قابل استفاده مجدد، و 2) پورتال وب برای به اشتراک گذاشتن اطلاعات مربوط به استفاده مجدد از قطعات، و به برجسته کردن مزایای طرح استفاده مجدد
1) مدیریت پیکربندی، مدیریت انتشار و ردیابی نقص: ما در مدیریت پیکربندی، مدیریت انتشار و ردیابی نقص اجزاء قابل استفاده مجدد را با سیستم های مربوطه تراز بندی نمودیم. این اجازه اجرای پروژه های مختلف که شامل اجزاء قابل استفاده مجدد مانند هر یک از اجزای دیگر پروژه است را می دهد. علاوه بر این، دست زدن به نقص برای اهداف استفاده مجدد تنظیم شده بود، به طوری که تمام پروژه ها می توانستند نقص در اجزاء قابل استفاده مجدد را گزارش دهند و همچنین آن ها را ردیابی نمایند.
Abstract
we share our experience in pursuing effective software reuse in a globally distributed software engineering team that uses a lean development methodology. The paper outlines the journey, starting from recognizing the potential for reuse, the steps taken to enable systematic reuse in lean projects, the challenges faced, and the corrective actions taken to ensure effectiveness of systematic reuse. The main lessons learned include: i) identification of relevant domains for reuse, ii) explicitly assigning responsibilities for reuse component development, iii) providing enabling infrastructure, iv) defining more rigorous software development processes for reuse components, and v) establishing a centralized team for developing reuse components. The results of our successful reuse initiative including the significant increase in quality and a 12 percent reuse of total code developed have been presented.
I. INTRODUCTION
We share our experience in pursuing effective software reuse in a globally distributed software engineering team consisting of about 1,000 engineers distributed across locations in North America, Europe, and Asia.
II. BACKGROUND
Our organization develops products in a highly regulated industry. We are involved in developing hardware, software, and firmware for multiple product families. Due to the nature of the industry, these products have long lifecycles and are expected to perform as specified for several decades. In addition, the products must fulfill regulatory requirements that entail conforming to industry standards. Hence, for our products, quality is non-negotiable.
To ensure on-time delivery of high-quality software, the team had switched to lean software development methodology [1,2]. The team had been operating for over 10 years and had addressed the issues encountered in global software development [3,4].
III. INITIAL APPROACH FOR SOFTWARE REUSE
The potential of software reuse within our organization was immediately recognized when we started software development. At that time, reuse was achieved by merely copying source parts from one project into another without any governing process. We soon observed a rapid increase in maintenance effort and growing incompatibility between products. We realized that we required a systematic approach to organize reuse [5]. Subsequently, we explored ways to harness the potential of software reuse and proposed an approach to the management with the following objectives: 1) reducing development time and costs by reusing existing components, 2) ensuring components with the same functionality have identical behavior and look and feel, and 3) increasing quality by systematic reuse of software components.
Our approach focused on four main areas: A) relevant domains for reuse, B) organizing for reuse, C) funding, and ensuring reuse, and D) enabling infrastructure and processes to facilitate reuse.
A. Relevant domains for reuse
In view of the differences of handling reuse in the different technical areas, we identified relevant reuse domains that were aligned with the development technologies and product platforms. These are listed in Table I. Our approach to identifying domains shares the objectives of domain analysis [6] while being pragmatic without the rigor of formalism.
B. Organizing for reuse
For each reuse domain, we identified members of the different project teams, who were assigned dual roles – one for project related tasks and another for reuse component related tasks. We also defined two new roles: domain owner and component owner. Domain owners are typically architects or subject matter experts who are expected to drive reuse in their domain. For their domain, they are responsible for: 1) assessing proposals for both new reuse components and significant enhancements in existing components, 2) defining a reuse roadmap, and 3) the architecture of the reuse components. On the other hand, component owners are responsible for: 1) design, 2) implementation, 3) testing, 4) release, and 5) maintenance of the reuse component (see Fig. 1).
C. Funding, and ensuring reuse
All activities were funded by the projects on a need basis (see Fig. 1). Further, to ensure support for reuse, the architect team was given a target to reduce costs explicitly through reuse of software. In addition, it was an unwritten understanding that the entire development organization would support the domain owners and the component owners in achieving the goals of reuse.
D. Enabling infrastructure and processes to facilitate reuse
To support systematic software reuse, we invested in enabling infrastructure: 1) configuration management and defect tracking of the reuse components, and 2) web portal to share information related to reuse components, and to highlight the benefits of the reuse initiative.
1) Configuration management, release management, and defect tracking: We aligned the configuration management, release management, and defect tracking of the reuse components with the respective systems in the projects. This allowed different projects to include the reuse components like any other project component. In addition, defect handling was adjusted for reuse purposes, so that all projects could report and track the defects in reuse components.
چکیده
1. مقدمه
2. پیش زمینه
3. رویکرد اولیه برای استفاده مجدد نرم افزار
A. حوزه مرتبط برای استفاده مجدد
B. سازمان برای استفاده مجدد
C. بودجه، و حصول اطمینان از استفاده مجدد
D. فعال کردن زیرساخت ها و فرایندهای به منظور تسهیل استفاده مجدد
4. تجارب و مسائل با رویکرد اولیه
A. اولویت بندی
B. بایاس ویژگی
C. کیفیت
D. ارتباطات
E. بودجه
5. تجزیه و تحلیل مسائل
A. مسئولیت دوگانه
B. اجرای فرآیندها
C. تنها نقطه تماس
D. بی میلی در بودجه پایگاه کد استفاده مجدد
6. روش تغییر
A. ایجاد یک پروژه استفاده مجدد متمرکز
B. بودجه
C. فرایندها برای توسعه کامپوننت های استفاده مجدد
7. نتایج و تاثیر
A. فرهنگ در حال تحول استفاده مجدد
B. دستیابی به کیفیت، تحویل و اهداف هزینه
8. نتیجه گیری
منابع
Abstract
1. INTRODUCTION
2. BACKGROUND
3. INITIAL APPROACH FOR SOFTWARE REUSE
A. Relevant domains for reuse
B. Organizing for reuse
C. Funding, and ensuring reuse
D. Enabling infrastructure and processes to facilitate reuse
4. EXPERIENCES AND ISSUES WITH THE INITIAL APPROACH
A. Prioritization
B. Feature bias
C. Quality
D. Communication
E. Funding
5. ANALYZING THE ISSUES
A. Dual Responsibility
B. Enforcement of processes
C. Single point of contact
D. Reluctance in funding reused code base
6. CHANGED APPROACH
A. Creation of a centraized reuse project
B. Funding
C. Processes for reuse component development
7. RESULTS AND IMAPCT
A. An evolving culture of reuse
B. Achieveing quality, delivery, and cost goals
8.CONCLUSIONS
REFERENCES