Програм хангамж боловсруулах технологийг авч үзэхдээ програм хангамж хөгжүүлэх асуудлын зарим нэг талыг биш, харин асуудлыг бүхэлд нь авч үзэх системчилсэн хандлагыг ашиглах шаардлагатай. Системийн хандлагыг орон зай, цаг хугацаанд хэрэгжүүлдэг.

Цаг хугацааны системтэй арга нь програм хангамжийн хангагдаагүй хэрэгцээ үүссэн үеэс програм хангамжийг бий болгох үе шатуудын дарааллыг харгалзан үздэг. зөвшөөрөл хүртэлболон хүлээн авсан үйл ажиллагаанд дэмжлэг үзүүлэх програм хангамжийн бүтээгдэхүүн.

"Сансар" дахь системийн хандлага системийн нэг хэсэг болгон боловсруулж буй програм хангамжийг авч үзэхийг заасан.Үүний зэрэгцээ боловсруулсан програм хангамжийг багтаасан системийн мэдээллийн хэрэгцээг судалсны үндсэн дээр зорилго, програм хангамжийн функцүүдийн багцыг томъёолж, прототипүүдэд дүн шинжилгээ хийдэг. програм хангамжийн хэрэгслүүд. Програм хангамжийн шаардлагыг бүрдүүлж, баримтжуулсан.

Орчин үеийн технологиПрограм хангамжийн хөгжүүлэлт нь програмчлалыг хөгжлийн мөчлөгийн дараалсан үе шатуудын гинжин хэлхээний хөгжлийн үе шатуудын нэг гэж үздэг. Эдгээр бүх үе шатууд нь програм хангамжийн амьдралын мөчлөгийн үзэл баримтлалаар нэгдсэн бөгөөд зохих програм хангамж, техник хангамжийн хэрэгслээр дэмжигдсэн байх ёстой.

Олон улсын ISO/IEC 12207 стандартын дагуу Мэдээллийн технологи– Програм хангамжийн амьдралын мөчлөгийн процессууд” програм хангамжийг хөгжүүлэх үйл явц нь програм хангамжийн амьдралын мөчлөгийн дараах үе шатуудыг агуулна.

1) шинжилгээ Системийн шаардлагаба хамрах хүрээ;

2) системийн архитектурын зураг төсөл;

3) програм хангамжийн шаардлагын дүн шинжилгээ (техникийн үзүүлэлт, гадаад интерфейс,);

4) програм хангамжийн архитектурын дизайн;

5) програм хангамжийн нэгж бүрийн нарийвчилсан загвар;

6) програм хангамжийн кодчилол (програмчлал)

7) програм хангамжийн нэгжийн туршилт;

8) програм хангамжийн нэгжийн багцыг нэгтгэх (програм хангамжийг нэгтгэх), турших;

9) програм хангамжийн мэргэшлийн шалгалт (нэгдсэн туршилт);

10) системийн интеграцийн програм хангамжийн бүтцийн нэгжүүд нь техник хангамжийн нэгжүүдтэй нэгдсэн байх;

11) системийн мэргэшлийн шалгалт;

12) програм хангамж суурилуулах.

Тиймээс програм хангамж боловсруулах үйл явц нь энэ програм хангамжийг ашиглах системээс эхэлж, системд дахин дуусдаг.

Програм хангамжийн амьдралын мөчлөгийн хөгжлийн үе шатуудын дараа програм хангамжийн үйл ажиллагаа, ашиглалтын засвар үйлчилгээний шат дамждаг. Заримдаа програм хангамжийн амьдралын мөчлөгийн үе шатуудын жагсаалтыг 12 үе шатыг нэгтгэн дүгнэж өгдөг. Тухайлбал, системийн дизайны үе шатууд болон програм хангамжийн шаардлагыг тодорхойлох, програм хангамжийн багцын дизайн, програм хангамжийн алгоритмын дизайн, програмчлал (кодлох), офлайн програм хангамжийн дибаг хийх, програм хангамжийн цогц алдаа засах, програм хангамжийн үйл ажиллагаа.

Програм хангамжийн дизайны үе шатуудыг үл тоомсорлож, алгоритмууд болон програм хангамжийн бүтцийн нэгжүүдийн харилцан үйлчлэлийн асуудлыг хангалттай судлахгүйгээр шууд програмчлалыг эхлүүлэх хүсэл нь амжилтанд хүрэх магадлал багатай эмх замбараагүй програм хангамжийг хөгжүүлэх үйл явцад хүргэдэг.

Спираль програм хангамжийн амьдралын мөчлөгийн загвар. "Хүнд ба хөнгөн" (хурдан) програм хангамж хөгжүүлэх технологи

Амьдралын мөчлөгийн загвар (LC) нь каскадын төрлийн загварт хамаарна. Энэ төрлийн амьдралын мөчлөгийн загвар нь хөгжүүлэлтийн эхэн үед програм хангамжид тавигдах бүх шаардлагыг бүрэн, үнэн зөв боловсруулах боломжтой програм хангамжид тохиромжтой.

Спираль програм хангамжийн амьдралын мөчлөгийн схем. Гэсэн хэдий ч, бодит үйл явцПрограм хангамжийн хөгжүүлэлт нь ийм хатуу схемд үргэлж нийцдэггүй бөгөөд ихэнхдээ гаргасан шийдвэрээ тодруулах, засварлах замаар өмнөх үе шат руугаа буцах шаардлагатай болдог.

Програм хангамжийн хувьд, мөн бусад нарийн төвөгтэй системүүдийн хувьд анхны шаардлага нь бүрэн хангагдаагүй байгаа тул давталттай хөгжүүлэх үйл явц нь онцлог юм. Үүний зэрэгцээ зарим төрлийн програм хангамжийн хувьд дараагийн шатанд аль болох хурдан шилжих нь зүйтэй юм. Үүний зэрэгцээ, ийм яаруу ажил хийхээс зайлсхийх боломжгүй дутагдал нь дараагийн давталтаар арилдаг эсвэл үүрд үлддэг.

Гол ажил бол ажиллах боломжтой програм хангамжийг аль болох хурдан олж авах, ингэснээр шаардлагыг тодруулах, нэмэлт болгох үйл явцыг идэвхжүүлэх явдал юм. Энэ бол спираль програм хангамжийн амьдралын мөчлөг гэж нэрлэгддэг загвар юм.

Спираль эргэх бүрт бүтээгдэхүүний хувилбар бий болж, програм хангамжийн шаардлагыг тодорхойлж, дараагийн ээлжийн ажлыг төлөвлөдөг. Програм хангамжийн амьдралын мөчлөгийн спираль загвар нь програм хангамжийн давталттай хөгжлийн объектив үйл явцыг тусгадаг (Зураг 8.2).

Програм хангамжийн амьдралын мөчлөгийн спираль схем нь яаран хөгжүүлэгчдэд зориулагдсан биш, харин програм хангамжийн функциональ зорилгод нийцүүлэн чанар муутай анхны хувилбаруудыг ашиглах боломжтой програм хангамжид зориулагдсан гэж үздэг.

Амьдралын мөчлөгийн спираль загвартай холбоотой үзэл бодлын үзэл суртлын үндэслэлийг өгдөг програм хангамжийг хөгжүүлэх "Хурдан технологи" (Agile Software Development) чиглэл байдаг. Эдгээр технологи нь дөрвөн санаан дээр суурилдаг:

Хувь хүмүүсийн харилцан үйлчлэл нь албан ёсны журам, хэрэглүүрээс илүү чухал.

Ажлын програм хангамж нь түүнд зориулсан баримт бичигтэй байхаас илүү чухал юм.

Хэрэглэгчтэй хамтран ажиллах нь албан ёсны гэрээнээс илүү чухал,

Шуурхай хариу гадаад өөрчлөлтүүдтөлөвлөгөөг чанд мөрдөхөөс илүү чухал.

Цагаан будаа. 8.2 - Спираль програм хангамжийн амьдралын мөчлөгийн схем

Өөрөөр хэлбэл, хурдан технологи нь хөгжүүлэлтийн явцад албан ёсны, цаг хугацаа шаардсан баримтжуулсан харилцан үйлчлэлийн журмыг интерактив журмаар солиход чиглэгддэг бөгөөд энэ нь төслийн жижиг хэмжээ, ажилчдын сонгосон чанар, хөгжүүлэгчид болон үйлчлүүлэгчдийг "нэг өрөөнд" байрлуулах, ашиглах боломжтой. чухал бус системүүдэд зориулсан програм хангамжийг хөгжүүлэх.

Програм хангамжийн боловсруулалтыг цөөн тооны мэргэшсэн, тусгай зориулалтын "фенүүд") зарим төрлийн програм хангамжийг хөгжүүлэхэд) тодорхой хэмжээгээр эдгээр зарчмуудын зөв эсэх нь маргахад хэцүү байдаг. Гэсэн хэдий ч Agile технологиуд болон тэдгээрийн үзэл сурталчид үүнийг ерөнхийдөө спираль амьдралын мөчлөгийн загвартай адил тодорхой ангилал, цар хүрээтэй програм хангамжийн төслүүдэд хэрэглэгдэх боломжтой гэдгийг хүлээн зөвшөөрдөг, тухайлбал програм хангамжийн алдаа нь зарим хүндрэл учруулдаг эсвэл нөхөн сэргээгдэх хөрөнгөө алдахад хүргэдэг.

Хэрэв буруу ажиллаж байгаа програм хангамж нь хүний ​​амь насанд аюул заналхийлж, их хэмжээний материаллаг хохирол учруулж байвал програм хангамжийн бүтээгдэхүүний найдвартай байдлыг хангахын тулд бүрэн боловсруулсан, сайтар бодож боловсруулсан технологийг ашиглах ёстой.

