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

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

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

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

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

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

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

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

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

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

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

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

Одоо програм хангамжийн инженерчлэлд IS програм хангамжийг хөгжүүлэх хоёр үндсэн хандлага байдаг бөгөөд тэдгээрийн үндсэн ялгаа нь системийг задлах янз бүрийн арга замуудаас шалтгаална: функциональ задралын зарчим дээр суурилсан функциональ-модульчлагдсан (бүтцийн) хандлага. системийн бүтэц нь түүний функцүүдийн шатлал, бие даасан функциональ элементүүдийн хооронд мэдээлэл дамжуулах байдлаар тодорхойлогддог. объект хандалтат хандлага, объектын задралыг ашигладаг бөгөөд IS-ийн бүтцийг объектууд болон тэдгээрийн хоорондын харилцааны хувьд, системийн үйл ажиллагааг объектуудын хоорондох мессежийн хувьд тодорхойлдог.

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

Бүтцийн хандлагын үндсэн зарчим нь:

o зарчим" хуваах ба захирах";

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

Эдгээр зарчмуудын гол нь:

o хийсвэрлэл - системийн чухал талуудыг тодруулах;

o тууштай байдал - системийн элементүүдийн хүчин төгөлдөр байдал, тууштай байдал;

o өгөгдлийн бүтэц - өгөгдлийн бүтэц зохион байгуулалттай, шаталсан зохион байгуулалттай байх ёстой.

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

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

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

o зохион бүтээсэн системийн хүндрэл;

o тайлбарын шаардлагатай бүрэн байдал;

o төсөлд оролцогчдын мэдлэг, ур чадвар;

o дизайн хийхэд зориулагдсан цаг.

Визуал загварчлал нь ялангуяа CASE хэрэгслүүдийн хөгжилд ихээхэн нөлөөлсөн. CASE (Computer Aided Software Engineering) гэсэн ойлголтыг өргөн утгаар нь ашигладаг. Энэхүү ойлголтын анхны утга нь зөвхөн програм хангамжийн хөгжүүлэлтийг автоматжуулах даалгавруудаар хязгаарлагдаж байсан бөгөөд одоо програм хангамжийн амьдралын мөчлөгийн ихэнх үйл явцыг хамарсан шинэ утгыг олж авсан.

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

1. Cascade (Англи хүрхрээ) - стандарт хөгжлийн загвар

Каскадын хөгжлийн загвар - хөгжлийн бүх үе шатыг дараалан гүйцэтгэдэг загвар - өмнөх шат дууссаны дараа дараагийн үе шат эхэлнэ.

Энэхүү загвар нь програм хангамж боловсруулах үйл явцын дараах алхмуудыг агуулна.

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

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

Хүрхрээ хөгжүүлэх гол давуу талууд:

2. Agile программ хангамж боловсруулах арга зүй

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

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

Agile хөгжүүлэх хэд хэдэн аргууд байдаг бөгөөд хамгийн алдартай нь Scrum, Extreme Programming, DSDM юм.

Agile хөгжлийн гол давуу талууд:

Agile хөгжлийн зарчим:

Тиймээс, EIS програм хангамжийг хөгжүүлэх бүтцийн аргын мөн чанар нь түүнийг автоматжуулсан функц болгон задлах (хуваах) дээр оршдог: систем нь функциональ дэд системүүдэд хуваагддаг бөгөөд тэдгээр нь эргээд дэд функцүүд, тэдгээр нь даалгавар гэх мэт хуваагддаг. тодорхой журам хүртэл. Үүний зэрэгцээ систем нь бүх бүрэлдэхүүн хэсгүүд хоорондоо уялдаатай байдаг цогц үзлийг хадгалдаг. "Доороос дээш" системийг боловсруулахдаа бие даасан ажлуудаас эхлээд бүхэл бүтэн систем хүртэл бүрэн бүтэн байдал алдагдаж, бие даасан бүрэлдэхүүн хэсгүүдийн мэдээллийн харилцан үйлчлэлийг тайлбарлахад асуудал үүсдэг.

Бүтцийн хандлагын хамгийн түгээмэл бүх аргууд нь хэд хэдэн ерөнхий зарчим дээр суурилдаг.

1. "Хувааж, ялах" зарчим;

2. Шатлан ​​эрэмбэлэх зарчим - системийн бүрдүүлэгч хэсгүүдийг шат бүрт шинэ дэлгэрэнгүй мэдээлэл нэмж, шаталсан модны бүтэц болгон зохион байгуулах зарчим.

Хоёр үндсэн зарчмыг сонгох нь үлдсэн зарчмууд нь хоёрдогч гэсэн үг биш, учир нь Тэдгээрийн аль нэгийг үл тоомсорлох нь урьдчилан таамаглах боломжгүй үр дагаварт хүргэж болзошгүй (бүх төслийн бүтэлгүйтэл гэх мэт). Эдгээр зарчмуудын гол нь:

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

2. Системийн элементүүдийн тууштай байдал, хүчин төгөлдөр байдал, уялдаа холбоотой байх зарчим.

3. Өгөгдлийн бүтцийн зарчим - өгөгдөл нь бүтэцтэй, шаталсан зохион байгуулалттай байх ёстой.

Бүтцийн хандлагын хувьд системийн функциональ бүтэц, өгөгдлийн хоорондын харилцааг тодорхойлдог үндсэн хоёр бүлэг хэрэгсэл байдаг. Багаж хэрэгсэл бүр нь тодорхой төрлийн загвар (диаграмм)-тай тохирч байгаа бөгөөд тэдгээрийн хамгийн түгээмэл нь:

