دانلود رایگان مقاله استفاده از محدودیت های معماری برای به دست آوردن مجدد اجزا نرم افزار

چکیده

        ما سیستم های یکپارچه نرم افزار و سخت افزاری قطعات با طول عمر اعم از 10-15 سال را توسعه می دهیم. در طول عمر این سیستم ها، نیازهای بازار به طور قابل توجهی با توجه به پیشرفت های تکنولوژیکی، نیازهای زیست محیطی، و اولویتهای فرهنگی تغییر کرده است. هزینه تغییر نرم افزار و سخت افزار یک محرک بسیار بزرگ است که اغلب منجر به معرفی تغییری می شود که در نتیجه منجر به معرفی تغییر در نرم افزار برای روبه رو شدن با تکامل انتظارات بازار خواهد شد. بزرگترین مزیت نرم افزار-، سازگاری آسان – است و همچنین بزرگترین نقطه ضعف آن، متعد بودن برای تغییر است. از این رو، طراحی نرم افزار به ویژه در توسعه نرم افزار در سطح جهانی (GDSD) بسیار چالش برانگیز است. در این مقاله تمرینی، ما رویکردمان را از اعمال نفوذ محدودیت های معماری نرم افزار و چالش مواجه شده به همراه درس های آموخته شده را به اشتراک میگذاریم، استفاده مجدد نرم افزار در هنگام اضافه کردن و بهبود ویژگی ها هم باعث کاهش هزینه های کلی و هم باعث کاهش زمان برای رسیدن محصول به بازار برای یک تیم گسترش نرم افزار توزیع شده خواهد بود.

1. سابقه

        سیستم های یکپارچه ای که ما به طور مستمر در حال توسعه آن ها هستیم در حال فشرده سازی نرم افزار بیشتر هستند، در حالی که در گذشته آنها فشرده تر بود. علاوه بر این، پس از چند سال، سیستم ما در حال تحول است و همچنین در حال رشد در هر دو بعد اندازه و پیچیدگی می باشد. 

         بنابراین معماری نرم افزار نقش رهبر را بازی می کند و آن را تبدیل به یک محصول مرکزی در چرخه زندگی سیستم های ما می نماید، چرا که آنها یک مرور کلی از سازمان و از این سیستم ها برای ارائه به ذینفعان مختلف را انجام می دهند. معماری نرم افزار به صورت زیر تعریف شده است  "مجموعه ای از ساختارهای یک سیستم نرم افزاری، که برای استدلال در مورد آن ... لازم است (و) از بخش های نرم افزاری تشکیل شده است و همچنین به صورت روابط میان آنها و خواص این اشخاص و روابط"  تعریف شده است[1]. معماری نرم افزار باعث می شود تا هر دو اجزای یک سیستم نرم افزاری و وابستگی بین این اجزا به صورت صریح باشد [2]. در سال 1990 اصطلاح "معماری نرم افزار" شروع به جلب توجه قابل توجهی هم از جامعه پژوهش و از صنعت نمود [3]. چالش ایجاد ارزیابی و حفظ این سیستم بزرگ تا حد زیادی باعث تحریک و رشد در زمینه معماری شده است. اهمیت معماری نرم افزار برای سیستم های نرم افزاری بزرگ و پیچیده را می توان با دلایل زیر توضیح داد[4]:

• ارتباطات متقابل: اکثر ذینفعان سیستم ها می توانند از معماری نرم افزار به عنوان پایه برای درک سیستم، به صورت اجماع، و برقراری ارتباط با یکدیگر استفاده کنند.

• تصمیم گیری اولیه طراحی: معماری نرم افزار اولین مصنوعی است که اولویت ها را در میان نگرانی های رقیب برای تجزیه و تحلیل قادر می سازد. چنین نگرانی هایی شامل مبادلات بین جنبه های عملکردی و غیر عملکردی مانند عملکرد، امنیت، نگهداری و اصلاح است. نگرانی های رقابتی اضافی را می توان هزینه توسعه در حال حاضر در مقابل هزینه های آینده نگهداری و یا تکمیل کاربردی و یا مبادلات بین جنبه های فنی و غیر فنی مانند بازار و یا بودجه در نظر گرفت.