Програм хангамжийн төслийн цар хүрээ нэмэгдэхийн хэрээр түүнд оролцох хүмүүсийн тоо нэмэгдэхийн хэрээр програм хангамжийн амьдралын мөчлөгийг бүрдүүлдэг хатуу хөгжлийн технологийн хэрэгцээ нэмэгдэж байна. Хөгжүүлэгчдийн аль нэг нь ямар ч үед алдагдах боломжтой, програм хоорондын харилцаа холбоог албан ёсны болгох, програм хангамжийн өөрчлөлтийн менежмент гэх мэт шаардлагатай байдаг тул энд бичиг баримт шаардлагатай байна.Програм хангамжийн хөгжилд каскадын амьдралын мөчлөгийн загварыг нэвтрүүлсэн нь хоосон биш юм. стандартууд. Үүний зэрэгцээ CTS-ийн дизайн, програм хангамжийг үе шаттайгаар хангасны улмаас давтагдах хөгжлийн үйл явцыг хэрэгжүүлэх боломжтой болгодог.

Маш том програм хангамжийн төслүүдийн хувьд (100 гаруй хөгжүүлэгчид) хөгжүүлэлтийн технологи нь зөвхөн програм хангамжийн чанарт төдийгүй түүнийг бий болгох боломжид нөлөөлдөг гол хүчин зүйл юм.

"Хүнд ба хөнгөн" програм хангамж хөгжүүлэх технологи . Олон төрлийн програм хангамжийг хөгжүүлэгчид хүрхрээний амьдралын мөчлөгийн загварыг хэт зохицуулалттай, хэт баримтжуулсан, хүнд, тиймээс үндэслэлгүй гэж үздэг. Програм хангамж хөгжүүлэх "Хурдан технологи" (хөнгөн технологи) чиглэл байдаг (Agile Software Development) нь эдгээр үзэл бодлын үзэл суртлын үндэслэлийг өгдөг. Эдгээр технологи нь дөрвөн санаан дээр суурилдаг:

1. хувь хүмүүсийн харилцан үйлчлэл нь албан ёсны журам, хэрэглүүрээс илүү чухал,

2. Ажиллаж байгаа програм хангамж нь түүнд зориулсан баримт бичгийн бэлэн байдлаас илүү чухал,

3. Үйлчлүүлэгчтэй хамтран ажиллах нь түүнтэй хийсэн албан ёсны гэрээнээс илүү чухал,

4. Гадны өөрчлөлтөд хурдан хариу өгөх нь төлөвлөгөөг чанд мөрдөхөөс илүү чухал юм.

Гурав дахь зарчмыг эс тооцвол эдгээр зарчмуудын зөв эсэх нь тодорхой хэмжээгээр (програм хангамжийн боловсруулалтыг цөөн тооны мэргэшсэн програмистууд - хяналт, нэмэлт сэдэл шаарддаггүй "фенүүд" гүйцэтгэдэг) програм хангамжийг хөгжүүлэхэд маргаан үүсгэхэд хэцүү байдаг. Гэсэн хэдий ч Agile технологиуд нь тодорхой ангилал, цар хүрээний програм хангамжийн төслүүдэд, мөн ерөнхийдөө спираль амьдралын мөчлөгийн загварт, тухайлбал, програм хангамжийн алдаа нь зарим нэг эвгүй байдалд хүргэдэг эсвэл нөхөн сэргээгдэх хөрөнгөө алддаг, програм хангамжийн програм хангамжийг ашиглахад тохиромжтой байдаг гэдгийг тэдний үзэл сурталчид хүлээн зөвшөөрдөг. Урьдчилан тааруухан тодорхойлсон тул шаардлага байнга өөрчлөгдөж байдаг тул эдгээр өөрчлөлтөд хурдан дасан зохицох шаардлагатай байдаг.

Хурдан технологи -хөгжлийг дагасан бичиг цаасны урсгалыг багасгах нэрийдлээр хөгжлийн хатуу сахилга бат, бүрэн байхгүй байх хоёрын хооронд тохиролцоонд хүрэхийг оролддог.Хөгжүүлэгчийн хариуцлагыг хууль ёсны дагуу баталгаажуулсан бичиг цаасны ажлыг багасгадаг тул хурдан технологи нь програм хангамжийн бүтээгдэхүүний өндөр найдвартай байдлыг хангаж чадахгүй. .

Agile технологийн жишээ бол Extreme Programming (XP) юм. XP дээрх давталт нь маш богино бөгөөд кодлох, турших, үйлчлүүлэгчийг сонсох, дизайн хийх гэсэн дөрвөн үйлдлээс бүрддэг. XP-ийн зарчмууд - минимализм, энгийн байдал, хэрэглэгчийн оролцоо, богино мөчлөгийн хугацаа, хөгжүүлэгчид хоорондын нягт харилцан үйлчлэл - тэд нэг өрөөнд сууж байх ёстой, үйлчлүүлэгчтэй өдөр бүр үйл ажиллагааны уулзалт хийх нь үндэслэлтэй мэт санагдаж, зөвхөн хурдан технологид төдийгүй эртнээс ашиглагдаж ирсэн. XP дээр тэдгээрийг туйлын утгад хүргэдэг.

Програм хангамжийн олон төслүүдэд хийсэн дүн шинжилгээ нь хөгжүүлэгчдийн хувийн чадварыг ашиглахыг чухалчилдаг, өөрийгөө зохион байгуулах зарчмуудыг номлодог хөнгөн технологиуд, спираль загвар, XP, SCRUM зэрэг богино хугацааны хөгжлийн давталтууд түгээмэл байдаг бөгөөд ихэнхдээ амжилтанд хүргэдэг. жижиг багаар ажиллахын ихэнх онцлог.

Хэрэв буруу ажиллаж байгаа программ хангамж нь хүний ​​амь насанд аюул заналхийлж, их хэмжээний материаллаг хохирол учруулж болзошгүй бол дунд зэргийн чадвартай хөгжүүлэгчдийн хувьд ч програм хангамжийн бүтээгдэхүүний найдвартай байдлыг хангахын тулд эмх цэгцтэй, бүрэн бодож боловсруулсан, урьдчилан тооцоолсон албан ёсны "хүнд" технологийг ашиглах ёстой. Програм хангамжийн төслийн цар хүрээ нэмэгдэж, түүнд оролцогчдын тоо нэмэгдэхийн хэрээр програм хангамжийн амьдралын мөчлөгийг бүрдүүлдэг хөгжүүлэлтийн оролцогч бүрийн хариуцлагыг тогтоодог хатуу бөгөөд албан ёсны хөгжлийн технологийн хэрэгцээ нэмэгдэж байна. Хүрхрээний амьдралын мөчлөгийн загварыг програм хангамж хөгжүүлэх стандартад нэвтрүүлсэн нь дэмий хоосон биш юм.

Томоохон хөгжлийн багуудад менежментийн асуудал урган гарч ирдэг.

Маш том програм хангамжийн төслүүдийн хувьд эмх цэгцтэй уялдуулан хөгжүүлэх асуудал: бүтэц зохион байгуулалт, нэгтгэх, программуудын зөв харилцан үйлчлэлийг хангах, зайлшгүй өөрчлөлтийг зөв, уялдаатай зохион байгуулах нь чухал юм. мөн тэдгээрийг бий болгох боломжид нөлөөлдөг.

Жижиг програм хангамжийн төслүүдэд алгоритмын сайжруулалт, хувь хүний ​​​​авьяаслаг хүмүүсийн нөлөө шийдвэрлэх үүрэг гүйцэтгэдэг бол томоохон төслүүдэд эдгээр хүчин зүйлүүд нь жигдэрч, хөгжлийн үйл явцад шийдвэрлэх нөлөө үзүүлдэггүй.

Технологийн сахилга батыг зөв технологийн хүрээнд сахиж, дундаж чадамжтай, олонхи болсон програм хангамж хөгжүүлэгчид шаардлагатай чанарын программ хангамжийг боловсруулах ёстой. "Захиалгатай бай, тэр чамайг сахих болно."

Хүрхрээний загвар Шаардлагын дүн шинжилгээ Зураг төсөл хэрэгжүүлэх Интеграцийн туршилт Бүтээгдэхүүний тодорхойлолтын төсөл боловсруулах Бүтээгдэхүүний архитектурын төсөл боловсруулах Эх кодын боловсруулалт Эх кодын хэсгүүдийг нэгтгэх Туршилт, дибаг хийх

Програм хангамж хөгжүүлэх нэгдсэн үйл явц (USDP) Хэрэглээний жишээ загвар нь ямар тохиолдолд хэрэглүүрийг ашиглахыг тодорхойлдог. Аналитик загвар нь хэрэглээний үндсэн ангиудыг тодорхойлдог. Загварын загвар нь ангиуд болон зориулалтын объектуудын хоорондын холбоо, харилцааг тодорхойлдог.Дэлгэцийн загвар нь программ хангамжийн компьютеруудын тархалтыг тодорхойлдог. Хэрэгжүүлэх загвар нь хөтөлбөрийн кодын дотоод зохион байгуулалтыг тодорхойлдог. Туршилтын загвар нь туршилтын бүрэлдэхүүн хэсэг, туршилтын журам, болон янз бүрийн сонголтуудтуршилт

Ердийн програм хангамжийн бүтээгдэхүүний архитектурын бүрэлдэхүүн хэсгүүд ба ердийн програм хангамжийн шаардлага Хөтөлбөрийн зохион байгуулалт Системийн үндсэн ангиуд Өгөгдлийн зохион байгуулалт Бизнесийн дүрэм Хэрэглэгчийн интерфейс Нөөцийн менежмент Аюулгүй байдал Гүйцэтгэлийн өргөтгөл бусад системтэй харилцах (интеграцчлал) Оролт-гаралтын өгөгдлийг олон улсын болгох, нутагшуулах Алдаа боловсруулах

