Бағдарламалық қамтамасыздаманың маңызы мен түрлері

Кіріспе

Бағдарламалық жасақтаманың жұмыс істеу принципін түсіндіреді. Бағдарламалық жасақтама құжаттамасы – компьютерлік бағдарламалық жасақтамамен бірге келтірілетін немесе бастапқы кодқа енгізілген жазбаша мәтін немесе иллюстрация. Құжаттама бағдарламалық жасақтаманың қалай жұмыс істейтінін немесе оны қалай пайдалануға болатынын түсіндіреді және әртүрлі лауазымдардағы адамдар үшін әртүрлі мағынаға ие болуы мүмкін. Құжаттама – бағдарламалық жасақтама жасаудың маңызды бөлігі. Құжаттама түрлері: Талаптар – Жүйенің қасиеттерін, мүмкіндіктерін, ерекшеліктерін немесе сапаларын анықтайтын мәлімдемелер. Бұл – іске асырылған немесе іске асырылатын нәрселердің негізі. Архитектура/Дизайн – Бағдарламалық жасақтаманың жалпы көрінісі. Бағдарламалық жасақтама компоненттерін жобалау кезінде қолданылатын ортамен және құрылымдық принциптермен байланысты қамтиды. Техникалық – Код, алгоритмдер, интерфейстер және API-лерді құжаттау. Соңғы пайдаланушы – Соңғы пайдаланушыларға, жүйе администраторларына және қолдау қызметкерлеріне арналған нұсқаулықтар. Маркетинг – Өнімді қалай таныстыру және нарық сұранысын талдау.

Талаптар құжаттамасы

Талаптар құжаттамасы – нақты бір бағдарламалық жасақтаманың не істейтінін немесе не істеу керектігін сипаттау. Ол бағдарламалық жасақтаманың қалай жұмыс істейтінін немесе қалай жұмыс істеуге тиісті екенін түсіндіру үшін даму процесінде қолданылады. Сондай-ақ, бағдарламалық жасақтаманың не істейтіні туралы келісімге келуге немесе келісімнің негізі ретінде пайдаланылады. Бағдарламалық жасақтаманы жасауға қатысатын барлық адамдар – соңғы пайдаланушылар, клиенттер, жоба менеджерлері, сату, маркетинг, бағдарламалық жасақтама архитекторлары, пайдаланушылық интерфейс инженерлері, өзара әрекеттесу дизайнерлері, әзірлеушілер және тестілеушілер – талаптарды жасайды және қолданады. Талаптар әртүрлі стильдерде, нотацияларда және формальдылық деңгейлерінде келеді. Олар мақсатқа бағытталған (мысалы, таратылған жұмыс ортасы), жобалауға жақын (мысалы, конфигурация файлына оң жақ батырмамен шертіп және 'құру' функциясын таңдау арқылы құрастыруды бастау) немесе олардың арасында болуы мүмкін. Олар табиғи тілдегі мәлімдемелер, схемалық кескіндер, егжей-тегжейлі математикалық формулалар немесе олардың барлық комбинациясы түрінде берілуі мүмкін. Талаптар құжаттамасының әртүрлілігі мен күрделілігі оны үнемі туындайтын қиындыққа айналдырады. Талаптар жасырын болуы және анықтау қиынға түсуі мүмкін. Қандай көлемде және қандай типтегі құжаттама қажет екенін, ал қаншасын архитектура мен жобалау құжаттамасына қалдыруға болатынын анықтау қиын, сондай-ақ, құжаттаманы оқитын және пайдаланатын адамдардың алуан түрлілігін ескере отырып, талаптарды қалай құжаттауға болатынын білу қиын. Сондықтан, талаптар құжаттамасы көбінесе толық емес (немесе мүлдем болмайды). Дұрыс талаптар құжаттамасы болмаса, бағдарламалық жасақтамаға өзгерістер енгізу қиындайды – демек, қателерге бейім (бағдарламалық жасақтама сапасы төмендейді) және уақытты көп алады (құнға түседі). Талаптар құжаттамасының қажеттілігі әдетте өнімнің күрделілігіне, өнімнің маңыздылығына және бағдарламалық жасақтаманың қызмет ету мерзіміне байланысты. Егер бағдарламалық жасақтама өте күрделі болса немесе көптеген адамдармен әзірленсе (мысалы, ұялы телефон бағдарламалық жасақтамасы), талаптар не істеу керектігін жақсырақ түсінуге көмектеседі. Егер бағдарламалық жасақтама қауіпсіздікке маңызды болса және адам өміріне кері әсер ете алса (мысалы, ядролық энергетика жүйелері, медициналық жабдықтар, механикалық жабдықтар), көбінесе талаптардың формальды құжаттамасы қажет. Егер бағдарламалық жасақтаманың қызмет ету мерзімі бір-екі ай ғана болса (мысалы, нақты бір акция үшін арнайы жасалған өте кішкентай ұялы телефон қосымшалары), талаптарды құжаттау өте аз болуы мүмкін. Егер бағдарламалық жасақтама кейіннен кеңейтілетін алғашқы нұсқа болса, талаптар құжаттамасы бағдарламалық жасақтаманың өзгеруін басқаруда және өзгерістер енгізген кезде ештеңе бұзылмағанын тексеруде өте пайдалы. Әдетте, талаптар талаптар құжаттарында (мысалы, мәтін редакторы мен электрондық кестелерді пайдалану арқылы) көрсетіледі. Талаптар құжаттамасының (және жалпы бағдарламалық жасақтама құжаттамасының) күрделілігі мен өзгергіш сипатын басқару үшін деректер базасына негізделген жүйелер мен арнайы талаптарды басқару құралдары қолданылады. Шапшаң бағдарламалық жасақтаманы әзірлеуде талаптар көбінесе пайдаланушы оқиғалары түрінде, қабылдау критерийлерімен бірге беріледі.