• انتزاع قابل انتقال از یک سیستم: مدل معماری نرم افزار انتقال در سراسر سیستم قابل انتقال است. به طور خاص، می توان آن را به سیستم های مشابه دیگر اعمال نیز اعمال نمود و استفاده مجدد از آن ها در مقیاس بزرگ را ترویج داد. 

         در حالی که سیستم های نرم افزاری در حال تحول هستند، تصمیم گیری ها و اصول معماری نیز در پی آن ها دنبال شوند و گسترش پیدا کنند. تغییر تصمیم گیری معماری دشوار است و نیاز به یک تجزیه و تحلیل و تاثیر دقیق و در نظر گرفتن دلایل تغییرات گذشته دارد. بنابراین مستندسازی تصمیمات معماری از جمله استدلال برای تصمیم گیری یک فعالیت مهم در فرآیندهای توسعه نرم افزار [5] بسیار مهم است. محدودیت های معماری در میان مهمترین توصیفات هستند و در میان اسناد مهم تصمیم گیری هستند. [7] 

         محدودیت معماری نشان دهنده مشخصات یک حالتی است که یک معمار باید به منظور جلب رضایت یک تصمیم در مورد  آن بگیرد. بنابراین محدودیت معماری نقش مهمی در تصمیم گیری های طراحی و اعتبار سازی معماری بازی می کند. هنگام طراحی معماری نرم افزار، تصمیمات و محدودیت نیازها به اهداف کسب و کار متصل می شود. تصمیم گیری های طراحی اغلب به دلایل غیر فنی گرفته شده اند: نگرانی استراتژیک کسب و کار، رویارویی با محدودیت های هزینه و برنامه، استفاده از پرسنل موجود، و غیره [8].

2. مقدمه

        به طور معمول طول عمر سیستم های یکپارچه ما در محدوده  10-15 سال است. در طول عمر خود یک سیستم از چهار مرحله مختلف (1) مقدمه (2) رشد، (3) بلوغ، و (4) کاهش عبور خواهد کرد.

        نیازهای بازار برای سیستم های یکپارچه در حال تغییر قابل توجهی به دلیل پیشرفت های زیست محیطی، فرهنگی، و فن آوری است. هزینه تغییر یک سیستم یکپارچه بستگی به مرحله چرخه عمر آن دارد.  فاز رشد برای محصولات ما مهم و چالش برانگیز است و  دو دلیل دارد: 1) این محصول در حضور رقابت تشدید باید با نیاز بازار پیش برود و ویژگی های یک محصول جدید نیز به آن اضافه شود. 2) محصول تحت یک انتقال با توجه به جریان زیاد نیاز به این محصول مورد نیاز است. 

          ما بر روی پلت فرم خط تولید کار میکنیم که در فاز رشد و توسعه یافته در سراسر 3 قاره (اروپا، آسیا، و شمال امریکا) کار می کنند. ما با ارائه برنامه های متعدد بر اساس این پلتفرم می پردازیم و به طور مداوم دامنه خط تولید را گسترش می دهیم. از این رو مهم است که یک ساختار در محل که به عنوان یک راهنما برای اضافه کردن ویژگی های جدید برای تمام تیم ها در سراسر جغرافیا داشته باشیم.

         در بخش بعدی ما جزئیات چنین ساختاری را همراه با چالش هایی که ما با آن مواجه شده ایم  و درس هایی که آموختیم را ارائه می کنیم.

Abstract

       we develop integrated systems that consist of software and hardware components with a lifespan ranging from 10-15 years. During the life span of these systems, market needs change significantly due to technological advancements, environmental needs, and cultural preferences. Cost of change of software vis-àvis hardware is a big driver which often leads to the introduction of change to software for meeting evolving market expectations. The biggest advantage of software-‘easy adaptability’-is also its biggest drawback, because it makes software susceptible to change. Hence, designing software is extremely challenging specially in Globally Distributed Software Development (GDSD). In this practice paper, we share our approach of leveraging the constraints of software architecture, the challenges encountered and lessons learnt which enabled higher software reuse when adding and enhancing features while reducing overall costs and shrinking time to market for a Globally Distributed Software Development team.