Ердийн програм хангамжийн бүтээгдэхүүний архитектурын бүрэлдэхүүн хэсгүүд ба ердийн програм хангамжийн шаардлага Алдаа тэсвэрлэх чадвар нь алдааг илрүүлэх, сэргээх, системийн муу үр дагаврыг тусгаарлах замаар системийн найдвартай байдлыг сайжруулдаг системийн шинж чанаруудын багц юм. Гэмтлийг тэсвэрлэх чадварыг хангах аливаа бодит системийг зохион бүтээхдээ системийн доголдолд хүргэж болзошгүй бүх нөхцөл байдлыг урьдчилан харж, эвдрэлийг арилгах механизмыг боловсруулах шаардлагатай. Найдвартай байдал гэдэг нь системийн янз бүрийн эвдрэл, эвдрэлийг тэсвэрлэх чадвар юм. Алдаа гэдэг нь алдааны үр дүнд системийг бүрэн ажиллах боломжгүй байдалд шилжүүлэх явдал юм. Алдаа гэдэг нь системийн эвдрэлд хүргэдэггүй системийн үйл ажиллагааны алдаа юм. Тодорхой хугацаанд алдаа, доголдол бага байх тусам системийг илүү найдвартай гэж үздэг.

Програм хангамжийн бүтээгдэхүүний архитектурын ердийн бүрэлдэхүүн хэсэг ба ердийн програм хангамжийн шаардлага Боловсруулсан архитектурыг хэрэгжүүлэх боломжууд. Боловсруулсан архитектурыг хэрэгжүүлэх боломжууд. илүүдэл функц. илүүдэл функц. Бэлэн програм хангамжийн бүрэлдэхүүн хэсгүүдийг худалдан авах шийдвэр гаргах. Бэлэн програм хангамжийн бүрэлдэхүүн хэсгүүдийг худалдан авах шийдвэр гаргах. Стратегийг өөрчлөх. Стратегийг өөрчлөх.

Хөтөлбөрийн ерөнхий зохион байгуулалтыг тодорхой тусгасан эсэх; тодорхойлолтод архитектурын тойм, түүний үндэслэлийг багтаасан эсэх. Хөтөлбөрийн ерөнхий зохион байгуулалтыг тодорхой тусгасан эсэх; тодорхойлолтод архитектурын тойм, түүний үндэслэлийг багтаасан эсэх. Хөтөлбөрийн үндсэн бүрэлдэхүүн хэсгүүд, тэдгээрийн хариуцах чиглэл, бусад бүрэлдэхүүн хэсгүүдтэй харилцах харилцааг зохих ёсоор тодорхойлсон эсэх. Хөтөлбөрийн үндсэн бүрэлдэхүүн хэсгүүд, тэдгээрийн хариуцах чиглэл, бусад бүрэлдэхүүн хэсгүүдтэй харилцах харилцааг зохих ёсоор тодорхойлсон эсэх. Шаардлагын тодорхойлолтод заасан бүх функцийг боломжийн тооны системийн бүрэлдэхүүн хэсгүүдээр хангаж байгаа эсэх. Шаардлагын тодорхойлолтод заасан бүх функцийг боломжийн тооны системийн бүрэлдэхүүн хэсгүүдээр хангаж байгаа эсэх. Хамгийн чухал ангиудыг тайлбарлаж, зөвтгөсөн байна. Хамгийн чухал ангиудыг тайлбарлаж, зөвтгөсөн байна. Мэдээллийн сангийн зохион байгуулалтын тодорхойлолтыг өгсөн эсэх. Мэдээллийн сангийн зохион байгуулалтын тодорхойлолтыг өгсөн эсэх. Бизнесийн бүх дүрмийг тодорхойлсон уу? Бизнесийн бүх дүрмийг тодорхойлсон уу? Тэдний системд үзүүлэх нөлөөг тайлбарласан уу? Тэдний системд үзүүлэх нөлөөг тайлбарласан уу? Архитектурын чанарын талаар дүгнэлт гаргах боломжийг олгодог асуултуудын жагсаалт:

Архитектурын чанарын талаар дүгнэлт хийх боломжийг олгодог асуултуудын жагсаалт: Хэрэглэгчийн интерфейсийн дизайны стратегийг тодорхойлсон уу. Хэрэглэгчийн интерфейсийн дизайны стратегийг тодорхойлсон эсэх. Хэрэглэгчийн интерфэйс нь модульчлагдсан байх нь түүнд өөрчлөлт оруулах нь системийн бусад хэсэгт нөлөөлөхгүй. Хэрэглэгчийн интерфэйс нь модульчлагдсан байх нь түүнд өөрчлөлт оруулах нь системийн бусад хэсэгт нөлөөлөхгүй. I/O стратегийн тайлбарыг өгсөн эсэх. I/O стратегийн тайлбарыг өгсөн эсэх. Энэхүү архитектурыг ашиглан хэрэгжүүлэх системийн гүйцэтгэлийн шинжилгээг хийсэн эсэх. Энэхүү архитектурыг ашиглан хэрэгжүүлэх системийн гүйцэтгэлийн шинжилгээг хийсэн эсэх. Төлөвлөсөн системийн найдвартай байдлын шинжилгээг хийсэн үү? Төлөвлөсөн системийн найдвартай байдлын шинжилгээг хийсэн үү? Системийн өргөтгөх, өргөтгөх чадварт дүн шинжилгээ хийсэн үү? Системийн өргөтгөх, өргөтгөх чадварт дүн шинжилгээ хийсэн үү?

Програм хангамжийн рефакторын код давтагдсан; аргын хэрэгжилт хэт том; гогцоонуудын хэт их үүрлэх, эсвэл гогцоо өөрөө маш том; Анги нь холболт муутай (Ангийн шинж чанар, аргууд нь зөвхөн 1 объектыг тайлбарлах ёстой); ангийн интерфейс нь тууштай хийсвэрлэл үүсгэдэггүй; арга нь хэт олон параметрүүдийг авдаг. Та параметрийн тоог боломжийн хамгийн бага хэмжээнд байлгахыг хичээх хэрэгтэй; ангийн бие даасан хэсгүүд нь ангийн бусад хэсгээс үл хамааран өөрчлөгддөг; Рефакторинг гэдэг нь програм хангамжийг шинэ хувилбарт тохируулах явдал юм техник хангамжмөн шинэ үйлдлийн системүүд, шинэ хөгжүүлэлтийн хэрэгслүүд, шинэ шаардлага, програм хангамжийн бүтэц, үйл ажиллагаа. Энэ нь програм хангамжийн өөрчлөлтийг хангах зорилготой програм хангамжийн дотоод бүтцэд түүний гадаад байдлыг өөрчлөхгүйгээр өөрчлөлт хийх явдал юм. Дахин засварлах үндэслэлтэй шалтгаанууд:

Хөтөлбөрийг өөрчлөх үед програм хангамжийн рефакторинг нь хэд хэдэн ангиудын зэрэгцээ өөрчлөлтийг шаарддаг. Хэрэв ийм нөхцөл байдал үүсвэл ирээдүйд гарч болзошгүй өөрчлөлтүүдийн газрыг багасгахын тулд ангиудыг дахин зохион байгуулах шаардлагатай; хэд хэдэн өв залгамжлалын шатлалыг зэрэгцүүлэн өөрчлөх шаардлагатай; та хэд хэдэн кейс блокуудыг өөрчлөх хэрэгтэй. Програмыг кейс блокийн хэрэгжилтийг хийх байдлаар өөрчлөх шаардлагатай бөгөөд үүнийг хөтөлбөрт шаардлагатай тооны удаа нэрлэх; Хамтдаа ашигласан холбогдох өгөгдлийн гишүүдийг анги болгон зохион байгуулдаггүй. Хэрэв та ижил өгөгдлийн элементүүдийг олон удаа ашигладаг бол эдгээр өгөгдлийг нэгтгэж, тэдгээрт гүйцэтгэсэн үйлдлүүдийг тусдаа ангид байрлуулахыг зөвлөж байна;

Програм хангамжийн рефакторын арга нь өөр ангиас илүү олон элементийг ашигладаг. Энэ нь аргыг өөр анги руу шилжүүлж, хуучин ангиас нь дуудах шаардлагатай гэсэн үг юм; энгийн өгөгдлийн төрөл хэт ачаалалтай байна. Бодит ертөнцийн мөн чанарыг тайлбарлахын тулд одоо байгаа өгөгдлийн төрлийг хэт ачаалахаас илүү класс ашиглах нь дээр; Анги нь хэт хязгаарлагдмал функцтэй. Функцийг нь өөр анги руу шилжүүлэх замаар энэ ангиас салах нь дээр; "тэнэмэл" өгөгдөл нь аргын гинжин хэлхээний дагуу дамждаг. Зөвхөн өөр арга руу дамжуулахын тулд арга руу дамжуулж байгаа өгөгдлийг төөрөгдөл гэж нэрлэдэг. Ийм нөхцөл байдал үүссэн тохиолдолд ангиудын архитектур, арга барилыг өөрчлөхийг хичээгээрэй.

Медиа объектыг дахин засварлах нь юу ч хийхгүй. Хэрэв ангийн үүрэг бол аргын дуудлагыг бусад анги руу чиглүүлэх юм бол тэр проксиг устгаад бусад анги руу шууд дуудлага хийх нь дээр. нэг анги нөгөө ангийн талаар хэтэрхий их мэддэг. Энэ нөхцөлд өв залгамжлагч эцэг эхийнхээ талаар хамгийн бага мэдлэгтэй байхын тулд бүрээсийг илүү хатуу болгох шаардлагатай; арга нь харамсалтай нэртэй байдаг; өгөгдлийн гишүүд олон нийтэд нээлттэй. Энэ нь интерфэйс болон хэрэгжилтийн хоорондох шугамыг бүдгэрүүлж, капсулжуулалтыг зайлшгүй эвдэж, програмын уян хатан байдлыг хязгаарладаг; эх кодонд тайлбар оруулах;