Requirements documentation is the description of what a particular software does or shall do. It is used throughout development to communicate how the software functions or how it is intended to operate. It is also used as an agreement or as the foundation for agreement on what the software will do. Requirements are produced and consumed by everyone involved in the production of software, including: end users, customers, project managers, sales, marketing, software architects, usability engineers, interaction designers, developers, and testers. Requirements come in a variety of styles, notations and formality. Requirements can be goal like (e. g., distributed work environment), close to design (e. g., builds can be started by right clicking a configuration file and selecting the 'build' function), and anything in between. They can be specified as statements in natural language, as drawn figures, as detailed mathematical formulas, or as a combination of them all. The variation and complexity of requirement documentation make it a proven challenge. Requirements may be implicit and hard to uncover. It is difficult to know exactly how much and what kind of documentation is needed and how much can be left to the architecture and design documentation, and it is difficult to know how to document requirements considering the variety of people who shall read and use the documentation. Thus, requirements documentation is often incomplete (or non existent). Without proper requirements documentation, software changes become more difficult — and therefore more error prone (decreased software quality) and time consuming (expensive). The need for requirements documentation is typically related to the complexity of the product, the impact of the product, and the life expectancy of the software. If the software is very complex or developed by many people (e. g., mobile phone software), requirements can help better communicate what to achieve. If the software is safety critical and can have a negative impact on human life (e. g., nuclear power systems, medical equipment, mechanical equipment), more formal requirements documentation is often required. If the software is expected to live for only a month or two (e. g., very small mobile phone applications developed specifically for a certain campaign) very little requirements documentation may be needed. If the software is a first release that is later built upon, requirements documentation is very helpful when managing the change of the software and verifying that nothing has been broken in the software when it is modified. Traditionally, requirements are specified in requirements documents (e. g. using word processing applications and spreadsheet applications). To manage the increased complexity and changing nature of requirements documentation (and software documentation in general), database centric systems and special purpose requirements management tools are advocated. In Agile software development, requirements are often expressed as User Stories with accompanying acceptance criteria.

Техникалық құжаттама

