Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Компьютерлік техникада хаос моделі – бағдарламалық жасақтаманы әзірлеудің құрылымы. Оның L. B. S. Raccoon атты автор (псевдоним) спираль және каскад сияқты жобаны басқару модельдері кестелерді және персоналды басқаруда жақсы болғанымен, қателерді жою немесе басқа техникалық мәселелерді шешу әдістерін ұсынбайтынын айтты. Сонымен қатар, бағдарламалау әдістемелері қателерді жою және техникалық мәселелерді шешуде тиімді болғанымен, мерзімдерді басқаруға немесе клиенттердің талаптарына жауап беруге көмектеспейді. Бұл құрылым осы кемшілікті жоюға бағытталған. Хаос теориясы осы мәселелерді түсінуге көмектесетін құрал ретінде пайдаланылды.
In computing, the chaos model is a structure of software development. Its creator, who used the pseudonym L. B. S. Raccoon, noted that project management models such as the spiral model and waterfall model, while good at managing schedules and staff, didn't provide methods to fix bugs or solve other technical problems. At the same time, programming methodologies, while effective at fixing bugs and solving technical problems, do not help in managing deadlines or responding to customer requests. The structure attempts to bridge this gap. Chaos theory was used as a tool to help understand these issues.
Бағдарламалық жасақтаманың өмірлік циклі
Хаос моделі өмірлік циклдың кезеңдері жобаның барлық деңгейлеріне – бүкіл жобадан бастап жеке код жолдарына дейін қолданылады. Бүкіл жоба анықталып, іске асырылып, интеграциялануы керек. Жүйелер анықталып, іске асырылып, интеграциялануы керек. Модульдер анықталып, іске асырылып, интеграциялануы керек. Функциялар анықталып, іске асырылып, интеграциялануы керек. Код жолдары анықталып, іске асырылып, интеграцияланады. Маңызды көзқарас өзгерісі – жобаларды тұтас бірліктер деп қарастыруға бола ма, әлде бөліктерге бөліп қарастыру қажет пе деген сұрақ. Ешкім бір отырыста он мыңдаған код жолын жаза алмайды. Олар кішкентай бөліктерді, бір жолдан бастап жазып, олардың жұмыс істейтінін тексеріп отырады. Содан кейін олар одан әрі дамытады. Күрделі жүйенің мінез-құлқы кіші құрылыс бөліктерінің біріккен мінез-құлқынан пайда болады.
The chaos model notes that the phases of the life cycle apply to all levels of projects, from the whole project to individual lines of code. The whole project must be defined, implemented, and integrated. Systems must be defined, implemented, and integrated. Modules must be defined, implemented, and integrated. Functions must be defined, implemented, and integrated. Lines of code are defined, implemented and integrated. One important change in perspective is whether projects can be thought of as whole units, or must be thought of in pieces. Nobody writes tens of thousands of lines of code in one sitting. They write small pieces, one line at a time, verifying that the small pieces work. Then they build up from there. The behavior of a complex system emerges from the combined behavior of the smaller building blocks.
Қауіпсіздік стратегиясы
Хаос стратегиясы – хаос моделіне негізделген бағдарламалық жасақтаманы әзірлеу стратегиясы. Басты ереже – ең маңызды мәселені бірінші шешу. Мәселе – аяқталмаған бағдарламалау тапсырмасы. Ең маңызды мәселе – үлкен, жедел және сенімді. Үлкен мәселелер пайдаланушыларға жұмыс істейтін мүмкіндік ретінде құндылық сыйлайды. Жедел мәселелер уақтылы болып табылады, әйтпесе олар басқа жұмыстың жолын тоқтатады. Сенімді мәселелер шешілген кезде тексеріліп, сенімділікке ие болады. Содан кейін бағдарламашылар өз назарын басқа нәрсеге аудара алады. Шешу дегеніміз – оны тұрақты күйге жеткізу. Хаос стратегиясы бағдарламашылардың жоба соңына жақындағандағы жұмыс стиліне ұқсайды, олар түзетуге қателер мен жасауға мүмкіндіктер тізімімен жұмыс жасайды. Әдетте біреу қалған тапсырмаларды басымдыққа қояды, ал бағдарламашылар оларды бірінен соң бірін түзетуге кіріседі. Хаос стратегиясы осының ғана дұрыс жол екенін айтады. Хаос стратегиясы Go стратегиясынан шабыттанды.
The chaos strategy is a strategy of software development based on the chaos model. The main rule is always resolve the most important issue first. An issue is an incomplete programming task. The most important issue is a combination of big, urgent, and robust. Big issues provide value to users as working functionality. Urgent issues are timely in that they would otherwise hold up other work. Robust issues are trusted and tested when resolved. Developers can then safely focus their attention elsewhere. To resolve means to bring it to a point of stability. The chaos strategy resembles the way that programmers work toward the end of a project, when they have a list of bugs to fix and features to create. Usually someone prioritizes the remaining tasks, and the programmers fix them one at a time. The chaos strategy states that this is the only valid
way to do the work. The chaos strategy was inspired by Go strategy.
Хаос теориясымен байланысы
Хаос теориясымен бірнеше байланыстар бар. Хаос моделі бағдарламалық құралдың неге соншалықты болжамсыз болатынын түсіндіруге көмектеседі. Ол архитектура сияқты жоғары деңгейдегі ұғымдарды төменгі деңгейдегі кодтың жолдарынан бөлек қарастыруға болмайтынын түсіндіреді. Бұл хаос стратегиясы тұрғысынан не істеу керектігін түсіндіруге мүмкіндік береді.
There are several tie ins with chaos theory. The chaos model may help explain why software tends to be so unpredictable. It explains why high level concepts like architecture cannot be treated independently of low level lines of code. It provides a hook for explaining what to do next, in terms of the chaos strategy.