Програм хангамжийг дахин боловсруулах дэд анги нь өвөг дээдсийнхээ аргын багахан хэсгийг л ашигладаг. Энэ нөхцөл байдал нь зөвхөн үндсэн ангиас цөөн хэдэн аргыг өвлөн авахын тулд шинэ анги үүсгэсэн тохиолдолд тохиолддог бөгөөд ямар нэгэн шинэ объектыг дүрслэхийн тулд биш юм. Үүнээс зайлсхийхийн тулд үндсэн ангиудыг шинэ ангид зөвхөн өөрт хэрэгтэй аргуудаар хандах боломжийг олгох байдлаар өөрчлөх шаардлагатай; код нь глобал хувьсагчдыг агуулна. Зөвхөн программыг бүхэлд нь ашигладаг хувьсагч нь глобал байх ёстой. Бусад бүх хувьсагч нь локал байх эсвэл зарим объектын шинж чанар болох ёстой; программ нь хэзээ нэгэн цагт хэрэг болох кодыг агуулдаг. Системийг боловсруулахдаа ирээдүйд эх код нэмэх боломжтой газруудыг зааж өгөх нь зүйтэй.

1. Програмчлалын технологийн зорилго. Програмчлалын технологийн хөгжлийн түүх. Програм хангамжийн төслийн төрлүүд. Програмчлалын технологийн бүрэлдэхүүн хэсгүүд. Төсөл, бүтээгдэхүүн, үйл явц, хүмүүс

2. Хөтөлбөрийн амьдралын мөчлөг. Хөгжлийн мөчлөгийн шинж чанар. Програмчлалын технологийн үндсэн ойлголтууд. Процесс ба загварууд. Үе шат ба эргэлтүүд. Чухал үе ба олдворууд. Оролцогч талууд ба ажилчид.

3. Шаардлагуудыг тодорхойлох, дүн шинжилгээ хийх. Програм хангамжийн шаардлага. Шаардлага боловсруулах схем. Шаардлагын менежмент.

4. Архитектур, нарийвчилсан зураг төсөл. Хэрэгжилт ба кодчилол. Туршилт ба баталгаажуулалт. Чанарын хяналтын үйл явц. Цагаан хайрцаг ба хар хайрцагны аргууд. Хяналт, шалгалт. Туршилтын зорилго. Баталгаажуулалт, баталгаажуулалт ба системийн туршилт. Засвар үйлчилгээ, тасралтгүй хөгжүүлэлт.

5. Хөгжлийн үйл явцын загварууд. Хүрхрээ ба конвейерийн загварууд. Спираль болон нэмэгдэл загварууд. Хөгжлийн үйл явцын уян хатан загварууд.

6. Үйл явцын загвар зохион бүтээх. Үйл явцын шаардлагыг тодорхойлох. Ашигласан үе шат, үе шат, олдворууд. Процессын архитектурын сонголт. Ердийн төслийг хэрэгжүүлэх журам. баримтжуулсан журам.

7. Хөгжлийн багийн загварууд. Хөгжлийн хамтын шинж чанар. Багийн оновчтой хэмжээ. Төсөлд оролцогчдыг захирах. Багийн хөгжил, боловсон хүчний хөгжил. Мэргэшсэн байдал, хамтын ажиллагаа, харилцан үйлчлэл.

8. Хөгжлийн багийн загварууд. Багийн шаталсан загвар. Мэс заслын багийн арга. Тэнцүү багийн загвар.

9. Програмчлалын мөн чанар. Програмчлалын шинжлэх ухаан. Програмчлалын урлаг. Програмчлалын гар урлал. програмчлалын парадигмууд. Бүтцийн програмчлал. Логик програмчлал. Объект хандалтат програмчлал.

10. Програм хангамжийн архитектур. Үйл явдлын менежмент. Үйлчлүүлэгч/серверийн архитектур. Үйлчилгээ. гурван давхар архитектур. Хөтөлбөрийн дизайн. Концепцийн дизайн. Логик дизайн. Нарийвчилсан дизайн.

1. Новиков програм хангамжийг хөгжүүлэх хандлага” http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Экстрим програмчлал. - Санкт-Петербург: Петр, 2002.

3. Програм хангамж боловсруулах технологи. - Санкт-Петербург. : Петр, 2004.

4. Брукс Жр. програм хангамжийн системийг зохион бүтээж, бүтээдэг. Москва: Наука, 1975; Орчуулгын шинэ хэвлэл: Домогт хүн-сар. Санкт-Петербург: СИМБОЛ+, 1999 он.

5. Алгоритм + өгөгдлийн бүтэц = программ. М., Мир, 1978.

6. Системчилсэн програмчлал. Оршил. М.: Мир, 1977.

7. Бүтцийн програмчлал. М .: Мир, 1975.

8. Програмчлалын сахилга бат. М .: Мир, 1978.

9. Програм хангамж боловсруулах технологи. - Санкт-Петербург: Петр, 2002.

10. Тереховын программчлал. М.: БИНОМ, 2006 он.

11. Rambo J. Нэгдсэн програм хангамж боловсруулах үйл явц. Санкт-Петербург: Петр, 2002.

Менежерүүдэд зориулсан эдийн засгийн онол

Микро эдийн засгийн үндсэн онолууд. Эдийн засгийн үйл явцын шинжилгээнд хэрэглэх жишээ. Макро эдийн засгийн үндсэн онолууд. Эдийн засгийн үйл явцын шинжилгээнд хэрэглэх жишээ. Эдийн засгийн үйл явцыг удирдах зарчим, арга. Эдийн засгийн үйл явцын хөгжлийн түвшинг үнэлэх хэрэгслүүд Өргөтгөсөн нөхөн үйлдвэрлэлийн асуудлууд. Оросын эдийн засгийн өсөлтийн хүчин зүйлүүд. Тогтвортой хөгжлийн шалгуур үзүүлэлтүүд. Циклийн хэлбэлзлийг жигдрүүлэх. Эдийн засгийн хөгжлийн хурдыг үнэлэхэд үржүүлэгч ба хурдасгуурын үүрэг. Эдийн засаг дахь үйлдвэрлэлийн чиг үүрэг. Эдийн засгийн үйл явцын шинжилгээнд хэрэглэх жишээ. Ашиг. Ашигт нөлөөлж буй үзүүлэлтүүдийн тооцоо, алдагдалгүй байдлын цэгийн график дүрслэл. Хөрөнгө оруулалтын бодлогыг хэрэгжүүлэх арга зүй.

Эдийн засгийн онолын хичээл: их дээд сургуулиудад зориулсан сурах бичиг / Ed. . -Киров: "ACA", 2004. Колемаев - математик загварчлал. Макро эдийн засгийн үйл явц ба тогтолцооны загварчлал: сурах бичиг. М.: НЭГДЭЛ-ДАНА, 2005. Бажин кибернетик. Харьков: Консул, 2004. Леушиний математик загварчлалын аргын семинар: сурах бичиг. Нижний Новгород муж технологи. их сургууль - Н.Новроод, 2007. Эдийн засгийн тухай улс төрчид: Эдийн засгийн чиглэлээр Нобелийн шагналтнуудын лекц. Москва: Орчин үеийн эдийн засаг ба хууль, 2005. Черемных. Ахисан түвшин: Сурах бичиг.-М.:ИНФРА-М, 2008. Мини-эдийн засгийн байгууллагуудын хувьсал. ОХУ-ын ШУА-ийн Уралын салбарын Эдийн засгийн хүрээлэн, - М.: Наука, 2007.

Удирдлагын шийдвэрийг боловсруулах, батлах технологи [N]

Шийдвэр гаргах нь менежерийн үйл ажиллагааны үндэс юм. Шийдвэрийн онолын танилцуулга. Шийдвэрлэх онолын үндсэн ойлголтууд. Бизнесийн удирдлагын загвар ба тэдгээрийн шийдвэр гаргахад үзүүлэх нөлөө. Янз бүрийн арга замуудшийдлийн ангилал. Ангилал: албан ёсны зэрэг, хэвшлийн зэрэг, давтамж, яаралтай, зорилгодоо хүрэх зэрэг, хувилбар сонгох аргын дагуу. Шийдвэр гаргах үндсэн аргууд. Шийдвэр гаргах сайн дурын аргууд. Шийдвэр гаргах зорилго. Шийдэл олох цаг. Үндсэн алдаа Шийдвэр гаргах математик аргууд. Шийдвэр гаргах онолын математикийн талууд. Үйл ажиллагааны судалгаа. Шийдвэр гаргах математик хандлага. Шийдвэрийн мод. Шийдвэр гаргах, хөгжүүлэх загварууд. Тоглоомын онол. Шийдвэр гаргах математик аргууд. Шийдвэр гаргах онолын математикийн талууд. Дарааллын онолын загварууд. Бараа материалын менежментийн загварууд. Шугаман програмчлалын загвар. тээврийн даалгавар. Симуляцийн загварчлал. Сүлжээний шинжилгээ. Эдийн засгийн шинжилгээ. Рационал загваруудын хязгаарлалт. Бүлэг дэх хөгжлийн болон шийдвэр гаргах онцлог. Олонлогуудын холболтын зэрэг дээр үндэслэн бүлгийн уялдаа холбоог тодорхойлох арга. Хамтын шийдвэр гаргах арга. зөвшилцлийн арга. санал өгөх арга. Шийдвэр гаргах бүтээлч аргууд. Оюуны шуурга. Санаачдын бага хурал. Усан онгоцны зөвлөл. Де Боногийн "Сэтгэцийн малгай" арга. Шинэ бүтээлийн асуудлыг шийдвэрлэх онол (TRIZ). Төгсгөлийн хамгийн тохиромжтой шийдэл. TRIZ ашиглан асуудал, тэдгээрийг шийдвэрлэх жишээ. Өвөрмөц, бүтээлч шийдвэр гаргахад TRIZ аргыг ашиглах. Шийдлийн санааг боловсруулах, нөхцөл байдалд тохируулах арга. Зорилтот модны загвар. Ашиг сонирхлыг зохицуулах стратеги. Ашиг сонирхлыг зохицуулах шийдвэр гаргах. Харьцагч талуудын ашиг сонирхлыг тодорхойлох арга. Шийдвэр гаргахад дэмжлэг үзүүлэх систем (шинжээчдийн систем). Шийдвэр гаргах тогтолцоо бий болсон түүх. Шийдвэр гаргах системийн ангилал. Эксперт системийн ердийн бүтэц. Мэдлэгийг илэрхийлэх арга замууд. Логик дүгнэлт хийх аргууд. Эксперт системийг практикт ашиглах.