Кодқа қатысты құжаттар (оларға README файлдары мен API құжаттамасы кіруі мүмкін) толық болуы маңызды, бірақ оларды сақтауға тым көп уақыт кетіп немесе күтіп ұстау қиын болғанша, әртүрлі сөздерге толы болмауы керек. API жазушылары құжаттаған бағдарламалық қолданбаға немесе өнімге қатысты түрлі нұсқаулықтар мен шолу материалдарын жиі кездестіруге болады. Бұл құжаттаманы бағдарламашылар, тестілеушілер және соңғы пайдаланушылар қолдана алады. Бүгінде қуат, энергия, көлік, желілер, ғарыш, қауіпсіздік, өнеркәсіптік автоматтандыру және басқа да көптеген салаларда жоғары деңгейдегі қолданбалар кең таралған. Мұндай ұйымдарда техникалық құжаттама маңызды рөл атқарады, себебі архитектура өзгерген кезде ақпараттың негізгі және кеңейтілген деңгейі уақыт өте келе өзгеріп қалуы мүмкін. Жақсы код құжаттамасы бағдарламалық жасақтаманы күтіп ұстау шығындарын төмендетуге көмектеседі деген дәлелдер бар. Код құжаттары көбінесе анықтамалық нұсқаулық түрінде ұйымдастырылады, бұл бағдарламашыға кез келген функцияны немесе классды жылдам табуға мүмкіндік береді.

Түпнұсқалық кодқа енгізілген техникалық құжаттама

Көбінесе Doxygen, NDoc, Visual Expert, Javadoc, JSDoc, EiffelStudio, Sandcastle, ROBODoc, POD, TwinText немесе Universal Report сияқты құралдар код құжаттарын автоматты түрде жасау үшін қолданылады – яғни, олар бастапқы кодтан түсініктемелер мен бағдарламалық шарттарды (болған жағдайда) шығарып, мәтін немесе HTML файлдары түрінде анықтамалық нұсқаулықтарды құрайды. Автоматты түрде құжаттама жасау идеясы бағдарламашыларға түрлі себептермен қызықты. Мысалы, ол бастапқы кодтан тікелей алынғандықтан (мысалы, түсініктемелер арқылы), бағдарламашы кодқа қарап қана жазып, осы кодты жасау үшін қолданылған құралдардың өзін құжаттама жасауға пайдалана алады. Бұл құжаттаманы дер кезінде жаңартуға мүмкіндік береді. Бір мүмкін кемшілігі – мұндай құжаттаманы тек бағдарламашылар ғана өңдей алады және олардың шығысты жаңартуы қажет (мысалы, түнде құжаттарды жаңарту үшін cron жұмысын іске қосу арқылы). Бірқатар мамандар мұны кемшілік емес, артықшылық деп санайды.

Сауатты бағдарламалау

Құрметті компьютер ғалымы Дональд Кнут құжаттаманы кейіннен жасаудың өте қиын процесс екенін айтқан және бастапқы кодпен бір уақытта және бір жерде жазылып, автоматты түрде ізделіп алынатын сауатты бағдарламалауды қолдаушы болған. Haskell және CoffeeScript бағдарламалау тілдері сауатты бағдарламалаудың қарапайым түрін қолдайды, бірақ бұл мүмкіндік кеңінен пайдаланылмайды.

Аңдатқышты бағдарламалау

Элюцидативті бағдарламалау – нақты бағдарламалау ортасында сауатты бағдарламалауты қолданудың нәтижесі. Элюцидативті парадигма кодты және құжаттаманы бөлек сақтауды ұсынады. Бағдарламашылар көбінесе бастапқы файлдың құрамына кірмейтін ақпаратты жасау және оған қол жеткізу қабілетіне ие болуы керек. Мұндай түсіндірмелер кодты қарау және басқа жүйеге көшіру сияқты бағдарламалық жасақтаманы әзірлеудің көптеген кезеңдерінде қолданылады, онда үшінші тараптың коды функционалдық тұрғыдан талданады. Сондықтан, анотациялар ресми құжаттама жүйесі жұмыстың барысын қиындатса, бағдарламашыға бағдарламалық жасақтаманы әзірлеудің кез келген кезеңінде көмектесе алады.