I. BACKGROUND

       The integrated systems we develop are continually becoming more software intensive, whereas in the past they were more hardware intensive. Furthermore, since several years, our systems have been evolving while growing both in size and complexity.

        Software architecture therefore plays a leading role and it has become a central artifact in the life cycle of our systems, because they provide the various stakeholders with an overview of the organization of these systems. Software architecture is dened as “the set of structures of a software system, necessary for reasoning about it…(and) is composed of software entities, the relations between them as well as properties of these entities and relations” [1]. Software architecture makes both the components of a software system and the dependencies between these components explicit [2]. By the year 1990 the term “software architecture” began to attract substantial attention both from the research community and from the industry [3]. The challenges to create evaluate and maintain these huge systems have greatly stimulated the growth of the field of architecture. The importance of software architecture for large and complex software systems can be explained by the following reasons [4].

• Mutual communications: Most systems stakeholders can use software architecture as a basis to understand the system, form consensus, and communicate with each other.

• Early design decisions: Software architecture is the earliest artifact that enables the priorities among competing concerns to be analyzed. Such concerns include tradeoffs between functional and nonfunctional aspects such as performance, security, maintainability, and modifiability. Additional competing concerns can be cost of current development vs. future maintenance costs or functional completeness or tradeoffs between technical and nontechnical aspects such as time to market or budget.

• Transferable abstraction of a system: The model of software architecture is transferable across systems. In particular, it can be applied to other similar systems and promote large scale reuse.

          While software systems are evolving, architecture decisions and principles need to be followed. Changing architecture decisions is difficult and it requires a careful impact analysis taking the reasons for past changes into account.. Therefore documenting architecture decisions including the reasoning for the decisions is an important activity in software development processes [5]. Architecture constraints are among the most important descriptions encountered in the documentation of an architecture decision. [7]

          An architecture constraint represents the specication of a condition which an architecture description must adhere to in order to satisfy an architectural decision. Therefore architecture constraints play an important role in design decisions and architecture validation. When designing software architecture, the decisions and constraints need to be connected to business goals. Design decisions are often made for non-technical reasons: strategic business concerns, meeting the constraints of cost and schedule, using available personnel, and so forth [8]

II. INTRODUCTION

       Typically the lifespan of our integrated systems ranges from 10-15 years. During its life span a system passes through four different phases (1) Introduction, (2) Growth, (3) Maturity, and (4) Decline.

        Market needs for integrated systems are changing significantly due to environmental, cultural, and technological advancements. The cost of change of an integrated system depends on the lifecycle phase it is in. The growth phase for our products is critical and challenging for two reasons: 1) the product has to differentiate itself in the presence of intensified competition that along with market requirements guide which features need to be added to a product, 2) the product undergoes a transition due to large inflow of requirements.

          We work on a product line platform which is in growth phase and developed across 3 continents (Europe, Asia, and North America). We provide multiple applications based on this platform and are continuously extending the scope of the product line. Hence it is important to have a structure in place which will act as a guideline for adding new features for all teams across the geographies.

         In the subsequent sections we will detail such a structure along with challenges we faced and the lessons we learnt.

چکیده

1. سابقه

2. مقدمه

3. چهار رکن

A. مهندسی مورد نیاز

B. تجزیه و تحلیل نوع

C. تصمیمات کلیدی معماری و مبادلات

D. طرح استفاده مجدد از اجزاء نرم افزار

4. چالش ها

5. درس های یاد گرفته شده

منابع

Abstract

1. BACKGROUND

2. INTRODUCTION

3. THE FOUR PILLARS

A. Requirement Engineering:

B. Variant analysis

C. Key architecture decisions and tradeoffs

D. Software component reuse plan

4. CHALLENGES

5. LESSONS LEARNT

REFERENCES