I. Шийдвэр гаргах онол: сурах бичиг. - М .: Шалгалт, 2006. - 573 х. I. Шийдвэр гаргах. Удирдлагын шийдвэр боловсруулах онол, арга. Заавар. - М.: 3-р сар, 2005. - 496 х. Удирдлагын шийдвэр боловсруулах - М.: Дело хэвлэлийн газар, 2004 - 392 х. G. Шинжээчдийн үнэлгээ, шийдвэр гаргах.- М .: Патент, 1996. - 271 х. Таха // Үйл ажиллагааны судалгааны танилцуулга = Үйл ажиллагааны судалгаа: Танилцуулга. - 7 дахь хэвлэл. - М.: "Уильямс", 2007. - S. 549-594. Г.Тейл. Эдийн засгийн таамаглал, шийдвэр гаргах. М.: Прогресс, 1970. К.Д.Льюис. Эдийн засгийн үзүүлэлтүүдийг урьдчилан таамаглах арга. М.: "Санхүү ба статистик" 1986. Г.С.Килдишев, А.А.Френкель. Хугацааны цувааны дүн шинжилгээ, прогноз. М.: "Статистик" 1973. О.Ким, К.В.Мюллер, В.Р.Клекка нар Фактор, дискриминант, кластерийн шинжилгээ. М.: "Санхүү, статистик" 1989. Үр дүнтэй менежер. Ном 3. Шийдвэр гаргах. - MIM LINK, 1999 Туревский ба авто тээврийн аж ахуйн нэгжийн удирдлага. - М.: төгссөн сургууль, 2005. , ; ed. . Менежмент дэх системийн шинжилгээ: заавар. - М .: Санхүү, статистик, 2006. , Тинков: сурах бичиг. - М.: КНОРУС, 2006 он.

Нэгдсэн удирдлагын систем дэх бизнесийн үйл явцыг загварчлах

Бизнесийн үйл явцын зарчим юу вэ? Бизнесийн үйл явцыг цогцоор нь тайлбарлах асуудал юу вэ. Систем гэж юу вэ, энэ нь ямар шинж чанартай вэ? Бизнесийн үйл явцыг загварчлахад системийн шинжилгээний үүрэг юу вэ? Хяналтын объект болох үйл явц. Процессын орчин. Бизнесийн үйл явцын үндсэн элементүүд. Функциональ ба үйл явцын удирдлагын давуу болон сул талууд. PDCA удирдлагын мөчлөг. Процессын удирдлагын мөчлөгийн үе шатууд. PDCA мөчлөг ба ISO 9001:2008 стандартын шаардлагыг хэрэгжүүлэх. SADT арга зүй (Бүтцийн шинжилгээ ба дизайны техник - бүтцийн шинжилгээ, дизайны арга). Мөн чанар. Үндсэн заалтууд. IDEF0 аргачлалд үйл ажиллагааны функциональ загварыг хэрхэн харуулсан бэ? Функциональ загварын диаграммууд нь юу гэсэн үг вэ, тэдгээрийг IDEF0 аргачлалын дагуу хэрхэн харуулсан бэ? Функциональ загварын диаграмм дахь сумнууд нь юу вэ, тэдгээрийн төрөл, төрлүүд юу вэ? DFD арга зүй. Мөн чанар. DFD графикийн үндсэн бүрэлдэхүүн хэсгүүд. DFD-диаграммын онцлог шинж чанарууд юу вэ, тэдгээрт юу тайлбарласан бэ? DFD-диаграмын объектуудын онцлог юу вэ? DFD диаграм дээрх сумнууд юуг илэрхийлж байна вэ? IDEF3 аргачлал. Мөн чанар. Баримтжуулалт, загварчлалын хэрэгсэл. IDEF3 диаграммын онцлог шинж чанарууд юу вэ, тэд юуг дүрсэлсэн бэ? IDEF3 диаграммын объектуудын онцлог юу вэ? Тэгээд буудагч уу? Процессын ангилал. Ердийн бизнесийн үйл явц. Реинженеринг ба түүний технологи. Компанийн удирдлагад реинженеринг ашиглах нь хэзээ тохиромжтой вэ? Үйл явцыг хянах, хэмжих. Байгууллагын үйл явцын үзүүлэлтүүд. Үйл явцын тоон болон үнэлгээний үнэлгээ.

"AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI ашиглан бизнесийн үйл явцыг загварчлах" 2003 "AllFusion Modeling Suite ашиглан мэдээллийн системийг бий болгох" хэвлэл. "Dialogue-MEPhI" 2003 "AllFusion Process Modeler 4.1-тэй функциональ загварчлалын практик. (BPwin) Хаана? Яагаад? Хэрхэн?" ed. "Dialogue-MEPhI" 2004 Dubeikovsky AllFusion Process Modeler (BPwin)-ийн загварчлал. ed. "Диалог-MEPhI" 2007 Д.Марк, К.Макгоуэн "Бүтцийн шинжилгээ ба дизайны SADT арга зүй" 1993 он SADT арга зүйн сонгодог бүтээл. Черемных системийн шинжилгээ: IDEF-технологи, Системийн загварчлал, дүн шинжилгээ. IDEF технологи. Семинар. М.: Санхүү ба статистик, 2001. , “Бүтцийн бизнесийн загварууд: DFD-технологи” http://www. /Level4.asp? ItemId=5810 "Бизнесийн үйл явцыг өөрчлөн зохион байгуулах онол практик"2003/ P50.1.. Функциональ загварчлалын арга зүй. Москва: ОХУ-ын Госстандарт, 2000. http://www. IDEF0, IDEF3, DFD http://www. BPwin-ийн тусламжтайгаар бизнесийн үйл явцыг загварчлах http://www. /department/se/devis/7/ Бизнесийн үйл явцын загварчлалын менежмент дэх IDEF0 http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Програм хангамжийн бүтээгдэхүүний үр ашгийг үнэлэх

1. Мэдээллийн технологийн архитектур

2. Удирдлагын үйл явцын хүрээ.

3. Домэйн төлөвлөлт, зохион байгуулалтын үйл явцын жагсаалт

4. Домэйн процессуудын жагсаалт Худалдан авалт ба Хэрэгжилт

5. Үйл ажиллагаа ба засвар үйлчилгээ домэйн дэх процессуудын жагсаалт

6. Хяналт-шинжилгээ, үнэлгээний домайн дахь үйл явцын жагсаалт

7. Үйл явцын төлөвшлийн загварын түвшинүүдийн шинж чанар

9. KPI ба KGI тэдгээрийн хамаарал, зорилго

1. 10. Мэдээллийн технологийн ерөнхий хяналт ба хэрэглээний хяналт. Бизнесийн болон мэдээллийн технологийн хариуцлагын чиглэл, хариуцлагын чиглэл.

Cobit 4.1 орос хувилбар.

Оюуны өмчийг бий болгох, ашиглах эрх зүйн зохицуулалт

1. Оюуны үйл ажиллагааны үр дүнгийн оюуны өмчийн эрхийг жагсааж, агуулгыг нь ил тод болгоно.

2. Онцгой эрхийг захиран зарцуулах гэрээний төрлийг жагсаа. Онцгой эрхийг захиран зарцуулах гэрээ тус бүрийг тайлбарлана уу.

4. Компьютерийн программыг зохиогчийн эрхийн объект болох эрх зүйн хамгаалалтын үндсэн заалтуудыг тайлбарлана уу.

5. Мэдээллийн санг зохиогчийн эрхийн объект болон түүнтэй холбоотой эрхийн объектын хувьд эрх зүйн хувьд хамгаалах үндсэн заалтуудыг харьцуулна уу.

6. Патентийн эрхийн объектуудын патентын чадварын нөхцөлийг тодорхойлно уу: шинэ бүтээл; ашигтай загварууд; аж үйлдвэрийн загвар.

7. Шинэ бүтээлийн агуулгыг өргөжүүлэх патентын чадварын шалгуур: шинэлэг байдал; зохион бүтээх алхам; аж үйлдвэрийн хэрэглээ.

8. Шинэ бүтээл, ашигтай загвар, үйлдвэрлэлийн загварт патент авах нөхцөл, журам, түүнчлэн патентын хүчинтэй байх нөхцөл, түүний үргэлжлэх хугацааг тодорхойлно.

9. "Ноу-хау"-ны тодорхойлолтыг гаргаж, үйлдвэрлэлийн нууцын хууль эрх зүйн хамгаалалт үүсэх, хэрэгжих нөхцөлийг жагсаа.

10. Хувьчлах хамгаалалттай арга хэрэгслийг жагсааж, тэдгээрийн харьцуулсан шинж чанарыг өг.

1., ОХУ-ын оюуны өмчийн хууль, сурах бичиг // М, Проспект, 2007