· DFD (Data Flow Diagrams) - өгөгдлийн урсгалын диаграмм;

SADT (Бүтцийн шинжилгээ ба дизайны техник - бүтцийн шинжилгээ, дизайны арга зүй) - загвар ба холбогдох функциональ диаграммууд: тэмдэглэгээ IDEF0 (системийн функциональ загварчлал), IDEF1x (өгөгдлийн сангийн үзэл баримтлалын загварчлал), IDEF3x (объектийн чанарыг үнэлэх барилгын системүүд). Урсгалын үйл явцын график дүрслэл, эдгээр үйл явцын нөлөөгөөр өөрчлөгдөж буй үйл явц, объектуудын харилцан үйлчлэл);

· ERD (Entity - Relationship Diagrams) - "аж ахуйн нэгж-харилцаа" диаграммууд.

Бүтцийн хандлагын бараг бүх аргуудад (бүтцийн шинжилгээ) програм хангамжийн шаардлагыг бүрдүүлэх үе шатанд хоёр бүлгийн загварчлалын хэрэгслийг ашигладаг.

1. Системийн гүйцэтгэх ёстой функцууд болон эдгээр функцүүдийн хоорондын хамаарлыг харуулсан диаграммууд - DFD эсвэл SADT (IDEF0).

2. Өгөгдөл ба тэдгээрийн хамаарлыг загварчлах диаграммууд (ERD).

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

Програм хангамжийн шаардлагыг бүрдүүлэх үе шатанд SADT загвар ба DFD нь "AS-IS" загвар ба "TO-BE" загварыг бий болгоход ашиглагддаг бөгөөд ингэснээр байгууллагын бизнесийн үйл явцын одоо байгаа болон санал болгож буй бүтэц, тэдгээрийн хоорондын харилцан үйлчлэлийг тусгасан болно. (SADT загваруудыг ихэвчлэн зөвхөн энэ үе шатанд ашигладаг, учир нь тэдгээр нь анх програм хангамжийн дизайнд зориулагдаагүй байсан). ERD-ийн тусламжтайгаар өгөгдлийн санг (DBMS) хэрэгжүүлэх аргаас үл хамааран байгууллагад ашигласан өгөгдлийн тодорхойлолтыг концепцийн түвшинд гүйцэтгэдэг.

1. Кодлох

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

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

Кодлохдоо сонгосон хэлний стандартыг дагаж мөрдөх шаардлагатай, тухайлбал, Си хэлний хувьд ANSI C, C++ нь ISO/IEC 14882 "С++ програмчлалын хэлний стандарт" юм.

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

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

Кодлох үе шатанд программист өөрөө програм бичиж, туршиж үздэг. Ийм туршилтыг нэгжийн туршилт гэж нэрлэдэг. Програм хангамжийн туршилттай холбоотой бүх асуудлыг Бүлэгт авч үзнэ. 10-т мөн програм хангамж боловсруулах үе шатанд хэрэглэгддэг туршилтын технологийг тайлбарласан болно. Энэ техникийг туршилт гэж нэрлэдэг. "шилэн хайрцаг" (шилэн хайрцаг);заримдаа туршилт гэж нэрлэдэг "цагаан хайрцаг" (цагаан хайрцаг)"хар хайрцаг" (хар хайрцаг) гэсэн сонгодог ойлголтоос ялгаатай.

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

"Шилэн хайрцаг" -ыг турших үед нөхцөл байдал огт өөр байна. Тестер (энэ тохиолдолд программист өөрөө) эх кодын мэдлэг дээр үндэслэн тестийг боловсруулдаг бөгөөд үүнд бүрэн хандах боломжтой. Үүний үр дүнд тэрээр дараах тэтгэмжийг авдаг.

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

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

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

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

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

6. Сонгосон алгоритмаар тодорхойлогдсон туршилтын боломж. Маш нарийн төвөгтэй тооцооллын алгоритмуудыг ашигладаг өгөгдөл боловсруулалтыг туршихын тулд тусгай технологи шаардлагатай байж болно. Матрицын хувиргалт ба өгөгдлийг ангилах нь сонгодог жишээ юм. Тестер нь програмистаас ялгаатай нь яг ямар алгоритмыг ашигладаг болохыг мэддэг байх ёстой тул тусгай ном зохиолоос лавлах хэрэгтэй.

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

Нэгжийн туршилт хийхдээ та бүтцийн болон функциональ туршилтын арга, эсвэл хоёуланг нь ашиглаж болно.

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

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

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

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

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

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

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

Сайн баримтжуулсан PP нь дараах давуу талуудтай.

1. Хэрэглэхэд хялбар. Хэрэв PP нь сайн баримтжуулсан бол өргөдөл гаргахад илүү хялбар болно. Хэрэглэгчид үүнийг илүү хурдан сурч, алдаа бага гаргадаг бөгөөд үүний үр дүнд ажлаа илүү хурдан, илүү үр дүнтэй хийдэг.

2. Техникийн дэмжлэгийн зардал бага. Хэрэглэгч өөрт хэрэгтэй үйлдлүүдийг хэрхэн хийхээ мэдэхгүй бол програм хангамж үйлдвэрлэгчийг техникийн дэмжлэг үзүүлэх үйлчилгээ рүү дууддаг. Ийм үйлчилгээний засвар үйлчилгээ маш үнэтэй байдаг. Нөгөө талаар сайн гарын авлага нь хэрэглэгчдэд асуудлыг бие даан шийдвэрлэхэд тусалдаг бөгөөд техникийн дэмжлэг үзүүлэх бүлэгтэй холбоо барих хэрэгцээг бууруулдаг.

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

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