Пайдаланушы құжаттамасы

Кодтық құжаттардан өзгеше, пайдаланушы құжаттары бағдарламаның қалай қолданылатынын ғана сипаттайды. Бағдарламалық кітапхана жағдайында кодтық және пайдаланушы құжаттары кейбір жағдайларда тиімді түрде бірдей болуы мүмкін және біріктіруге лайық, бірақ жалпы қолданба үшін мұндай жағдай сирек кездеседі. Әдетте, пайдаланушы құжаттамасы бағдарламаның әрбір мүмкіндігін сипаттайды және пайдаланушыға осы мүмкіндіктерді пайдалануға көмектеседі. Пайдаланушы құжаттарының түсініксіз болмауы және уақтылы жаңартылуы өте маңызды. Пайдаланушы құжаттарын арнайы тәртіппен ұйымдастыру міндетті емес, бірақ толыққанды мазмұндамасы болуы аса қажет. Тұрақтылық пен қарапайымдық та жоғары бағаланады. Пайдаланушы құжаттамасы бағдарламалық жасақтаманың қандай міндеттерді орындайтынын көрсететін келісімшарт ретінде қарастырылады. API жазушылары жақсы пайдаланушы құжаттарын жазуға өте қабілетті, себебі олар бағдарламалық жасақтама архитектурасымен және қолданылатын бағдарламалау техникаларымен жақсы таныс. Қосымша, техникалық жазуға да назар аударыңыз. Пайдаланушы құжаттамасын түрлі онлайн және баспа форматында жасауға болады. Дегенмен, пайдаланушы құжаттамасын ұйымдастырудың үш негізгі тәсілі бар. Оқулық: Жаңа пайдаланушы үшін ең тиімдісі – оқулық тәсілі, онда олар нақты тапсырмаларды орындаудың әрбір қадамын орындау бойынша жетекшілік алады. Тақырыптық: Тараулар немесе бөлімдер нақты бір қызығушылық тақырыбына шоғырланған тақырыптық тәсіл орта деңгейдегі пайдаланушылар үшін көбірек пайдалы. Кейбір авторлар өз ойларын білімдік мақалалар арқылы жеткізуді жөн көреді, осылайша пайдаланушының қажеттіліктерін қанағаттандырады. Мұндай тәсіл көбінесе ақпараттық технологиялар сияқты динамикалық салаларда қолданылады. Тізім немесе анықтамалық: Ұйымдастыру принципінің үшінші түрі – командалар немесе тапсырмалардың әліпби бойынша немесе логикалық топтарға бөлініп тізімделуі, көбінесе сілтемелік мазмұндамалар арқылы. Бұл тәсіл ақпаратты қалай іздеу керектігін білетін тәжірибелі пайдаланушылар үшін тиімді. Пайдаланушылардың бағдарламалық қамтамасыз ету құжаттамасына қатысты жиі айтатын шағымы – үш тәсілдің тек біреуі қолданылып, қалған екеуі толығымен ескерілмегендігі. Жеке компьютерлерге арналған бағдарламалық қамтамасыз ету құжаттамасын көбінесе командалар немесе мәзір элементтері туралы анықтамалық ақпаратты ұсынатын онлайн көмекке дейін шектеуге болады. Жаңа пайдаланушыларды оқыту және тәжірибелі пайдаланушыларға бағдарламадан толыққанды пайда алуға көмектесу жұмысы жеке баспагерлерге жүктеледі, оларға бағдарламалық жасақтаманы жасаушылар көбінесе айтарлықтай көмек көрсетеді.