2., Оюуны өмчийн эрх зүй, сурах бичиг // М, RIOR, 2009

Төслийн удирдлага ба програм хангамж хөгжүүлэлт [R]

Арга зүй гэж юу вэ, яагаад хэрэгтэй вэ. Арга зүйн ерөнхий бүтэц, арга зүйн үндсэн элементүүд. Өөрийнхөө арга зүй зохиох зарчим. Төрөл бүрийн олдвор, үүрэг, чадвар, хилийн нөхцлийн жишээ. Cowburn арга зүйн бүтэц, арга зүйн хэмжүүр. Коуберн төслийн шалгуур. Арга зүйг сонгох шалгуур, Коуберн матриц. Төслийн амьдралын мөчлөг. Хүрхрээ ба давтагдах амьдралын мөчлөгийн загварууд. Хүрхрээ болон давталтын загварт хэрэглэх боломжийн хязгаар. RUP нь давтагдах аргын жишээ болгон. RUP-ийн үндсэн ойлголтууд, хэрэглэх боломжийн хязгаар. Програм хангамж боловсруулахад хүний ​​үүрэг. Agile арга зүй, Agile арга зүйн үндсэн зарчим. Agile арга зүйн гарал үүсэл. Agile арга зүйн жишээ болгон Scrum. Scrum дахь үүрэг, олдвор, үйл ажиллагаа. Scrum-ийн хэрэглээний хязгаар. Extreme Programming (XP) Санаа, үнэ цэнэ, үндсэн дадал зуршил, хэрэглэх боломжийн хязгаар. Scrum болон XP хоёрын ижил төстэй ба ялгаа. Шаардлагуудыг цуглуулах, удирдах. Үндсэн практик, нэр томъёо, зарчим. Төсөл, бүтээгдэхүүнийг баримтжуулах арга барил, баримт бичгийн үндсэн төрлүүд. Хичээлээр хэлэлцсэн арга зүйгээс шаардлагын менежментийн туршлагын жишээ. Програм хангамж хөгжүүлэх төлөвлөлт. Төлөвлөгөөний төрлүүд, эрсдэлийн удирдлага, түгээмэл эрсдэлүүд. Хичээлээр хэлэлцсэн арга зүйгээс хөгжлийн төлөвлөлтийн туршлагын жишээ. Програм хангамж боловсруулахад туршилт хийх. Програм хангамжийн бүтээгдэхүүнийг угсрах (бүтээх) тухай ойлголт. Туршилтын үндсэн аргууд, нэр томъёо. Хичээл дээр хэлэлцсэн аргачлалаас туршилтын туршлагын жишээ. Угсрах тухай ойлголт (бүтээл), код хадгалах арга зам, багаж хэрэгсэл. Хувилбарын хяналтын системтэй ажиллах ажлыг зохион байгуулах хоёр зарчим. Төрөл бүрийн бүтээгдэхүүний ангилалд зориулсан бүтээгдэхүүн гаргах/бүтээгдэхүүний үйл явцын онцлог, туршлагын жишээ. Програм хангамжийн архитектурын орчин үеийн ойлголтууд, олон түвшний архитектурууд, архитектурын шалгуурууд. Програм хангамжийг боловсруулахад шаардлагатай шийдвэрүүдийн жагсаалт, өгөгдөл хадгалах системийг сонгох хандлага.

Кент Бек - Хэт их програмчлал Фредерик Брукс - Домогт хүн-сар буюу тэд хэрхэн бүтээгдсэн бэ програм хангамжийн системүүд. Том де Марко - Эцсийн хугацаа. Төслийн менежментийн тухай роман. Том де Марко, Тимоти Листер - Баавгайтай вальс. Том де Марко, Тимоти Листер - Хүний хүчин зүйл_ амжилттай төсөл, багууд. Alistair Cowburn - Төсөл бүр өөрийн гэсэн аргачлалтай. Alistair Cowburn - Хүмүүс шугаман бус бөгөөд програм хангамж боловсруулахад хамгийн чухал бүрэлдэхүүн хэсэг юм. Андрей Орлов - Автомататорын тэмдэглэл. Мэргэжлийн мэдүүлэг. Филип Крахтен - оновчтой нэгдсэн үйл явцын танилцуулга. Хенрик Книберг - Скрум ба XP: тэргүүн эгнээний тэмдэглэл. Курсын лекцийн илтгэлүүд

Компьютерийн шинжлэх ухаан, кибернетик, програмчлал

Давталт N USDP Програм хангамжийн нэгдсэн хөгжүүлэлтийн процесс Хэрэглээний жишээ загвар нь тухайн програмыг ашиглах тохиолдлуудыг тодорхойлдог. Аналитик загвар нь хэрэглээний үндсэн ангиудыг тодорхойлдог. Загварын загвар нь ангиуд болон зориулалтын объектуудын хоорондын холбоо, харилцааг тодорхойлдог.Дэлгэцийн загвар нь программ хангамжийн компьютеруудын тархалтыг тодорхойлдог.

Хичээл №20
Програм хангамж хөгжүүлэх ерөнхий зарчим, арга барил

Програм хангамж хөгжүүлэх загварууд

1. Водопадная
2. Каскадын загвар
3. Спираль
4. Экстрим програмчлал
5. нэмэгдэл
6. MSF арга зүй

хүрхрээ загвар

спираль загвар

Өсөн нэмэгдэж буй хөгжил

Шаардлагын дүн шинжилгээ

Дизайн

Хэрэгжилт

Бүрэлдэхүүн хэсэг

туршилт

Интеграци

Туршилт хийх

бүхэлд нь

Давталт 1 Давталт 2 …. Давталт Н

Програм хангамж хөгжүүлэх нэгдсэн үйл явц (USDP)

1. Хэрэглээний кейс загвар нь програмыг ашиглах тохиолдлуудыг тодорхойлдог.
2. Аналитик загвар нь хэрэглээний үндсэн ангиудыг тодорхойлдог.
3. Загварын загвар нь ангиуд болон сонгосон объектуудын хоорондын холбоо, харилцааг тодорхойлдог
4. Байршуулах загвар нь программ хангамжийн компьютер хоорондын тархалтыг тодорхойлдог.
5. Хэрэгжүүлэх загвар нь хөтөлбөрийн кодын дотоод зохион байгуулалтыг тодорхойлдог.
6. Туршилтын загвар нь туршилтын бүрэлдэхүүн хэсгүүд, туршилтын журам, янз бүрийн туршилтын тохиолдлуудаас бүрдэнэ.

MSF арга зүй

Ердийн програм хангамжийн бүтээгдэхүүний архитектурын бүрэлдэхүүн хэсгүүд ба ердийн програм хангамжийн шаардлага

алдааг тэсвэрлэх чадвар- алдааг илрүүлэх, системийн сөрөг үр дагаврыг сэргээх, нутагшуулах замаар түүний найдвартай байдлыг нэмэгдүүлдэг системийн шинж чанаруудын багц. Гэмтлийг тэсвэрлэх чадварыг хангах аливаа бодит системийг зохион бүтээхдээ системийн доголдолд хүргэж болзошгүй бүх нөхцөл байдлыг урьдчилан харж, эвдрэлийг арилгах механизмыг боловсруулах шаардлагатай.

Найдвартай байдал - системийн янз бүрийн эвдрэл, эвдрэлийг тэсвэрлэх чадвар.

Татгалзах системийн шилжилт юмалдааны үр дүнд бүрэн ажиллах боломжгүй байдалд хүргэсэн.

сүйрэл - системийн үйл ажиллагааны алдаа нь системийн эвдрэлд хүргэдэггүй.

Тодорхой хугацаанд алдаа, доголдол бага байх тусам системийг илүү найдвартай гэж үздэг.

Мөн таны сонирхлыг татахуйц бусад бүтээлүүд
57355.		Органик нэгдлүүдийн төрөл зүйл, тэдгээрийн ангилал. Байгалийн органик бодисууд	48.5 КБ
	Органик нэгдлүүдийн олон янз байдал нь нүүрстөрөгчийн атомууд хоорондоо энгийн бөгөөд олон төрлийн холбоогоор нэгдэж, гинж, цикл, унадаг дугуй, гурван дугуй, полицикл, хүрээ гэх мэт бараг хязгааргүй тооны атом бүхий нэгдлүүдийг үүсгэх өвөрмөц чадвараар тодорхойлогддог.
57359.		Аман мэдээллийн загварыг боловсруулах	291 КБ
	Үндсэн ойлголтууд: загвар; мэдээллийн загвар; аман мэдээллийн загвар; тайлбар; хийсвэр. Тайлбар Лат хэлнээс товчлол. 2-ын тоймыг үүсгэ. Баримт бичгийг өөрийн хавтсанд Abstract нэрээр хадгална.
57361.		Тоо ба дугаар 3. Хил дээр байгаа тоог хослуулах 3. Бичсэн тоо 3. Хуучин зүйлсийг хослуулах	35.5 КБ
	Бүх амьтдын тоо хэн нь хамгийн түрүүнд байх ёстой вэ? Хэн нь хамгийн сүүлд байх ёстой вэ? Сусид баруун гарт хэрэм хэн бэ Сусид зүүн гарт анааш гэж хэн бэ

Програм хангамж хөгжүүлэх загварууд байдаг. Мөн аргачлалууд байдаг. Интернетэд юу вэ, тэдгээрийг хэрхэн ялгах талаар олон зөрчилтэй мэдээлэл байдаг. Эхлэгчдэд үүнийг ойлгоход хэцүү байж болно. Энэ нийтлэлд бид i-г цэг тавих болно.

Програм хангамжийн амьдралын мөчлөгийн үе шатууд

