Ანოტაცია: პროგრამული უზრუნველყოფის განვითარების პროცესის კონცეფცია. უნივერსალური პროცესი. მიმდინარე პროცესი. კონკრეტული პროცესი. სტანდარტული პროცესი. პროცესის გაუმჯობესება. გაყვანის/დაძაბვის სტრატეგიები. კლასიკური პროცესის მოდელები: ჩანჩქერის მოდელი, სპირალური მოდელი. ფაზები და აქტივობები.
ამ მოდელის უპირატესობა ის არის, რომ ის ზღუდავს თვითნებური ნაბიჯის უკან დაბრუნების შესაძლებლობას, მაგალითად, ტესტირებიდან ანალიზამდე, შემუშავებიდან მოთხოვნებზე მუშაობამდე და ა.შ. აღინიშნა, რომ ასეთმა დაბრუნებამ შეიძლება კატასტროფულად გაზარდოს პროექტის ღირებულება და მისი დასრულების დრო. მაგალითად, თუ ტესტირების დროს აღმოჩენილია დიზაინის ან ანალიზის შეცდომები, მათი გამოსწორება ხშირად იწვევს სისტემის სრულ რედიზაინს. ეს მოდელი საშუალებას აძლევდა დაბრუნებას მხოლოდ წინა საფეხურზე, მაგალითად, ტესტირებიდან კოდირებამდე; პროგრამული უზრუნველყოფიდან ეს მოდელი აქტიურად გააკრიტიკეს შესაბამისი სტატიებისა და სახელმძღვანელოების თითქმის ყველა ავტორის მიერ. საყოველთაოდ მიღებული აზრი გახდა, რომ ის არ ასახავს პროგრამული უზრუნველყოფის განვითარების მახასიათებლებს. ჩანჩქერის მოდელის უარყოფითი მხარეა:
- ფაზებისა და აქტივობების იდენტიფიცირება, რაც იწვევს განვითარების მოქნილობის დაკარგვას, კერძოდ, განმეორებითი განვითარების პროცესის მხარდაჭერის სირთულეებს;
- აქტივობის ფაზის სრული დასრულების მოთხოვნა, შედეგების კონსოლიდაცია დეტალური წყაროს დოკუმენტის სახით (ტექნიკური დავალება, საპროექტო სპეციფიკაცია); თუმცა, პროგრამული უზრუნველყოფის დამუშავების გამოცდილება აჩვენებს, რომ შეუძლებელია მოთხოვნების სრულად დასრულება, სისტემის დიზაინი და ა.შ. - ეს ყველაფერი ექვემდებარება ცვლილებას; და ამის მიზეზი არ არის მხოლოდ ის, რომ საპროექტო გარემო არის თხევადი, არამედ ის, რომ ბევრი გადაწყვეტილების ზუსტად განსაზღვრა და წინასწარ ჩამოყალიბება შეუძლებელია, ისინი მხოლოდ მოგვიანებით ირკვევა და დაზუსტდება;
- განვითარების ყველა შედეგის ინტეგრირება ხდება ბოლოს, რის შედეგადაც ინტეგრაციის პრობლემები თავს ძალიან გვიან იგრძნობს;
- მომხმარებლები და მომხმარებელი ვერ გაეცნონ სისტემის ვარიანტებს განვითარების პროცესში და შედეგს მხოლოდ ბოლოს ხედავენ; ამრიგად, მათ არ შეუძლიათ გავლენა მოახდინონ სისტემის შექმნის პროცესზე და, შესაბამისად, იზრდება დეველოპერებსა და მომხმარებლებს/მომხმარებელს შორის გაუგებრობის რისკები;
- მოდელი არასტაბილურია პროექტების დაფინანსების ან სახსრების გადანაწილების წარუმატებლობის მიმართ; დაწყებულ განვითარებას, ფაქტობრივად, ალტერნატივა არ აქვს „გზაში“.
თუმცა, ეს მოდელი კვლავაც გამოიყენება პრაქტიკაში - მცირე პროექტებისთვის ან სტანდარტული სისტემების შემუშავებაში, სადაც განმეორება არც ისე მოთხოვნადია. მისი დახმარებით მოსახერხებელია განვითარების თვალყურის დევნება და პროექტზე ეტაპობრივი კონტროლის განხორციელება. ეს მოდელი ასევე ხშირად გამოიყენება ოფშორულ პროექტებში 1 ინგლისური ოფშორიდან - ნაპირის გარეთ, გაფართოებული ინტერპრეტაციით - ერთი ქვეყნის გარეთ.საათობრივი ანაზღაურებით. ჩანჩქერის მოდელი ჩართული იქნა სხვა მოდელებსა და მეთოდოლოგიაში, როგორიცაა MSF.
სპირალური მოდელიშემოთავაზებული იყო Barry Boehm-ის მიერ 1988 წელს ჩანჩქერის მოდელის ნაკლოვანებების დასაძლევად, პირველ რიგში რისკის უკეთესი მართვისთვის. ამ მოდელის მიხედვით, პროდუქტის განვითარება სპირალურად მიმდინარეობს, რომლის ყოველი შემობრუნება განვითარების სპეციფიკურ ფაზას წარმოადგენს. ჩანჩქერის მოდელისგან განსხვავებით, სპირალურ მოდელს არ აქვს მოხვევების წინასწარ განსაზღვრული და სავალდებულო ნაკრები; თითოეული შემობრუნება შეიძლება იყოს ბოლო სისტემის განვითარების დროს; მისი დასრულების შემდეგ, შედგენილია შემდეგი შემობრუნების გეგმები. დაბოლოს, რევოლუცია არის ზუსტად ფაზა და არა აქტივობის სახეობა, როგორც ჩანჩქერის მოდელშია; მის ფარგლებში შეიძლება განხორციელდეს მრავალი სხვადასხვა ტიპის აქტივობა, ანუ მოდელი არის ორგანზომილებიანი.
მონაცვლეობის თანმიმდევრობა შეიძლება იყოს შემდეგი: პირველ რიგში მიიღება გადაწყვეტილება პროგრამული უზრუნველყოფის შექმნის მიზანშეწონილობის შესახებ, შემდეგში - გადაწყვეტილებები. სისტემის მოთხოვნები , შემდეგ სისტემა დაპროექტებულია და ა.შ. მონაცვლეობას შეიძლება სხვა მნიშვნელობა ჰქონდეს.
თითოეულ წრეს აქვს შემდეგი სტრუქტურა (სექტორები):
- პროექტის მიზნების, შეზღუდვებისა და ალტერნატივების განსაზღვრა;
- ალტერნატივების შეფასება, რისკების შეფასება და გადაჭრა; შესაძლებელია პროტოტიპის გამოყენება (პროტოტიპების სერიის შექმნის ჩათვლით), სისტემის სიმულაცია, ვიზუალური მოდელირება და სპეციფიკაციის ანალიზი; ფოკუსირება პროექტის ყველაზე სარისკო ნაწილებზე;
- შემუშავება და ტესტირება – აქ შესაძლებელია ჩანჩქერის მოდელის გამოყენება ან პროგრამული უზრუნველყოფის განვითარების სხვა მოდელებისა და მეთოდების გამოყენება;
- შემდეგი გამეორებების დაგეგმვა - გაანალიზებულია შედეგები, გეგმები და რესურსები შემდგომი განვითარებისთვის, მიიღება გადაწყვეტილება (ან არ მიიღება) ახალი რაუნდის შესახებ; აანალიზებს აზრი აქვს თუ არა სისტემის განვითარების გაგრძელებას; განვითარება შეიძლება შეჩერდეს, მაგალითად, დაფინანსების ჩავარდნის გამო; სპირალური მოდელისაშუალებას გაძლევთ ამის გაკეთება სწორად.
ცალკე სპირალი შეიძლება შეესაბამებოდეს ზოგიერთი პროგრამული კომპონენტის შემუშავებას ან პროდუქტში რეგულარული ცვლილებების დანერგვას. ამრიგად, მოდელს შეიძლება ჰქონდეს მესამე განზომილება.
სპირალური მოდელის გამოყენება არ არის მიზანშეწონილი რისკის დაბალი ხარისხის პროექტებში, შეზღუდული ბიუჯეტით, მცირე პროექტებისთვის. გარდა ამისა, ნაკლებობა კარგი სახსრებიპროტოტიპმა შეიძლება ასევე გახადოს სპირალური მოდელი არასასიამოვნო გამოსაყენებლად.
სპირალური მოდელიარ იპოვა ფართო აპლიკაციაინდუსტრიაში და მნიშვნელოვანია, უფრო ისტორიული და მეთოდოლოგიური თვალსაზრისით: ეს არის პირველი განმეორებითი მოდელი, აქვს ლამაზი მეტაფორა - სპირალი - და, ჩანჩქერის მოდელის მსგავსად, მოგვიანებით გამოიყენეს სხვა პროცესის მოდელებისა და პროგრამული უზრუნველყოფის განვითარების მეთოდოლოგიების შესაქმნელად.
პროგრამული პროდუქტის შემუშავებამ იცის ბევრი ღირსეული მეთოდოლოგია - სხვა სიტყვებით რომ ვთქვათ, დამკვიდრებული საუკეთესო პრაქტიკა. არჩევანი დამოკიდებულია პროექტის სპეციფიკაზე, ბიუჯეტის სისტემაზე, სუბიექტურ პრეფერენციებზე და მენეჯერის ტემპერამენტზეც კი. სტატიაში აღწერილია მეთოდოლოგიები, რომლებსაც რეგულარულად ვხვდებით ედისონში.
1. "ჩანჩქერის მოდელი" (კასკადური მოდელი ან "ჩანჩქერი")
ერთ-ერთი უძველესი, მოიცავს ეტაპების თანმიმდევრულ გავლას, რომელთაგან თითოეული მთლიანად უნდა დასრულდეს მომდევნო დაწყებამდე. ჩანჩქერის მოდელი აადვილებს პროექტის მართვას. მისი სიხისტის წყალობით, განვითარება სწრაფად მიმდინარეობს, ღირებულება და ვადა წინასწარ არის განსაზღვრული. მაგრამ ეს ორლესილი ხმალია. ჩანჩქერის მოდელი შესანიშნავ შედეგს მოგცემთ მხოლოდ პროექტებში მკაფიოდ და წინასწარ განსაზღვრული მოთხოვნებით და მათი განხორციელების გზებით. არ არსებობს გზა უკან გადადგმული ნაბიჯით; ტესტირება იწყება მხოლოდ განვითარების დასრულების ან თითქმის დასრულების შემდეგ. ამ მოდელის მიხედვით შემუშავებულ პროდუქტებს დასაბუთებული არჩევანის გარეშე შეიძლება ჰქონდეთ ხარვეზები (მოთხოვნების სიის კორექტირება ნებისმიერ დროს შეუძლებელია), რაც ცნობილი ხდება მხოლოდ დასასრულს მოქმედებების მკაცრი თანმიმდევრობის გამო. ცვლილებების შეტანის ღირებულება მაღალია, რადგან ის მოითხოვს ლოდინს მთელი პროექტის დასრულებამდე მის დასაწყებად. თუმცა, ფიქსირებული ღირებულება ხშირად აღემატება მიდგომის ნაკლოვანებებს. შექმნის პროცესში გამოვლენილი ხარვეზების გამოსწორება შესაძლებელია და, ჩვენი გამოცდილებით, მოითხოვს ერთიდან სამ დამატებით ხელშეკრულებას მცირე ტექნიკური სპეციფიკაციით.
ჩანჩქერის მოდელის გამოყენებით, ჩვენ შევქმენით მრავალი პროექტი ნულიდან, მათ შორის მხოლოდ ტექნიკური მახასიათებლების შემუშავება. Habré-ზე დაწერილი პროექტები: საშუალო - , პატარა - .
როდის გამოვიყენოთ ჩანჩქერის მეთოდოლოგია?
- მხოლოდ მაშინ, როდესაც მოთხოვნები ცნობილია, გასაგები და დაფიქსირებული. არ არსებობს ურთიერთსაწინააღმდეგო მოთხოვნები.
- არანაირი პრობლემა არ არის საჭირო კვალიფიკაციის მქონე პროგრამისტების ხელმისაწვდომობასთან დაკავშირებით.
- შედარებით მცირე პროექტებში.
2. "V-Model"
მემკვიდრეობით მიიღო "ნაბიჯ ნაბიჯ" სტრუქტურა კასკადის მოდელიდან. V- ფორმის მოდელი გამოიყენება სისტემებზე, რომლებისთვისაც უწყვეტი მუშაობა განსაკუთრებით მნიშვნელოვანია. Მაგალითად, აპლიკაციის პროგრამებიკლინიკებში პაციენტების მონიტორინგისთვის, ინტეგრირებული პროგრამული უზრუნველყოფა მანქანების გადაუდებელი აირბალიშების კონტროლის მექანიზმებისთვის და ა.შ. მოდელის განსაკუთრებული მახასიათებელია ის, რომ ის მიზნად ისახავს პროდუქტის საფუძვლიან შემოწმებას და ტესტირებას, რომელიც უკვე დიზაინის საწყის ეტაპზეა. ტესტირების ეტაპი ტარდება განვითარების შესაბამის ეტაპთან ერთდროულად, მაგალითად, კოდირების დროს იწერება ერთეული ტესტები.
V- მეთოდოლოგიაზე დაფუძნებული ჩვენი მუშაობის მაგალითი - მობილური აპლიკაციაევროპულისთვის მობილური ოპერატორი, რაც დაზოგავს როუმინგის ხარჯებს მოგზაურობისას. პროექტი ხორციელდება მკაფიო სპეციფიკაციის მიხედვით, მაგრამ იგი მოიცავს ტესტირების მნიშვნელოვან ეტაპს: ინტერფეისის მოხერხებულობას, ფუნქციონალურობას, დატვირთვას და ინტეგრაციის ჩათვლით, რაც უნდა დაადასტუროს, რომ სხვადასხვა მწარმოებლის რამდენიმე კომპონენტი ერთად მუშაობს სტაბილურად, ფულის და სესხების ქურდობა. შეუძლებელია.
როდის გამოვიყენოთ V- მოდელი?
- თუ საჭიროა პროდუქტის საფუძვლიანი ტესტირება, მაშინ V-მოდელი გაამართლებს მის თანდაყოლილ იდეას: ვალიდაციას და გადამოწმებას.
- მცირე და საშუალო ზომის პროექტებისთვის, სადაც მოთხოვნები მკაფიოდ არის განსაზღვრული და დაფიქსირებული.
- საჭირო კვალიფიკაციის მქონე ინჟინრების, განსაკუთრებით ტესტერების ხელმისაწვდომობის პირობებში.
3. „ინკრემენტალური მოდელი“ (ნამატიანი მოდელი)
ინკრემენტულ მოდელში, სისტემის სრული მოთხოვნები იყოფა სხვადასხვა შეკრებად. ტერმინოლოგია ხშირად გამოიყენება პროგრამული უზრუნველყოფის ეტაპობრივი შეკრების აღსაწერად. მიმდინარეობს განვითარების რამდენიმე ციკლი და ისინი ერთად ქმნიან მრავალ ჩანჩქერის სასიცოცხლო ციკლს. ციკლი დაყოფილია პატარა, ადვილად შექმნილ მოდულებად. თითოეული მოდული გადის მოთხოვნების განსაზღვრის, დიზაინის, კოდირების, განხორციელებისა და ტესტირების ეტაპებს. ინკრემენტული მოდელის მიხედვით განვითარების პროცედურა გულისხმობს საბაზისო ფუნქციონირების მქონე პროდუქტის პირველ დიდ ეტაპზე გამოშვებას და შემდეგ ახალი ფუნქციების, ე.წ. პროცესი გრძელდება მანამ, სანამ არ შეიქმნება სრული სისტემა.
დამატებითი მოდელები გამოიყენება, სადაც ინდივიდუალური ცვლილებების მოთხოვნები ნათელია და ადვილად შეიძლება ფორმალიზებული და განხორციელდეს. ჩვენს პროექტებში ჩვენ ვიყენებდით DefView Reader-ის, შემდეგ კი ელექტრონული ბიბლიოთეკების Vivaldi ქსელის შესაქმნელად.
მაგალითად, ჩვენ აღვწერთ ერთი ნამატის არსს. შეცვალა DefView. DefView დაკავშირებულია ერთ დოკუმენტის სერვერთან და ახლა შეუძლია ბევრთან დაკავშირება. შენახვის სერვერი დამონტაჟებულია დაწესებულების საიტზე, რომელსაც სურს მისი შინაარსის გადაცემა კონკრეტულ აუდიტორიაზე, რომელიც პირდაპირ წვდება დოკუმენტებს და გარდაქმნის მათ საჭირო ფორმატში. გამოჩნდა არქიტექტურის ძირეული ელემენტი - ცენტრალური ვივალდის სერვერი, რომელიც მოქმედებს როგორც ერთი საძიებო სისტემასხვადასხვა დაწესებულებებში დაინსტალირებული ყველა შენახვის სერვერზე.
როდის გამოვიყენოთ დამატებითი მოდელი?
- როდესაც სისტემის ძირითადი მოთხოვნები მკაფიოდ არის განსაზღვრული და გასაგები. ამავდროულად, ზოგიერთი დეტალი შესაძლოა დროთა განმავლობაში დაიხვეწოს.
- საჭიროა პროდუქტის ადრეული შემოტანა ბაზარზე.
- არსებობს რამდენიმე სარისკო თვისება ან მიზანი.
4. "RAD მოდელი" (აპლიკაციის განვითარების სწრაფი მოდელი ან აპლიკაციის სწრაფი განვითარება)
RAD მოდელი არის დამატებითი მოდელის ტიპი. RAD მოდელში კომპონენტები ან ფუნქციები მუშავდება რამდენიმე მაღალკვალიფიციური გუნდის მიერ პარალელურად, რამდენიმე მინი-პროექტის მსგავსად. ერთი ციკლის დრო მკაცრად შეზღუდულია. შექმნილი მოდულები შემდეგ ინტეგრირებულია ერთ სამუშაო პროტოტიპში. Synergy საშუალებას გაძლევთ ძალიან სწრაფად მიაწოდოთ კლიენტს რაიმე სამუშაო განსახილველად მისაღებად უკუკავშირიდა ცვლილებების შეტანა.
აპლიკაციის სწრაფი განვითარების მოდელი მოიცავს შემდეგ ეტაპებს:
- ბიზნეს მოდელირება: სხვადასხვა დეპარტამენტებს შორის ინფორმაციის ნაკადების სიის განსაზღვრა.
- მონაცემთა მოდელირება: წინა ეტაპზე შეგროვებული ინფორმაცია გამოიყენება ინფორმაციის მიმოქცევისთვის საჭირო ობიექტებისა და სხვა ერთეულების დასადგენად.
- პროცესის მოდელირება: ინფორმაციის ნაკადები აკავშირებს ობიექტებს განვითარების მიზნების მისაღწევად.
- აპლიკაციის შექმნა: იყენებს ავტომატური შეკრების ინსტრუმენტებს CAD მოდელების კოდად გადაქცევისთვის.
- ტესტირება: ტესტირებულია ახალი კომპონენტები და ინტერფეისები.
შესაძლებელია მხოლოდ მაღალკვალიფიციური და მაღალკვალიფიციური არქიტექტორების გამოყენება. პროექტის ბიუჯეტი დიდია ამ სპეციალისტებისთვის მზა ავტომატური შეკრების ხელსაწყოების ხარჯებთან ერთად. RAD მოდელის შერჩევა შესაძლებელია მიზნობრივი ბიზნესის დარწმუნებით ცოდნით და სისტემის გადაუდებელი წარმოების საჭიროებით 2-3 თვის განმავლობაში.
5. “Agile Model” (მოქნილი განვითარების მეთოდოლოგია)
„სწრაფი“ განვითარების მეთოდოლოგიაში, ყოველი გამეორების შემდეგ მომხმარებელს შეუძლია დააკვირდეს შედეგს და გაიგოს, აკმაყოფილებს თუ არა მას. ეს არის მოქნილი მოდელის ერთ-ერთი უპირატესობა. მის ნაკლოვანებებს შორისაა ის ფაქტი, რომ შედეგების სპეციფიკური ფორმულირებების არარსებობის გამო, ძნელია შეაფასოს შრომითი ხარჯები და განვითარებისთვის საჭირო ხარჯები. ექსტრემალური პროგრამირება (XP) არის სწრაფი მოდელის ერთ-ერთი ყველაზე ცნობილი პროგრამა პრაქტიკაში.
ამ ტიპს ეფუძნება მოკლე ყოველდღიური შეხვედრები - „სკრამი“ და რეგულარულად განმეორებადი შეხვედრები (კვირაში ერთხელ, ორ კვირაში ერთხელ ან თვეში ერთხელ), სახელწოდებით „სპრინტი“. ყოველდღიურ შეხვედრებზე გუნდის წევრები განიხილავენ:
- ანგარიში ბოლო Scrum-ის შემდეგ შესრულებული სამუშაოს შესახებ;
- დავალებების სია, რომელიც თანამშრომელმა უნდა შეასრულოს მომდევნო შეხვედრამდე;
- სირთულეები, რომლებიც წარმოიქმნება მუშაობის დროს.
როდის გამოვიყენოთ Agile?
- როდესაც მომხმარებლის მოთხოვნილებები მუდმივად იცვლება დინამიურ ბიზნესში.
- სწრაფი ცვლილებები ხორციელდება უფრო დაბალ ფასად, ხშირი მატების გამო.
- ჩანჩქერის მოდელისგან განსხვავებით, მოქნილი მოდელი მოითხოვს მხოლოდ მცირე დაგეგმვას, რომ პროექტი დადგეს ადგილზე.
6. „იტერატიული მოდელი“ (იტერატიული ან განმეორებითი მოდელი)
სასიცოცხლო ციკლის განმეორებითი მოდელი არ საჭიროებს სრულ მოთხოვნების დაზუსტებას დასაწყისისთვის. ამის ნაცვლად, შექმნა იწყება ფუნქციონალური ნაწილის განხორციელებით, რაც შემდგომი მოთხოვნების განსაზღვრის საფუძველი ხდება. ეს პროცესი მეორდება. ვერსია შეიძლება არ იყოს სრულყოფილი, მთავარია ის მუშაობს. საბოლოო მიზნის გაცნობიერებით, ჩვენ მისკენ ვისწრაფვით, რათა ყოველი ნაბიჯი იყოს ეფექტური და ყველა ვერსია იყოს გამოსადეგი.
დიაგრამაზე ნაჩვენებია მონა ლიზას განმეორებითი "განვითარება". როგორც ხედავთ, პირველ გამეორებაში არის მხოლოდ მონა ლიზას ესკიზი, მეორეში ჩნდება ფერები, ხოლო მესამე გამეორება ამატებს დეტალებს, გაჯერებას და ასრულებს პროცესს. ინკრემენტულ მოდელში პროდუქტის ფუნქციონირება აგებულია ნაწილ-ნაწილ, პროდუქტი შედგება ნაწილებისგან. განმეორებითი მოდელისგან განსხვავებით, თითოეული ნაწილი წარმოადგენს სრულ ელემენტს.
განმეორებითი განვითარების მაგალითია ხმის ამოცნობა. სამეცნიერო აპარატის პირველი კვლევა და მომზადება დიდი ხნის წინ დაიწყო ჯერ ფიქრებში, შემდეგ ქაღალდზე. ყოველი ახალი გამეორებით, ამოცნობის ხარისხი უმჯობესდებოდა. თუმცა, სრულყოფილი აღიარება ჯერ არ არის მიღწეული, შესაბამისად, პრობლემა ჯერ ბოლომდე არ არის მოგვარებული.
როდის არის ოპტიმალური იტერატიული მოდელის გამოყენება?
- საბოლოო სისტემის მოთხოვნები მკაფიოდ არის განსაზღვრული და წინასწარ გაგებული.
- პროექტი არის დიდი ან ძალიან დიდი.
- მთავარი მიზანი უნდა განისაზღვროს, მაგრამ განხორციელების დეტალები შეიძლება დროთა განმავლობაში განვითარდეს.
7. „სპირალური მოდელი“ (სპირალური მოდელი)
"სპირალური მოდელი" მსგავსია დამატებითი მოდელის, მაგრამ აქცენტით რისკის ანალიზზე. ის კარგად მუშაობს კრიტიკული ბიზნეს პრობლემების გადასაჭრელად, როდესაც წარუმატებლობა შეუთავსებელია კომპანიის საქმიანობასთან, ახალი პროდუქტის ხაზების გამოშვების კონტექსტში, როდესაც აუცილებელია სამეცნიერო კვლევა და პრაქტიკული ტესტირება.
სპირალური მოდელი მოიცავს 4 ეტაპს თითოეული მობრუნებისთვის:
- დაგეგმვა;
- რისკის ანალიზი;
- დიზაინი;
- შედეგის შეფასება და თუ ხარისხი დამაკმაყოფილებელია, ახალ ეტაპზე გადასვლა.
შევაჯამოთ
სლაიდი აჩვენებს განსხვავებებს ორ ყველაზე გავრცელებულ მეთოდოლოგიას შორის.
თანამედროვე პრაქტიკაში განვითარების მოდელები პროგრამული უზრუნველყოფამრავალვარიანტული. არ არსებობს ერთი სწორი მოდელი ყველა პროექტისთვის, საწყისი პირობებისთვის და გადახდის მოდელებისთვის. ჩვენთვის ასე საყვარელი Agile-საც კი ყველგან ვერ გამოიყენებთ ზოგიერთი მომხმარებლის მოუმზადებლობის ან მოქნილი დაფინანსების შეუძლებლობის გამო. მეთოდოლოგიები ნაწილობრივ ემთხვევა საშუალებებს და ნაწილობრივ ჰგავს ერთმანეთს. ზოგიერთი სხვა კონცეფცია გამოიყენებოდა მხოლოდ საკუთარი შემდგენელების პოპულარიზაციისთვის და პრაქტიკაში რაიმე ახალი არ შემოიტანეს.
განვითარების ტექნოლოგიების შესახებ:
.
.
.
.
რა მეთოდოლოგიას იყენებთ?
გამოვლენილია და დახასიათებულია პროგრამული უზრუნველყოფის განვითარების ძირითადი ეტაპები. თითოეული ეტაპისთვის წარმოდგენილია და აღწერილია ის საშუალებები, რომლებიც შეიძლება გამოყენებულ იქნას ეტაპის მიზნების მისაღწევად.
1. ტერმინოლოგია
სანამ დავიწყებთ განვითარების ინსტრუმენტების განხილვას, რომლებიც შეიძლება გამოყენებულ იქნას პროგრამების შესაქმნელად, აუცილებელია განვსაზღვროთ ძირითადი ცნებები და ტერმინები, რომლებიც გამოყენებული იქნება სტატიაში. სტატიის თემის შესაბამისად, ჩვენთვის ძირითადი ტერმინი, რა თქმა უნდა, არის „პროგრამის განვითარების ინსტრუმენტები“. როდესაც გამოიყენება პროგრამული უზრუნველყოფის განვითარების სფეროში, ეს განმარტება შეიძლება ასე ჟღერდეს:
პროგრამული უზრუნველყოფის განვითარების ინსტრუმენტები– ტექნიკის, მეთოდების, ტექნიკის ნაკრები, ასევე ინსტრუმენტული პროგრამების ნაკრები (კომპილატორები, აპლიკაციის/სისტემის ბიბლიოთეკები და ა.შ.), რომელსაც იყენებს დეველოპერი პროგრამის პროგრამის კოდის შესაქმნელად, რომელიც აკმაყოფილებს მითითებულ მოთხოვნებს.
Იმის გათვალისწინებით ამ განმარტებასტერმინი „პროგრამის განვითარება“ ასე ჟღერს:
პროგრამული უზრუნველყოფის განვითარება – რთული პროცესი, რომლის მთავარი მიზანია პროგრამის კოდის შექმნა და შენარჩუნება, რომელიც უზრუნველყოფს საიმედოობისა და ხარისხის საჭირო დონეს. პროგრამული უზრუნველყოფის განვითარების მთავარი მიზნის მისაღწევად გამოიყენება პროგრამული უზრუნველყოფის განვითარების ინსტრუმენტები.
2. პროგრამის შემუშავების სხვადასხვა ეტაპზე გამოყენებული ძირითადი ინსტრუმენტები
საგნის სფეროდან და დეველოპერებისთვის დაკისრებული ამოცანებიდან გამომდინარე, პროგრამის შემუშავება შეიძლება იყოს საკმაოდ რთული, ნაბიჯ-ნაბიჯ პროცესი, რომელიც მოიცავს დიდი რიცხვიმონაწილეები და სხვადასხვა საშუალებები. იმის დასადგენად, როდის და რა შემთხვევებში რომელი ინსტრუმენტები გამოიყენება, ჩვენ გამოვყოფთ პროგრამული უზრუნველყოფის შემუშავების ძირითად ეტაპებს. განსახილველი საკითხებისთვის ყველაზე დიდი ინტერესია განვითარების შემდეგი ეტაპები:
- განაცხადის დიზაინი.
- განაცხადის კოდის დანერგვა.
- განაცხადის ტესტირება.
ეტაპები, რომლებიც დაკავშირებულია ტექნიკური მახასიათებლების ჩაწერასთან, დაგეგმვის ვადებთან, ბიუჯეტებთან და ა.შ. აქ შეგნებულად გამოტოვებულია. ამის მიზეზი ის არის, რომ ამ ეტაპებზე, იშვიათი გამონაკლისების გარდა, განვითარების კონკრეტული ინსტრუმენტები პრაქტიკულად არ გამოიყენება.
2.1 აპლიკაციის დიზაინის ინსტრუმენტები
განაცხადის დიზაინის ეტაპზე, შემუშავებული პროგრამული პროდუქტის სირთულიდან გამომდინარე, რაც პირდაპირ დამოკიდებულია მოთხოვნებზე, შესრულებულია შემდეგი დიზაინის ამოცანები:
- მოთხოვნების ანალიზი.
- მომავალი პროგრამული არქიტექტურის შემუშავება.
- მოწყობილობებისა და ძირითადი პროგრამული კომპონენტების შემუშავება.
- მომხმარებლის ინტერფეისის განლაგების შემუშავება.
დიზაინის შედეგი, როგორც წესი, არის „სქემატური დიზაინი“ (პროგრამული დიზაინის დოკუმენტი) ან „ტექნიკური დიზაინი“ (პროგრამული არქიტექტურის დოკუმენტი). მოთხოვნების ანალიზის ამოცანა, როგორც წესი, ხორციელდება სისტემური მეცნიერების (ანალიზი და სინთეზი) მეთოდების გამოყენებით, დიზაინერის საექსპერტო გამოცდილების გათვალისწინებით. ანალიზის შედეგი, როგორც წესი, არის პროგრამის ფუნქციონირების პროცესის მნიშვნელოვანი ან ფორმალიზებული მოდელი. პროცესის სირთულიდან გამომდინარე, ამ მოდელების ასაგებად შეიძლება გამოყენებულ იქნას სხვადასხვა მეთოდები და დამხმარე საშუალებები. ზოგადად, შემდეგი აღნიშვნები ჩვეულებრივ გამოიყენება მოდელების აღსაწერად (ფრჩხილებში არის პროგრამული უზრუნველყოფა, რომელიც შეიძლება გამოყენებულ იქნას მოდელების მისაღებად):
- BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
- ნაკადების დიაგრამები (Vision 2003 და მრავალი სხვა).
- ER დიაგრამები (Visio 2003, ERWin, Sybase Power Designer და მრავალი სხვა).
- UML დიაგრამები (Sybase Power Designer, Rational Rose და მრავალი სხვა).
- განლაგება, ხალიჩების მოდელები და ა.შ.
ზოგჯერ, როდესაც შემუშავებული პროგრამული პროდუქტი გამიზნულია რაიმე რთული აქტივობის ავტომატიზაციისთვის, ანალიზის (მოდელირების) დავალება შესრულებულია მომავალი პროდუქტის ტექნიკური მოთხოვნების შედგენამდე. ანალიზის შედეგები საშუალებას გვაძლევს ჩამოვაყალიბოთ გონივრული მოთხოვნები შემუშავებული პროგრამის ამა თუ იმ ფუნქციონალურობის მიმართ და გამოვთვალოთ რეალური სარგებელი შემუშავებული პროდუქტის განხორციელებიდან. უფრო მეტიც, ზოგჯერ ირკვევა, რომ ანალიზის შედეგების საფუძველზე, ავტომატიზაციის საწყისი მიზნები და ამოცანები რადიკალურად იცვლება, ან განვითარებისა და განხორციელების ეფექტურობის შეფასების შედეგებზე დაყრდნობით, მიიღება გადაწყვეტილება, რომ არ შეიმუშაოს პროდუქტი.
ამოცანების მოცემული სიიდან მეორე და მესამე დავალების მიზანია შეიმუშაოს მომავალი სისტემის მოდელის (აღწერის) ენკოდერისთვის - პროგრამის კოდის დამწერისთვის გასაგები. აქ დიდი მნიშვნელობა აქვს პროგრამირების რა პარადიგმას (პროგრამის პარადიგმაც განვითარების ინსტრუმენტად უნდა მივიჩნიოთ) პროგრამის დაწერისას. ძირითადი პარადიგმების მაგალითად უნდა მოვიყვანოთ შემდეგი:
- ფუნქციური პროგრამირება;
- სტრუქტურირებული პროგრამირება;
- იმპერატიული პროგრამირება;
- ლოგიკური პროგრამირება;
- ობიექტზე ორიენტირებული პროგრამირება (პროტოტიპირება; კლასების გამოყენება; სუბიექტურზე ორიენტირებული პროგრამირება).
არჩევანი დიდწილად დამოკიდებულია დამკვიდრებულ ჩვევებზე, გამოცდილებაზე, ტრადიციებზე, ხელსაწყოები, რომელიც დეველოპერთა გუნდს აქვს განკარგულებაში. ზოგჯერ შემუშავებული პროგრამული პროდუქტი იმდენად რთულია, რომ სხვადასხვა პარადიგმები გამოიყენება სისტემის სხვადასხვა კომპონენტში რიგი პრობლემების გადასაჭრელად. უნდა აღინიშნოს, რომ ამა თუ იმ მიდგომის არჩევა აწესებს შეზღუდვებს იმ ინსტრუმენტებზე, რომლებიც გამოყენებული იქნება პროგრამის კოდის დანერგვის ეტაპზე. ამ პრობლემის გადაჭრის შედეგი, მიდგომიდან გამომდინარე, შეიძლება იყოს (პროგრამული ინსტრუმენტები, რომლებიც შეიძლება გამოყენებულ იქნას მათ მოსაპოვებლად, მოცემულია ფრჩხილებში):
- კლასის დიაგრამა და ა.შ. (Ration Rose, Sybase PowerDisigner და მრავალი სხვა).
- სტრუქტურის მოდულების აღწერა და მათი პროგრამული ინტერფეისი (მაგალითად, Sybase PowerDisigner და მრავალი სხვა).
მომხმარებლის ინტერფეისის განლაგების შემუშავება გულისხმობს ვიზუალური წარმოდგენის შექმნას, თუ როგორ გამოიყურება გარკვეული ვიდეო ფორმები და ფანჯრები შემუშავებულ აპლიკაციაში. ამ პრობლემის გადაწყვეტა ეფუძნება დიზაინერული ხელსაწყოების გამოყენებას, რაც ამ სტატიაში არ იქნება განხილული.
2.2 ინსტრუმენტები პროგრამის კოდის განხორციელებისთვის
პროგრამის კოდის განხორციელების ეტაპზე ხდება პროგრამის ცალკეული კომპონენტების კოდირება შემუშავებული ტექნიკური დიზაინის შესაბამისად. საშუალებები, რომელთა გამოყენება შესაძლებელია დიდწილად დამოკიდებულია იმაზე, თუ რა მიდგომები იქნა გამოყენებული დიზაინის დროს და, გარდა ამისა, ტექნიკური დიზაინის დამუშავების ხარისხზე. ამასთან, პროგრამული კოდის შემუშავების ინსტრუმენტებს შორის აუცილებელია გამოვყოთ შემდეგი ძირითადი ტიპის ინსტრუმენტები (ინსტრუმენტების მაგალითები მოცემულია ფრჩხილებში): ალგორითმული მეთოდები და ტექნიკა.
- პროგრამირების ენები (C++, C, Java, C#, php და მრავალი სხვა);
- UI ინსტრუმენტები (MFC, WPF, QT, GTK+ და ა.შ.)
- კოდის ვერსიის კონტროლის ხელსაწყოები (cvs, svn, VSS).
- ინსტრუმენტები შესრულებადი კოდის მისაღებად (MS Visual Studio, gcc და მრავალი სხვა).
- მონაცემთა ბაზის მართვის ინსტრუმენტები (Oracle, MS SQL, FireBird, MySQL და მრავალი სხვა).
- debugger-ები (MS Visual Studio, gdb და ა.შ.).
2.3 პროგრამის ტესტირების ხელსაწყოები
ტესტირების ძირითადი მიზნებია იმის შემოწმება, აკმაყოფილებს თუ არა შემუშავებული პროგრამის ფუნქციონალობა საწყის მოთხოვნებს, აგრეთვე შეცდომების იდენტიფიცირება, რომლებიც აშკარად ან იმპლიციურად ჩნდება პროგრამის მუშაობის დროს. ძირითადი ტესტირების აქტივობები მოიცავს შემდეგს:
- წარუმატებლობის ტესტირება და აღდგენა.
- ფუნქციური ტესტირება.
- უსაფრთხოების ტესტირება.
- ურთიერთქმედების ტესტირება.
- ინსტალაციის პროცესის ტესტირება.
- გამოყენებადობის ტესტირება.
- კონფიგურაციის ტესტირება.
- სტრესის ტესტირება.
ძირითადი ტიპის საშუალებებს შორის, რომლებიც შეიძლება გამოყენებულ იქნას დავალებული სამუშაოს შესასრულებლად, არის შემდეგი:
- კოდების ანალიზისა და პროფილირების ხელსაწყოები (Code Wizard – ParaSoft, Purify – Rational Softawre. Test Coverage – Semantic და ა.შ.);
- ფუნქციების შესამოწმებელი ინსტრუმენტები (TEST – Parasoft, QACenter – Compuware, Borland SilkTestდა ა.შ.);
- შესრულების ტესტირების ხელსაწყოები (QACenter Performance – Compuware და ა.შ.).
3. დასკვნა
პროგრამული უზრუნველყოფის შემუშავების პროცესი რთული პროცესია და რა ინსტრუმენტები უნდა იქნას გამოყენებული დიდწილად დამოკიდებულია დეველოპერებისთვის დაკისრებულ ამოცანებზე. განვითარების ამოცანების მიუხედავად, ინსტრუმენტები არ შეიძლება შემოიფარგლოს მხოლოდ გარკვეული ინსტრუმენტების ნაკრებით; ასევე აუცილებელია შეიცავდეს მეთოდებს, ტექნიკას, მიდგომებს და ყველაფერს, რაც გამოიყენება პროგრამის შესაქმნელად, რომელიც აკმაყოფილებს მითითებულ მოთხოვნებს.
ასევე შეხედე :
დღეს რთული პროგრამული აპლიკაციების შექმნის პროცესი წარმოუდგენელია მისი სასიცოცხლო ციკლის ეტაპებად დაყოფის გარეშე. პროგრამის სასიცოცხლო ციკლში ჩვენ ვგულისხმობთ ეტაპების ერთობლიობას:
- საგნის არეალის ანალიზი და ტექნიკური მახასიათებლების შექმნა (მომხმარებელთან ურთიერთქმედება)
- პროგრამის სტრუქტურის შემუშავება
- კოდირება (პროგრამის კოდის ნაკრები პროექტის დოკუმენტაციის მიხედვით)
- ტესტირება და გამართვა
- პროგრამის განხორციელება
- პროგრამის მხარდაჭერა
- განკარგვა
UML არის გრაფიკული ენა სხვადასხვა სისტემების (კერძოდ, პროგრამების) ვიზუალიზაციის, პარამეტრების აღწერისთვის, დიზაინისა და დოკუმენტაციისთვის. დიაგრამები იქმნება სპეციალური CASE ინსტრუმენტების გამოყენებით, როგორიცაა Rational Rose (http://www-01.ibm.com/software/rational/) და Enterprise Architect (http://www.sparxsystems.com.au/). UML ტექნოლოგიაზე დაყრდნობით, ერთიანი ინფორმაციის მოდელი. ზემოთ მოყვანილ CASE ინსტრუმენტებს შეუძლიათ კოდის გენერირება სხვადასხვა ობიექტზე ორიენტირებულ ენაზე და ასევე აქვთ ძალიან სასარგებლო ფუნქციასაპირისპირო ინჟინერია. (უკუ ინჟინერია საშუალებას გაძლევთ შექმნათ გრაფიკული მოდელი არსებული პროგრამის კოდიდან და მასზე კომენტარებიდან.)
მოდით გადავხედოთ დიაგრამების ტიპებს მოდელის ვიზუალიზაციისთვის (ეს აუცილებელია, თუმცა კიდევ ბევრი ტიპია):
გამოიყენეთ საქმის დიაგრამა
შემუშავებული სისტემა წარმოდგენილია როგორც ერთეულების ან აქტორების ერთობლიობა, რომლებიც ურთიერთქმედებენ სისტემასთან ე.წ. პრეცედენტების გამოყენებით. ამ შემთხვევაში, აქტორი ან აქტორი არის ნებისმიერი სუბიექტი, რომელიც ურთიერთქმედებს სისტემასთან გარედან. სხვა სიტყვებით რომ ვთქვათ, თითოეული გამოყენების შემთხვევა განსაზღვრავს მოქმედებების გარკვეულ კომპლექსს, რომელსაც სისტემა ასრულებს აქტორთან დიალოგის დროს. თუმცა, არაფერია ნათქვამი იმაზე, თუ როგორ განხორციელდება აქტორების სისტემასთან ურთიერთქმედება.კლასის დიაგრამა
კლასის დიაგრამა ემსახურება სისტემის მოდელის სტატიკური სტრუქტურის წარმოდგენას ობიექტზე ორიენტირებული პროგრამირების კლასების ტერმინოლოგიაში. კლასის დიაგრამა შეიძლება ასახავდეს, კერძოდ, სხვადასხვა ურთიერთობებს ცალკეულ დომენურ ერთეულებს შორის, როგორიცაა ობიექტები და ქვესისტემები, ასევე აღწერს მათ შიდა სტრუქტურას (ველები, მეთოდები...) და ურთიერთობების ტიპებს (მემკვიდრეობა, ინტერფეისების განხორციელება... ). ეს დიაგრამა არ იძლევა ინფორმაციას სისტემის მუშაობის დროის ასპექტების შესახებ. ამ თვალსაზრისით, კლასის დიაგრამა არის შემუშავებული სისტემის კონცეპტუალური მოდელის შემდგომი განვითარება. ამ ეტაპზე აუცილებელია OOP მიდგომისა და დიზაინის ნიმუშების ცოდნა.
მდგომარეობის დიაგრამა
ამ დიაგრამის მთავარი მიზანია აღწეროს მდგომარეობათა და გადასვლების შესაძლო თანმიმდევრობა, რომლებიც ერთად ახასიათებენ მოდელის ელემენტის ქცევას მისი სასიცოცხლო ციკლის განმავლობაში. მდგომარეობის დიაგრამა წარმოადგენს ერთეულების დინამიურ ქცევას ზოგიერთი კონკრეტული მოვლენის აღქმაზე მათი რეაგირების სპეციფიკაზე დაყრდნობით.
თანმიმდევრობის დიაგრამა
UML ენაში ობიექტების ურთიერთქმედების მოდელირებისთვის გამოიყენება ურთიერთქმედების შესაბამისი დიაგრამები. ობიექტების ურთიერთქმედების ნახვა შესაძლებელია დროში, შემდეგ კი მიმდევრობის დიაგრამა გამოიყენება ობიექტებს შორის შეტყობინებების გადაცემისა და მიღების დროის გამოსაჩენად. ურთიერთქმედების ობიექტები ერთმანეთს უცვლიან გარკვეულ ინფორმაციას. ამ შემთხვევაში ინფორმაცია დასრულებული შეტყობინებების ფორმას იღებს. სხვა სიტყვებით რომ ვთქვათ, მიუხედავად იმისა, რომ შეტყობინებას აქვს ინფორმაციული შინაარსი, ის იძენს მის მიმღებზე მიმართული ზემოქმედების განხორციელების დამატებით თვისებას.
თანამშრომლობის დიაგრამა
თანამშრომლობის დიაგრამაში, ურთიერთქმედებაში მონაწილე ობიექტები გამოსახულია მართკუთხედების სახით, რომლებიც შეიცავს ობიექტის სახელს, მის კლასს და, შესაძლოა, ატრიბუტების მნიშვნელობებს. კლასის დიაგრამის მსგავსად, ობიექტებს შორის ასოციაციები მითითებულია სხვადასხვა დამაკავშირებელი ხაზების სახით. ამ შემთხვევაში, თქვენ შეგიძლიათ პირდაპირ მიუთითოთ ასოციაციის სახელები და როლები, რომლებსაც ობიექტები ასრულებენ ამ ასოციაციაში.მიმდევრობის დიაგრამისგან განსხვავებით, თანამშრომლობის დიაგრამა ასახავს მხოლოდ ობიექტებს შორის ურთიერთობებს, რომლებიც ასრულებენ კონკრეტულ როლს ურთიერთქმედებაში.
კომპონენტის დიაგრამა
კომპონენტის დიაგრამა, განსხვავებით ადრე განხილული დიაგრამებისგან, აღწერს სისტემის ფიზიკური წარმოდგენის მახასიათებლებს. კომპონენტის დიაგრამა საშუალებას გაძლევთ განსაზღვროთ შემუშავებული სისტემის არქიტექტურა პროგრამული უზრუნველყოფის კომპონენტებს შორის დამოკიდებულების დადგენით, რაც შეიძლება იყოს წყარო, ორობითი და შესრულებადი კოდი. განვითარების ბევრ გარემოში, მოდული ან კომპონენტი შეესაბამება ფაილს. მოდულების დამაკავშირებელი წერტილოვანი ისრები აჩვენებს ურთიერთდამოკიდებულების მსგავს კავშირებს, რაც ხდება პროგრამის საწყისი კოდის შედგენისას. კომპონენტის დიაგრამის ძირითადი გრაფიკული ელემენტებია კომპონენტები, ინტერფეისები და მათ შორის დამოკიდებულებები.
განლაგების დიაგრამა
განლაგების დიაგრამა შექმნილია პროგრამის ელემენტებისა და კომპონენტების ვიზუალიზაციისთვის, რომლებიც არსებობს მხოლოდ გაშვების ეტაპზე. ამ შემთხვევაში წარმოდგენილია მხოლოდ პროგრამის ინსტანციის კომპონენტები, რომლებიც არის შესრულებადი ფაილები ან დინამიური ბიბლიოთეკები. ის კომპონენტები, რომლებიც არ გამოიყენება მუშაობის დროს, არ არის ნაჩვენები განლაგების დიაგრამაში.განლაგების დიაგრამა შეიცავს გრაფიკული სურათებიპროცესორები, მოწყობილობები, პროცესები და მათ შორის კავშირები. ლოგიკური წარმოდგენის დიაგრამებისგან განსხვავებით, განლაგების დიაგრამა მთლიანი სისტემისთვის ერთგვაროვანია, რადგან ის სრულად უნდა ასახავდეს მისი განხორციელების მახასიათებლებს. ეს დიაგრამა არსებითად ასრულებს OOAP პროცესს კონკრეტულისთვის პროგრამული სისტემადა მისი განვითარება, როგორც წესი, მოდელის დაზუსტების ბოლო ეტაპია.
ეს ამთავრებს ჩვენს მიმოხილვას დიაგრამების კონკრეტულად და ზოგადად დიზაინზე. აღსანიშნავია, რომ დიზაინის პროცესი დიდი ხანია გახდა სტანდარტი პროგრამული უზრუნველყოფის განვითარებისთვის, მაგრამ ხშირად თქვენ უნდა გაუმკლავდეთ შესანიშნავად დაწერილ პროგრამას, რომელიც, ნორმალური დოკუმენტაციის არარსებობის გამო, გადატვირთულია არასაჭირო გვერდითი ფუნქციებით, ხელჯოხებით, ხდება რთული. და კარგავს თავის ყოფილ ხარისხს. =(
დარწმუნებული ვარ, რომ პროგრამისტი უპირველეს ყოვლისა კოდიერია - ის არ უნდა დაუკავშირდეს მომხმარებელს, არ უნდა იფიქროს სისტემის არქიტექტურაზე, არ უნდა გამოიგონოს პროგრამის ინტერფეისი, მან უნდა მხოლოდ კოდირება - დანერგოს ალგორითმები, ფუნქციონირება, გარეგნობაგამოყენებადობა, მაგრამ მეტი არაფერი... დიზაინერმა უნდა, დაწყებული აბსტრაქტული დიაგრამებიდან (საგნის არეალის აღწერით) დიაგრამებამდე, რომელიც წარმოადგენს მონაცემთა სტრუქტურას, კლასებს და მათი ურთიერთქმედების პროცესებს, დეტალურად აღწერს ყველაფერს ეტაპობრივად. ანუ, სამუშაოს სირთულე და დიზაინერის ხელფასი უნდა იყოს სიდიდის რიგითობა, ვიდრე პროგრამისტის == კოდირების. ბოდიშს გიხდით ამბოხებისთვის....