Unlike code documents, user documents simply describe how a program is used. In the case of a software library, the code documents and user documents could in some cases be effectively equivalent and worth conjoining, but for a general application this is not often true. Typically, the user documentation describes each feature of the program, and assists the user in realizing these features. It is very important for user documents to not be confusing, and for them to be up to date. User documents do not need to be organized in any particular way, but it is very important for them to have a thorough index. Consistency and simplicity are also very valuable. User documentation is considered to constitute a contract specifying what the software will do. API Writers are very well accomplished towards writing good user documents as they would be well aware of the software architecture and programming techniques used. See also technical writing. User documentation can be produced in a variety of online and print formats. However, there are three broad ways in which user documentation can be organized. Tutorial: A tutorial approach is considered the most useful for a new user, in which they are guided through each step of accomplishing particular tasks. Thematic: A thematic approach, where chapters or sections concentrate on one particular area of interest, is of more general use to an intermediate user. Some authors prefer to convey their ideas through a knowledge based article to facilitate the user needs. This approach is usually practiced by a dynamic industry, such as Information technology. List or Reference: The final type of organizing principle is one in which commands or tasks are simply listed alphabetically or logically grouped, often via cross referenced indexes. This latter approach is of greater use to advanced users who know exactly what sort of information they are looking for. A common complaint among users regarding software documentation is that only one of these three approaches was taken to the near exclusion of the other two. It is common to limit provided software documentation for personal computers to online help that gives only reference information on commands or menu items. The job of tutoring new users or helping more experienced users get the most out of a program is left to private publishers, who are often given significant assistance by the software developer.

Пайдаланушы құжаттамасын құрастыру

Техникалық құжаттаманың басқа түрлері сияқты, жақсы пайдаланушы құжаттамасы да ұйымдастырылған әзірлеу процесінен үлкен пайда көреді. Пайдаланушы құжаттамасы жағдайында, өнеркәсіпте кең таралған процесс бес қадамнан тұрады:

Пайдаланушыны талдау, процестің негізгі зерттеу кезеңі. Жоспарлау, немесе құжаттаманы жасау кезеңі. Жобаны қарау – бұл бұрынғы қадамда дайындалған жобаға пікір алу кезеңі. Пайдалану ыңғайлылығын тексеру, осы арқылы құжаттың қолдануға ыңғайлылығы тәжірибелік жолмен тексеріледі. Редакциялау – үшінші және төртінші қадамдарда жиналған ақпаратты пайдаланып, соңғы нұсқаны дайындау үшін жасалатын соңғы қадам.

Сату құжаттамасы

Көптеген қолданбалар үшін өнім туралы көбірек білуге кездейсоқ көрермендерді ынталандыру үшін жарнамалық материалдар қажет. Осы құжаттаманың үш мақсаты бар:

* Әлеуетті пайдаланушыны өнімге қызықтырып, оған қатысуға ықыласын ояту.
* Өнімнің қандай қызмет атқаратынын түсіндіріп, олардың күтулері алған өнімдерімен сәйкес болуын қамтамасыз ету.
* Бұл өнімнің басқа баламалармен салыстырғандағы орнын анықтау.

Құжаттамалық және жедел даму даулары

"Бағдарламашылардың құжаттамаға қарсылығы жақсы белгілі және оны арнайы атап көрсетудің қажеті жоқ". Бұл жағдай әсіресе шапшаң бағдарламалық жасақтаманы әзірлеуде жиі кездеседі, себебі бұл әдістемелер тікелей пайда келтірмейтін артық әрекеттерден қашуға тырысады. Атап айтқанда, Agile манифесі "толыққанды құжаттамадан гөрі жұмыс істейтін бағдарламалық жасақтаманы бағалауды" жақтайды, бұл кейде циникалық тұрғыдан "Біздің барлық уақытымыз код жазуға кетсін. Есіңізде болсын, шынайы бағдарламашылар құжаттама жазбайды" деп түсіндіріледі. Дегенмен, бағдарламалық инженерия сарапшылары арасында жүргізілген сауалнама шапшаң дамуда құжаттаманың мүлдем қажетсіз емес екенін көрсетті. Бірақ дамуда мотивациялық мәселелер бар екені және шапшаң дамуға бейімделген құжаттама әдістері қажет болуы мүмкін екені мойындалады (мысалы, бедел жүйелері және геймификация арқылы).