Аливаа програм хангамж нь бүтээгдсэнээс эхлээд боловсруулалт, хэрэгжилтийн төгсгөл хүртэлх амьдралын мөчлөгтэй байдаг. Ихэнхдээ энэ нь бэлтгэл, дизайн, бүтээн байгуулалт, дэмжлэг юм. Үе шатуудыг өөр өөрөөр нэрлэж болох бөгөөд жижиг үе шатанд хувааж болно.

Онлайн дэлгүүрийн амьдралын мөчлөгийн жишээн дээр эдгээр үе шатуудыг авч үзье.

Сургалт.Иван онлайн номын дэлгүүр нээхээр шийдэж, сүлжээнд ямар ижил төстэй сайтууд байгааг шинжилж эхлэв. Тэдний урсгал, үйл ажиллагааны талаархи мэдээллийг цуглуулсан.

Дизайн.Иван гэрээлэгчийг сонгож, мэргэжилтнүүдтэйгээ ирээдүйн онлайн дэлгүүрийн архитектур, дизайны талаар ярилцав.

Бүтээл.Иван хөгжүүлэгчидтэй гэрээ байгуулав. Тэд код бичиж, дизайн зурж, баримт бичгийг бичиж эхлэв.

Дэмжлэг.Иван хүлээн авах гэрчилгээнд гарын үсэг зурж, гүйцэтгэгч онлайн дэлгүүрийг "байлдааны" серверүүд дээр байрлуулсан. Хэрэглэгчид үүн дээр зочилж, дэмжлэг үзүүлэхийн тулд алдааны талаар мэдээлж, программистууд бүгдийг хурдан засч эхлэв.

ЗагварПрограм хангамжийн хөгжүүлэлт нь програм хангамжийн амьдралын мөчлөгийн аль үе шатыг туулж, тэдгээрт юу тохиолдохыг тодорхойлдог.

ГЭХДЭЭ арга зүйхөгжлийн менежментийн багц аргуудыг багтаасан байдаг: эдгээр нь түүнийг илүү үр дүнтэй болгодог дүрэм, техник, зарчмууд юм.

Програм хангамж хөгжүүлэх үндсэн загварууд

• Код ба засах - алдааг кодлох, засах загвар;
• Хүрхрээний загвар - каскадын загвар, эсвэл "хүрхрээ";
• V-загвар - V хэлбэрийн загвар, туршилтанд суурилсан хөгжил;
• Өсөн нэмэгдэж буй загвар - өсөлтийн загвар;
• Давталтын загвар - давтагдах (эсвэл давтагдах) загвар;
• Спираль загвар - спираль загвар;
• Эмх замбараагүй загвар - эмх замбараагүй байдлын загвар;
• Прототип загвар - загвар загвар.

Эдгээр загваруудаас үндсэн таван загвар нь хамгийн алдартай нь: каскад, V хэлбэртэй, өсөлттэй, давтагдах ба спираль. Тэдгээрийг илүү нарийвчлан авч үзье.

Хүрхрээ (хүрхрээ загвар, эсвэл "хүрхрээ")

Энэ загварт хөгжлийг үе шаттайгаар явуулдаг: дараагийн үе шат бүр өмнөх шат дууссаны дараа л эхэлдэг. Зөв хийгдсэн бол хүрхрээ нь хамгийн хурдан бөгөөд энгийн загвар байх болно. Энэ нь 1970-аад оноос хойш бараг хагас зуун жилийн турш ашиглагдаж байна.

Хүрхрээний ашиг тус

• Хөгжлийг хянахад хялбар байдаг.Үйлчлүүлэгч програмистууд одоо юу хийж байгааг үргэлж мэддэг, цаг хугацаа, зардлыг удирдаж чаддаг.
• Төслийн өртөг нь эхний шатанд тодорхойлогддог.Гэрээг тохиролцох үе шатанд бүх алхмуудыг аль хэдийн төлөвлөсөн, програм хангамжийг "эхээс болон" тасралтгүй бичдэг.
• Техникийн ноцтой мэдлэгтэй шалгагч ажилд авах шаардлагагүй.Туршилтын мэргэжилтнүүд техникийн нарийвчилсан баримт бичигт найдах боломжтой болно.

Хүрхрээний загварын сул тал

• Туршилт нь хөгжлийн сүүлийн үе шатанд эхэлдэг.Хэрэв бүтээгдэхүүнд тавигдах шаардлагад алдаа гарсан бол түүнийг засахад үнэтэй байх болно. Хөгжүүлэгч кодыг, техникийн зохиолчид баримт бичгийг аль хэдийн бичсэн үед шалгагчид үүнийг олж мэдэх болно.
• Үйлчлүүлэгч нь хөгжлийн төгсгөлд бэлэн бүтээгдэхүүнийг хардаг бөгөөд зөвхөн дараа нь өгч чадна санал хүсэлт. Үр дүн нь түүнд тохирохгүй байх магадлал өндөр байна.
• Хөгжүүлэгчид маш их техникийн баримт бичгийг бичдэг бөгөөд энэ нь ажлыг хойшлуулдаг.Төслийн баримт бичгийг илүү өргөн хүрээтэй байх тусам илүү их өөрчлөлт хийх шаардлагатай бөгөөд тэдгээрийг батлах хугацаа урт байх ёстой.

"Хүрхрээ" нь төсөл боловсруулахад тохиромжтой Баримт бичгийн өргөн мэдээллийн сан аль хэдийн бүрдсэн эмнэлгийн болон сансрын салбар(SNiP ба техникийн үзүүлэлтүүд), үүний үндсэн дээр та шинэ програм хангамжийн шаардлагыг бичиж болно.

Хүрхрээний загвартай ажиллахдаа гол ажил бол хөгжлийн нарийвчилсан шаардлагыг бичих явдал юм. Туршилтын үе шатанд тэд бүхэл бүтэн бүтээгдэхүүнд нөлөөлж буй алдаатай болох нь тодорхой болж болохгүй.

V хэлбэрийн загвар (туршилтанд суурилсан хөгжүүлэлт)

Энэ бол хэрэглэгч болон програмчлалын баг системд тавигдах шаардлагуудыг нэгэн зэрэг бичиж, үе шат бүрт хэрхэн туршихыг тайлбарладаг дэвшилтэт хүрхрээ загвар юм. Энэ загварын түүх 1980-аад оноос эхэлдэг.

V-загварын ашиг тус

Програм хангамжийн архитектур дахь алдааны тоог хамгийн бага хэмжээнд хүртэл бууруулсан.

V хэлбэрийн загварын сул тал

Архитектурын зураг төсөлд алдаа гарсан бол "хүрхрээ" шиг буцаж очоод засах нь үнэтэй байх болно.

V загварт таарна найдвартай байдал чухал бөгөөд алдааны өртөг маш өндөр байдаг төслүүдийн хувьд. Жишээлбэл, автомашины аюулгүйн дэр, эсвэл эмнэлэгт байгаа өвчтөнүүдэд зориулсан хяналтын системийг боловсруулахад.

Өсөн нэмэгдэж буй загвар (өсмөсөн загвар)

Хэсэгчилсэн хөгжлийн энэ загвар (Англи хэлнээс орчуулсан өсөлт - өсөлт) нь 1930-аад оноос эхтэй. Үүнийг нийгмийн сүлжээг бий болгох жишээн дээр авч үзье.

1. Үйлчлүүлэгч олон нийтийн сүлжээ нээхийг хүсч байгаагаа шийдэж, нарийвчилсан ажлын даалгавар бичжээ. Програмистууд үндсэн функцуудыг хэрэгжүүлэхийг санал болгов - бүхий хуудас хувийн мэдээлэлболон чатлах. Дараа нь хэрэглэгчид дээр "хөөрөх үү, үгүй" гэж туршиж үзээрэй.
2. Хөгжүүлэгч баг нь бүтээгдэхүүнийг хэрэглэгчдэд үзүүлж, зах зээлд гаргадаг. Хэрэв үйлчлүүлэгч болон хэрэглэгчид хоёулаа олон нийтийн сүлжээНадад таалагдаж байна, үүн дээр ажиллаж байна, гэхдээ хэсэгчлэн.
3. Программистууд нэгэн зэрэг зураг байршуулах, бичиг баримт солилцох, хөгжим сонсох болон үйлчлүүлэгчтэй тохиролцсон бусад үйлдлүүдийг бий болгодог. Өсөлтөөр нэмэгдэж, тэд техникийн даалгаварт дурдсантай ойртож, бүтээгдэхүүнийг сайжруулдаг.

Өсөн нэмэгдэж буй загварын давуу талууд

• Эхний шатанд их хэмжээний хөрөнгө оруулалт хийх шаардлагагүй.Үйлчлүүлэгч үндсэн функцийг бий болгоход төлбөр төлж, бүтээгдэхүүнийг хүлээн авч, зах зээлд нийлүүлж, санал хүсэлтийн үр дүнд үндэслэн хөгжлийг үргэлжлүүлэх эсэхээ шийддэг.
• Та хэрэглэгчдийн санал хүсэлтийг хурдан авч, ажлын даалгаврыг хурдан шинэчлэх боломжтой.Энэ нь хэнд ч хэрэггүй бүтээгдэхүүнийг бий болгох эрсдэлийг бууруулдаг.
• Алдаа нь хямд байдаг.Хэрэв архитектурыг боловсруулах явцад алдаа гарсан бол үүнийг засах нь "хүрхрээ" эсвэл V хэлбэрийн загвартай адил зардал гарахгүй.

Өсөн нэмэгдэж буй загварын сул тал

• Програмчлалын баг бүр өөрийн гэсэн функцийг хөгжүүлж, бүтээгдэхүүний интерфейсийг өөрийн арга замаар хэрэгжүүлж чаддаг.Үүнээс урьдчилан сэргийлэхийн тулд төслийн бүх оролцогчид нэгдмэл ойлголттой болохын тулд ажлын даалгаврыг хэлэлцэх шатанд энэ нь ямар байх талаар тайлбарлах нь чухал юм.
• Хөгжүүлэгчид үндсэн функцийн эцсийн боловсруулалтыг хойшлуулж, "жижиг зүйлийг харсан" болно.Үүнээс урьдчилан сэргийлэхийн тулд төслийн менежер баг бүр юу хийж байгааг хянах ёстой.

Өсөлттэй загвар тохиромжтой Техникийн даалгаврыг яг эхэнд нь бичсэн төслүүд бөгөөд бүтээгдэхүүн нь зах зээлд хурдан орох ёстой.

Давталтын загвар (давталтын загвар)

Энэ нь үйлчлүүлэгч ямар бүтээгдэхүүн авахыг хүсч байгаагаа ойлгох албагүй загвар бөгөөд техникийн нарийвчилсан даалгаврыг нэн даруй өгөхгүй байж болно.

Энэ загвар хэрхэн ажилладаг талаар мессенжер үүсгэх жишээг харцгаая.

1. Үйлчлүүлэгч мессенжер үүсгэхээр шийдсэн. Хөгжүүлэгчид та найзаа нэмж, хоёр хүн чатлах боломжтой программыг бүтээжээ.
2. Мессенжерийг програмын дэлгүүрт "хэвэлсэн" бөгөөд хэрэглэгчид үүнийг татаж аваад идэвхтэй ашиглаж эхэлсэн. Үйлчлүүлэгч бүтээгдэхүүн нь алдартай болохыг ойлгосон бөгөөд үүнийг сайжруулахаар шийдсэн.
3. Программистууд мессенжерт видео үзэх, зураг оруулах, аудио мессеж бичих чадварыг нэмсэн. Тэд програмын үйл ажиллагааг аажмаар сайжруулж, зах зээлийн шаардлагад нийцүүлэн тохируулдаг.

Давталтын загварын ашиг тус

• Хамгийн бага бүтээгдэхүүнийг хурдан гаргаххэрэглэгч болон хэрэглэгчдийн санал хүсэлтийг хурдан хүлээн авах боломжийг танд олгоно. Энэ нь програм хангамжийн хамгийн чухал функцүүдэд анхаарлаа төвлөрүүлж, зах зээлийн шаардлага, үйлчлүүлэгчийн хүсэлд нийцүүлэн сайжруулах гэсэн үг юм.
• Хэрэглэгчийн тасралтгүй туршилталдааг хурдан илрүүлэх, засах боломжийг танд олгоно.

Давталтын загварын сул тал

• Өгөгдлийн сан эсвэл серверийн анхны хэрэглээ- эхнийх нь масштаблахад хэцүү, сүүлийнх нь ачааллыг тэсвэрлэдэггүй. Та програмын ихэнх хэсгийг дахин бичих шаардлагатай болж магадгүй юм.
• Тогтмол төсөв, эцсийн хугацаа дутмаг.Хэрэглэгч эцсийн зорилго нь ямар байх, хөгжил хэзээ дуусахыг мэдэхгүй.

Давталтын загвар нь ажиллахад тохиромжтой тодорхойгүй шаардлага бүхий томоохон төслүүд, эсвэл даалгаврын хувьд шинэлэг хандлагаүйлчлүүлэгч үр дүндээ эргэлзэх үед.

Спираль загвар (спираль загвар)

Энэхүү загварыг ашиглан үйлчлүүлэгч болон хөгжүүлэлтийн баг төслийн эрсдэлийг нухацтай шинжилж, давталттайгаар хэрэгжүүлдэг. Дараагийн шат нь өмнөх үе дээрээ тулгуурлан давталт бүрийн төгсгөлд төслийг үргэлжлүүлэх эсэхээ шийддэг. Энэ загварыг 1988 онд ашиглаж эхэлсэн.

"Ухаалаг гэр" системийг хөгжүүлэх жишээн дээр энэ загвар хэрхэн ажилладаг талаар авч үзье.

1. Үйлчлүүлэгч ийм систем хийхийг хүсч байгаагаа шийдэж, данхыг утсан дээрээс хянахыг програмистуудад тушаажээ. Тэд "хүрхрээ" загварын дагуу ажиллаж эхлэв: тэд санааг сонсож, зах зээл дээрх саналуудад дүн шинжилгээ хийж, системийн архитектурын талаар үйлчлүүлэгчтэй ярилцаж, үүнийг хэрхэн хэрэгжүүлэхээ шийдэж, боловсруулж, туршиж, "хэрэглээ" эцсийн бүтээгдэхүүн.
2. Үйлчлүүлэгч үр дүн, эрсдлийг үнэлэв: хэрэглэгчдэд бүтээгдэхүүний дараагийн хувилбар хэр их хэрэгтэй вэ - аль хэдийн ТВ хяналттай. Нөхцөл, төсөв тооцоогоо гаргаж, бүтээн байгуулалтыг захиалсан. Программистууд хүрхрээ загварын дагуу ажиллаж, эхнийх нь үндсэн дээр боловсруулсан илүү нарийн төвөгтэй бүтээгдэхүүнийг хэрэглэгчдэд танилцуулав.
3. Үйлчлүүлэгч хөргөгчийг утаснаас удирдах функцийг бий болгох цаг болсон гэж бодсон. Гэхдээ эрсдэлд дүн шинжилгээ хийхдээ Wi-Fi модулийг хөргөгчинд нэгтгэх нь хэцүү гэдгийг би ойлгосон бөгөөд үйлдвэрлэгчид энэ асуудлаар хамтран ажиллах сонирхолгүй байна. Тиймээс эрсдэл нь боломжит ашиг тусаас давж гардаг. Хүлээн авсан өгөгдөл дээр үндэслэн хэрэглэгч ухаалаг гэрийн системийг хэрхэн хөгжүүлэх талаар ойлгохын тулд одоо байгаа функцийг хөгжүүлэхээ зогсоож, сайжруулахаар шийдсэн.

Спираль загвар нь өсөлтийн загвартай төстэй боловч эрсдэлийн үнэлгээнд илүү их цаг зарцуулдаг. Спираль шинэ эргэлт бүрт үйл явц нь илүү төвөгтэй болдог. Энэ загварыг ихэвчлэн ашигладаг судалгааны төслүүд, эрсдэл өндөртэй газар.

Спираль загварын ашиг тус

Эрсдэлийг судлахад ихээхэн анхаарал хандуулдаг.

Спираль загварын сул талууд

• Эхний шатанд гацах эрсдэлтэй- бүтээгдэхүүний эхний хувилбарыг эцэс төгсгөлгүй сайжруулж, дараагийн хувилбар руу шилжихгүй байх.
• Хөгжүүлэлт нь удаан хугацаа шаарддаг бөгөөд өндөр өртөгтэй байдаг.

Давталтын загвар дээр үндэслэн Agile-ийг бүтээсэн - загвар эсвэл арга зүй биш, харин хөгжлийн хандлага юм.

Agile гэж юу вэ?

Agile ("agile") нь англи хэлнээс "уян хатан" гэж орчуулагддаг. Бүтээгдэхүүнийг илүү үр дүнтэй бүтээхэд туслах практик, арга барил, арга зүйг багтаасан болно:

• экстрим програмчлал (Extreme Programming, XP);
• туранхай програм хангамж хөгжүүлэх (Lean);
• скрам төслийн удирдлагын хүрээ;
• онцлогт суурилсан хөгжил (FDD);
• тестээр дамжуулан хөгжүүлэх (Туршилтад суурилсан хөгжүүлэлт, TDD);
• "цэвэр өрөө"-ийн арга зүй (Cleanroom програм хангамжийн инженерчлэл);
• давталттай-өсөлттэй хөгжлийн арга (OpenUP);
• арга зүй Майкрософт хөгжүүлэлтШийдлийн хүрээ (MSF);
• динамик системийг хөгжүүлэх арга (DSDM);
• Канбаны хөгжлийн менежментийн арга.

Бид Agile болон хөгжлийн уламжлалт аргын хоорондох ялгааг хүснэгтэд нэгтгэн дүгнэв.

Жагсаалтад байгаа бүхэн аргачлал биш. Жишээлбэл, Scrum-ийг ихэвчлэн арга зүй биш, харин хүрээ гэж нэрлэдэг. Ялгаа нь юу вэ? Хүрээ бол хатуу дүрэм журамтай илүү боловсронгуй арга зүй юм. Scrum-д бүх үүрэг, үйл явц тодорхой тодорхойлогддог. Scrum-аас гадна Канбаныг ихэвчлэн ашигладаг.

Канбан

Энэ нь өнөө үед хамгийн алдартай програм хангамж хөгжүүлэх аргуудын нэг юм. Баг нь төслийн үе шатуудад хуваагддаг виртуал самбарын тусламжтайгаар ажилладаг. Оролцогч бүр аль даалгавар хийгдэж байгаа, аль нэг үе шатанд гацсан, аль нь түүний баганад хүрч, анхаарал хандуулах шаардлагатай байгааг хардаг.

Scrum-аас ялгаатай нь Канбан дээр та дараагийн спринт эхлэхийг хүлээхгүйгээр яаралтай ажлуудыг шууд хөгжүүлж чадна. Канбан нь зөвхөн ажил дээрээ төдийгүй хувийн зорилгоор ашиглахад тохиромжтой - амралтын өдрүүдэд хийх төлөвлөгөө, гэр бүлийн даалгавраа тараах, ахиц дэвшлийг нүдээр хянах.

Тун удахгүй бид гурван өдрийн арга хэмжээг зохион байгуулна. Үүн дээр та энэ аргын бүх давуу талыг хэрхэн ашиглах, хөгжлийг удирдах, аливаа нарийн төвөгтэй төслүүдийг гаргах талаар сурах болно. Таныг хүлээж байна!