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

Энэ асуудлыг шийдэхийн тулд шинэ арга барил хэрэгтэй. Үйлчлүүлэгчдэд бий болгох боломжийг олгох арга програм хангамжхолимог хөгжлийн орчныг ашиглах. Borland-ийн Нээлттэй ALM шийдлүүдийн тусламжтайгаар байгууллагууд одоо байгаа хөгжлийн нөөц, хэрэгслүүдээ ашиглах боломжтой. Энэ нь програм хангамжийг хөгжүүлэх мөчлөгийн туршид ил тод байдал, хяналт, сахилга батыг хангахад тусална. Үйлчлүүлэгчид одоо оновчтой ALM платформ болон нэг, удирдаж болохуйц, хэмжигдэхүйц програм хангамж хөгжүүлэх үйл явцаас ашиг хүртэх боломжтой.

Урьдчилан таамаглах боломжтой програм хангамж хөгжүүлэх: даалгавар боломжгүй юу?

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

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

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

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

ALM-ийн гаралт

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

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

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

ALM аж үйлдвэр

Эхэндээ, ALM чиг хандлагын ач холбогдлыг ойлгож, бүтээгдэхүүн гаргах стратегиа өөрчилсөн цөөхөн хэдэн шинийг санаачлагчдын зарим нь үүнийг тодорхой дэмжиж байсан. Борландболон IBM Rational. Илэрхий боломжуудад хариу үйлдэл үзүүлснээр бусад компаниуд ялалт байгуулсан ALM үзэл баримтлалд нэгдсэн: Microsoft, IBM Rational / Telelogic, Mercury, Serena. Өнөөдөр ALM нь тогтсон чиг хандлага бөгөөд шинжээчдийн хүлээн зөвшөөрөгдсөн өсөн нэмэгдэж буй салбар юм. ALM үйлдвэрлэгчид програм хангамж боловсруулах үйл явцыг дэмжих төрөл бүрийн хэрэгсэл, технологиор хангадаг. Эдгээр хэрэгслүүд нь хувь хүн хөгжүүлэгчийн уламжлалт бүтээмжийн хэрэгслээс хол давсан байдаг. Эдгээр нь програм хангамжийг хөгжүүлэх хамтын ажилд чиглэсэн арга зүй, хэрэгслээр хангахад чиглэгддэг. Амьдрах боломжтой ALM шийдлийг бий болгохын тулд борлуулагчид "өргөтгөсөн" програм хангамж хөгжүүлэх багийн хэрэгцээг харгалзан үзэж, илүү том үйл явцад оролцдог бүтээгдэхүүндээ үүрэг гүйцэтгэх ёстой.

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

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

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

Архитекторуудын хэрэгцээнд зориулж хэрэглээний янз бүрийн талыг (бүрэлдэхүүн хэсэг, өгөгдөл, үйл явц), дизайны загвар, корпорацийн архитектурыг дүрслэх хэрэгслүүдээр хангадаг.

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

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

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

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

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

ALM технологи нь программ хөгжүүлэлтийн хэрэгслийн салбар болон түүний үйлчлүүлэгчдийн хувьд томоохон дэвшил гэдгийг өргөнөөр хүлээн зөвшөөрдөг. Сонирхуулахад, сүүлийн 10 жилд амжилтгүй болсон программ хангамжийн төслүүдийн хувь хэмжээ хоёр дахин буурсан нь “Стандиш” группээс гаргасан хамгийн сүүлийн “Эмх замбараагүй байдлын тайлан”-гаас харагдаж байна. Энэхүү сайжруулалтыг хэсэгчлэн ALM-тэй холбож болно. Гэсэн хэдий ч хэрэглэгчийн хэрэгцээг сайтар судалж үзэхэд ALM-ийн илт давуу талыг үл харгалзан энэ технологийн бүрэн боломжийг хэрэгжүүлэхэд хэцүү хэвээр байна. Үүнийг хийхийн тулд та програм хангамжийн амьдралын мөчлөгт хамаарах процесс, хэрэгслийг нэгтгэхэд ашигладаг үндсэн хандлагыг өөрчлөх хэрэгтэй.

Бизнесийн ALM-ийн боломжууд үндсэндээ ашиглагдаагүй байна

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

Корпорацийн мэдээллийн технологийн орчин: нэг төрлийн бус байдлын асуудал

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

Үндсэн фрэйм ​​дээр ажилладаг цул тусгай программуудаас J2EE болон .NET гэх мэт байгууллагын түгээлтийн платформуудад зориулсан шинэ хөгжүүлэлтийн хэрэгслүүд рүү шилжих.

Хуучин архитектур дээр бүтээгдсэн байгууллагын багц программуудаас SAP NetWeaver, Oracle Fusion зэрэг процесс болон нийлмэл програмын ажиллах цаг руу шилжинэ.

Мэргэшсэн платформуудын тусгай хэрэгцээнд ашиглах. Эдгээр нь жишээлбэл, мэдээллийн сан (PHP, Ruby гэх мэт) ашиглан вэб програмын скрипт хэлүүд эсвэл баялаг вэб болон мультимедиа функц бүхий програм хөгжүүлэх платформууд (жишээ нь Adobe® Flash®/Flex™) юм.

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

Ялангуяа дунд болон том корпорацуудын хувьд ойрын ирээдүйд корпорацийн мэдээллийн технологийн орчин бүр дор хаяж гурвыг нь байршуулах платформыг агуулна гэж таамаглах нь үндэслэлтэй байх болно: үндсэн фрэйм, тархсан орчин (J2EE эсвэл .NET) болон систем. бизнесийн автоматжуулалт.-процессууд (SAP эсвэл Oracle). Мөн зарим байгууллагууд J2EE платформ болон .NET-д программ хангамжийг суулгаж байгаа нь (мөн улам бүр тодорхой болж байгаа) бололтой. 2

Зөрчилтэй хөтөлбөрүүд

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

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

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

o Үндсэн фрэйм, багц програмууд болон дотооддоо боловсруулсан түгээсэн программуудыг багтаасан нийлмэл програмууд эсвэл үйлчилгээнүүд.

o Үйлчлүүлэгч тал дээр .NET функцууд болон хэрэглэгчийн интерфэйсийг ашигладаг J2EE/.NET эрлийзүүд. Серверийн тал дээр тэд J2EE технологийн өргөтгөх, удирдах чадвар, аюулгүй байдлын давуу талыг ашигладаг. Энэхүү архитектурын хэв маяг нь ялангуяа санхүүгийн босоо чиглэлд түгээмэл байдаг. Энэ нь өндөр гүйцэтгэлд ашиглагддаг худалдааны платформуудУчир нь Уолл Стрит дээр Windows нь ширээний компьютерт зориулсан де факто стандарт юм.

o Flash/J2EE эрлийз. Тэд Adobe Flash-ийн хүчийг видеог цацах платформ болон интернетийн баялаг программуудыг серверт зориулсан J2EE технологийн давуу талтай хослуулсан. Энэ нь өндөр түвшний өргөтгөх боломжтой, баялаг медиа интерфейстэй байх боломжийг олгодог.

Хөгжлийн зардлыг бууруулах. Байгууллагууд нээлттэй эхийн болон өмчийн хэрэгсэл, программуудыг хослуулан програм хангамж хөгжүүлэх, байршуулах зардлыг бууруулахыг хичээж байна. Үүнтэй холбогдуулан LAMP иж бүрдэл (Linux, Apache, MySQL, PHP) улам бүр түгээмэл болж, байгууллагуудад улам бүр нэмэгдэж байгааг дурдах нь зүйтэй.

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

Өмнө нь хийсэн хөрөнгө оруулалтыг үр дүнтэй ашиглах. Аливаа "устгах, солих" арга нь ихээхэн саад тотгор учруулдаг. Энэ нь ихэнх байгууллагууд хуучин хөтөлбөр, хэрэгсэлд томоохон хөрөнгө оруулалт хийхээс татгалзах хүсэлгүй байгаатай холбоотой юм.

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

2 CMM/CMMI процессыг сайжруулах тогтолцоог хурдасгаж нэвтрүүлэх, аутсорсингийн хөгжүүлэлтийн загваруудыг ашиглах зэрэг салбарын гол чиг хандлага нь програм хангамж хөгжүүлэх салбарын энэхүү илэрхий өөрчлөлттэй нягт холбоотой юм. Стив МакКлюрын J2EE болон .NET-ийг ашиглах тухай IDC Insight тайланд дараах зүйлийг дурдсан байна. Одоогийн .NET хэрэглэгчдийн 10.4% нь дараагийн 12 сарын дотор J2EE/J2ME-г ашиглахаар төлөвлөж байна; J2EE/J2ME хэрэглэгчдийн 11.9% нь ирэх 12 сарын дотор .NET хөгжүүлэлтэд хамрагдана гэж найдаж байна.

МТ-ийн нэг төрлийн бус байдал: ALM-ийн хамгийн том сорилт

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

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

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

Сахилга бат нь янз бүрийн зүйлийг байрлуулах, хүлээн зөвшөөрөх, хянахыг шаарддаг нийтлэг үйл явцпрограм хангамжийн үйлдвэрлэлийн менежментэд зориулагдсан. Төрөл бүрийн процессын хэрэгслүүдийн дунд дэд процессууд "процессын арлууд" болж урсах үед энэ нь илүү төвөгтэй болдог. Ийм дэд үйл явцын бүжиг дэглэх (дээд түвшний үйл явцын дагуу) эсвэл эдгээр хэрэгслүүдэд үйл явцын бүрэлдэхүүн хэсгүүдийг байрлуулах стандарт механизм байдаггүй. Мөн өөр өөр хэрэгслүүдийн орчин дахь үйл явцыг тайлбарлах нэг нэр томъёо байдаггүй. Тэд бүгд "элементүүд", "олдворууд", "төслүүд" гэх мэт өөрийн хэлийг ашигладаг. Сахилга батын өөр нэг тал нь удирдлага, нөлөөллийн шинжилгээнд томоохон өөрчлөлт хийхийг шаарддаг. Гэсэн хэдий ч эдгээр чадварууд нь төгсгөл хүртэлх үйл ажиллагааны хяналтыг зөв хэрэгжүүлэхийг шаарддаг. Өмнө дурьдсанчлан, хөгжлийн янз бүрийн орчинд төгсгөл хүртэл хяналт тавих нь илүү хэцүү байдаг.

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

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

Бизнесийн зорилгынхоо хувьд ажлын платформуудын холимогийг хамгийн оновчтой байдлаар ашиглах чадвар.

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

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

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

Нэг төрлийн бус байдлыг даван туулах нь: ALM-ийн сүүлчийн хил

Нээлттэй ALM арга нь Борландын тогтоосон алсын хараа, бүтээгдэхүүний стратегийг хэрэгжүүлдэг. Энэхүү хандлага нь арилжааны ALM зах зээлд өвөрмөц архитектурын томоохон өөрчлөлтийг илэрхийлдэг. Үнэн хэрэгтээ, хэрэв бүрэн хэрэгжсэн тохиолдолд Borland Open ALM платформ болон үүнтэй холбоотой програмууд нь Borland-ийн ямар ч програм хөгжүүлэх хэрэгслийг огт ашигладаггүй хэрэглэгчдэд ч ихээхэн ач холбогдолтой байх болно. Борланд багаж хэрэгслийн бизнесээ амин чухал гэж үздэг нь эргэлзээгүй. Компани нь тэдгээрийг үргэлжлүүлэн хөгжүүлж, програм хангамж хөгжүүлэгчдийн өргөтгөсөн багт ангиллын шилдэг хэрэгслүүдийг хүргэх болно. Borland-ийн хэрэгслүүд Open ALM стратегийг дэмжихийн тулд аажмаар өөрчлөгдөнө. Энэ нь тэдэнд Open ALM-д суурилсан програм хангамжийн үйлдвэрлэлийн зохион байгуулалтад оролцох боломжийг олгоно. Гэсэн хэдий ч хэрэв үйлчлүүлэгчид үүнийг олж харвал Borland хэрэгслийг тэдний хөгжлийн шаардлагыг хангасан бүтээгдэхүүнээр сольж болно. Энэ нь гуравдагч этгээд эсвэл нээлттэй эхийн бүтээгдэхүүн байж болно. Модульчлагдсан байдал, уян хатан байдлын энэ түвшин нь Borland-ийн бүтээгдэхүүний стратегийг бусад ALM үйлдвэрлэгчдээс ялгаж өгдөг бөгөөд тэдгээрийн ихэнх нь програм хангамжийн хангамжийн сүлжээг бүхэлд нь "эзэмших" гэж оролддог.

OpenALM-ийн ашиг тус

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

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

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

Тэдний төсөл, сонгосон платформд хамгийн сайн тохирох хөгжлийн процессыг сонгох, төлөвлөх эрх чөлөө, түүнчлэн

байгууллагын соёл, зах зээлд гарах цаг хугацааны шаардлага.

Нээлттэй ALM платформ болон түүнийг дэмжих хэрэгслүүд нь анх удаагаа нэг төрлийн бус хэрэглээний хөгжүүлэлтийн орчинг ашигладаг мэдээллийн технологийн байгууллагуудад дараах боломжуудыг олгох болно.

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

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

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

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

Төслийн багцын удирдлага (Project Portfolio Management, PPM).Сангууд ба автоматжуулсан процессуудпрограм хангамжийг хөгжүүлэх стратегийг бүхэлд нь боловсруулах, түүнчлэн програм хангамж хөгжүүлэх төслийн багцын гүйцэтгэлийг удирдах.

Шаардлагын тодорхойлолт ба тэдгээрийн удирдлага (Requirements Definition and Management, RDM).Төслийн шаардлагуудыг үнэн зөв, бүрэн гүйцэд байлгах, тэдгээрийг бизнесийн зорилгод үр дүнтэйгээр эргүүлэн татах, програм хангамжийн туршилтанд оновчтойгоор хамруулах арга хэрэгсэл, шилдэг туршлагын багц.

Амьдралын мөчлөг дэх чанарын менежмент (Lifecycle Quality Management, LQM).Програм хангамж боловсруулах бүх үе шатанд чанарын тодорхойлолт, хэмжилтийг удирдах журам, арга хэрэгсэл. Эдгээр хэрэгслийг засварлах зардал харьцангуй бага байх үед төслийн эхний шатанд чанарын асуудлыг илрүүлж, урьдчилан сэргийлэх зорилготой юм. Түүнчлэн, QA багууд туршилтаа бүрэн гүйцэд хийж, эцсийн хэрэглэгчийн шаардлагад үндэслэсэн гэдэгт итгэлтэй байх ёстой.

Өөрчлөлтийн менежмент (CM).Өөрчлөлтийн үр нөлөөг урьдчилан таамаглахад туслах дэд бүтэц, хэрэгслүүд. Тэд мөн олон зангилаа болон нэг зангилааны загварт нөөц болон амьдралын мөчлөгийн өөрчлөлтийн үйл ажиллагааг удирдахад тусалдаг.

Borland Open ALM шийдэл

Өмнө дурьдсанчлан, ALM-ийн гол зорилго нь автоматжуулсан хэмжилт, зохицуулалт, сахилга батаар дамжуулан урьдчилан таамаглах боломжтой, удирдах боломжтой програм хангамж хөгжүүлэх үйл явцыг бий болгох явдал юм. ALM-ийн гурван хэмжигдэхүүн бүр нь нэг төрлийн бус програм хөгжүүлэх орчинд илүү хэцүү болж, ALM хэрэглэгчдэд хэд хэдэн тодорхой сорилтуудыг бий болгож байгааг бид харсан. Borland Open ALM платформын архитектур нь үндсэн ALM домэйнуудын аль нэг дэх асуудлыг шийдвэрлэхэд тусгайлан зориулагдсан гурван шийдлийн хэсэг юм. Нээлттэй ALM шийдлийн хэсэг бүр нь өндөр модульчлагдсан, өргөтгөх боломжтой дэд бүтцийн давхарга дээр суурилдаг бөгөөд тусгай програмуудын цуглуулга юм. Дэд бүтцийн давхаргын зорилго нь Нээлттэй ALM платформыг үйлдвэрлэгч болон хүлээгдэж буй үйлдлийн орчны технологиос үл хамааран арилжааны болон нээлттэй эхийн хөгжүүлэлтийн хэрэгсэл, процессуудын аль ч хослолтой ажиллах боломжийг олгох явдал юм. Дараагийн хуудсан дээрх диаграмм нь Borland ALM шийдлийн концепцийн диаграммыг харуулж байна.

Borland Open ALM Solution Architecture

ALM-д зориулсан нээлттэй бизнесийн тагнуул

ALM-д зориулсан Open Business Intelligence (OBI4ALM) нь ахиц дэвшлийн хэмжигдэхүүнийг нэмэгдүүлэх, ажлын чанарыг сайжруулах эсвэл програм хангамжийн төслүүдэд зориулсан бусад тусгай хэмжигдэхүүнийг нэг төрлийн бус програм хөгжүүлэх орчинд ашиглах стандарт дэд бүтэц, програмууд дээр суурилдаг. OBI4ALM нь нууцлалтайгаар хуваарилагдсан өгөгдөл цуглуулах хүрээ, түүнчлэн үүнд бүртгэлтэй програм хөгжүүлэх хэрэглүүрийн хэмжүүрүүдийн хамаарал, дүн шинжилгээ хийх боломжийг олгодог. Өгөгдлийн эх сурвалжаас урьдчилан тодорхойлсон хэмжигдэхүүнүүдийг гаргаж авснаар OBI4ALM хүрээ нь програм хангамжийн хөгжлийн мөчлөгийн туршид тархсан ялгаатай мэдээллийг нэгтгэдэг. Энэхүү нэгдэл нь маш том боломжийг олгодог. Жишээлбэл, та төслийн хэмжүүрүүдийн нэгдсэн харагдацыг үүсгэж, олон доод түвшний хэмжүүрүүдийг нэгтгэсэн төслийн шинэ хэмжүүрүүдийг тодорхойлж болно. OBI4ALM дэд бүтэц нь мэдээллийн агуулахыг ашигладаг. Энэхүү агуулах нь програм хангамж боловсруулах үйл явцын янз бүрийн үе шатанд оролцдог эдгээр хэрэглүүрүүдээс цуглуулсан одоогийн болон түүхэн мэдээллийг агуулдаг. Энэ нь асуулга, өгөгдөлд дүн шинжилгээ хийхэд оновчтой бүтцийг ашигладаг. OBI4ALM програмууд цуглуулсан хэмжигдэхүүнийг түүн дээр үндэслэн шийдвэр гаргахад тохиромжтой мэдээлэл болгон хувиргах боломжтой. Энэ нь шийдвэр гаргахад дэмжлэг үзүүлж, асуудлын талаар эрт мэдэгдэнэ.

Бодит цагийн өгөгдлийн самбар - Цаг хугацааны чиг хандлагыг харуулдаг KPI-ийн тохируулгатай харагдац.

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

Шийдвэр гаргах хэрэгслүүд нь төслийн удирдлагын шийдвэр гаргахад туслахын тулд төслийн (эсвэл олон төсөл) талаарх түүхэн мэдээллийг ашигладаг аналитик хэрэгсэл юм.

ALM-д зориулсан процессын менежментийг нээх

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

ALM-д зориулсан нээлттэй процессын менежмент (Нээлттэй Процессын менежмент ALM-д зориулсан OPM4ALM) нь янз бүрийн програм хангамж хөгжүүлэх орчинд янз бүрийн програм хангамжийн процессуудыг загварчлах, байрлуулах, хэрэгжүүлэхэд ашигладаг дэд бүтцийн бүрэлдэхүүн хэсгүүд болон програмуудын багцаар хангадаг. OPM4ALM нь зааварчилгаа өгөх, үйл явцад оролцогчдын дунд даалгавар хуваарилахаас хамаагүй илүү юм. Энэ арга нь процессын загварт заасан дүрмийн дагуу үйлчлүүлэгч тал, сервер тал, аргачлалыг нэгтгэх үндсэн "цавуу" болж үйлчилдэг процессын автоматжуулалтын давхаргыг ашигладаг. Энэ үүднээс авч үзвэл хэрэглүүр боловсруулах хэрэгслүүдийн хоорондын уялдаа холбоог үнэндээ доод түвшний процессоор хангадаг. Энэ нь үндэс суурь болдог үр дүнтэй ажилбаг.

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

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

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

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

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

Үйл явц бүрийн тодорхой хэмжүүр дээр үндэслэн хэмжилт хийж, тайлагнана.

ALM-д зориулсан хяналтыг нээх

Төгсгөлийн процессын хяналт нь ALM-ийн олон чухал ач тусыг дэмждэг. Тэдгээрийн заримыг энд дурдъя: энэ нь шаардлагад тулгуурласан хөгжүүлэлт, шаардлагад тулгуурласан хөгжүүлэлт, туршилтыг хэрэгжүүлэх, өөрчлөлтийн үр нөлөөг үнэн зөв шинжлэх чухал хэрэгсэл юм. Open Traceability for ALM (OT4ALM) нь програм хангамжийг хөгжүүлэх явцад бий болсон нөөцүүдийн хоорондын харилцааг үүсгэх, ангилах тогтолцоог бүрдүүлдэг. Мөн бий болгосон уян хатан хуваарьхолбогдох эх сурвалжуудын холбоосууд. Эдгээр нөөцийг аль хэрэгсэлд байрлуулах нь хамаагүй. Мөн энэхүү технологи нь нөөц хоорондын холбоосын диаграммыг чиглүүлэх, оновчтой асуулга үүсгэх, энэ диаграммд агуулагдах өгөгдлийг задлах хэрэгслүүдээр хангадаг.

OT4ALM нь цуглуулсан хяналтын өгөгдлийг шийдвэр гаргах мэдээлэл болгон хувиргах програмуудыг хангадаг.

Автомат төлөвлөлт, нөлөөллийн дүн шинжилгээ, үнэн зөв зардал, төсвийн таамаглал.

Хилийн хяналт - Өгөгдсөн хил хязгаараас хазайх (жишээ нь, шаардлага хангаагүй нөөц) болон биелэгдээгүй шаардлагын талаар эрт анхааруулах.

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

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

Нийтлэг платформын дэд бүтэц

Нээлттэй ALM хүрээ нь шийдлийн бүх хэсэгт хэрэглэгддэг хоёр бүрэлдэхүүн хэсгийг агуулдаг.

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

ALM интеграцийн түвшин.Өргөтгөх, суулгах боломжтой нэгтгэх хөдөлгүүр ба SDK. Энэ нь ALM хэрэгслүүдийн ажиллах стандарт арга замыг тодорхойлж, ALM хэмжигдэхүүнийг цуглуулж, нөөцийг хянах графикийг бий болгодог. ALM платформыг дэмжиж, оролцохын тулд уг хэрэгсэл нь стандарт Open ALM API-г хангасан платформ залгаасыг хангах ёстой. Та мөн Open ALM платформоор удирдуулсан процессоор дамжуулан уг хэрэгслийг бусад програм хөгжүүлэх орчинтой холбодог тусгай адаптер ашиглаж болно.

ALM-ийг нээх зам

Ирэх 24 сарын хугацаанд Borland нь Open ALM платформыг бүрдүүлдэг дэд бүтэц, програмууд болон хэрэгслүүдээ улам бүр өргөжүүлэх болно. Borland мөн энэ бүтээгдэхүүнийг аж ахуйн нэгжийн Open ALM хэрэгжилтийг амжилттай нэвтрүүлэх, амжилттай нэвтрүүлэхэд чиглэсэн өргөн хүрээний мэргэжлийн үйлчилгээний хөтөлбөрүүдээр нөхөх бодолтой байна. Нээлттэй ALM-ийн зарим давуу талыг өнөөдөр хэрэглэгчид ашиглах боломжтой. Чанарыг сайжруулж, өөрчлөлт, төслийн менежментийн үйл явцыг сайжруулахыг эрэлхийлж буй байгууллагуудад Борландын одоогийн шийдлийг маш их татах болно. Энэхүү шийдэл нь програм боловсруулах үйл явцын дөрвөн чухал хэсэгт өндөр автоматжуулсан, нэгдсэн дэмжлэг үзүүлдэг.

Төслийн багцын менежмент (PPM);

Шаардлагын тодорхойлолт ба удирдлага (RDM);

Хэрэглээний амьдралын мөчлөгийн менежмент (LQM);

Өөрчлөлтийн менежмент (CM).

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

Яагаад Борланд гэж?

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

Шийдвэр гаргах хамгийн том компаниуд болох ALM, IBM Rational болон Microsoft-ын тухай ярихад харилцагчийн үйлчилгээ нь тэдний тэргүүлэх чиглэл биш юм. Хоёр компани хоёулаа хэрэглэгчдийг дунд програмын шийдэл, системийн удирдлагын платформтой холбохын тулд хөгжүүлэлтийн хэрэгслээ ашиглахыг байнга хичээдэг.

Энэ арга барилаас ялгаатай нь Borland үргэлж Java болон J2EE стандартуудыг дэмжихийг шаарддаг бөгөөд платформ, хэл, хөгжүүлэлтийн хэрэгслүүдэд хүчтэй, нэгдсэн дэмжлэг үзүүлдэг. Microsoft. Borland нь ALM-д зориулсан Microsoft-ын шийдлийг тодорхой өргөжүүлсээр байна. Borland Microsoft-ын хамгийн сүүлийн үеийн технологийг дэмжихэд ихээхэн хөрөнгө оруулалт хийсэн. Жишээлбэл, Багийн системийн шаардлагын удирдлагын анхны цогц шийдэл болох CaliberRM нь VSTS хэрэгслээр хангагдсан үндсэн шаардлагуудын удирдлагын функцийг өргөтгөхийн тулд Microsoft-оос санал болгож байна. Borland нь Java болон .NET платформуудын хамтын ажиллагааг өргөжүүлэх болно. UML-ээс C# руу код үүсгэх, Microsoft домэйны тусгай хэлийг дэмжих (Microsoft-ийн UML-ийг орлуулах хувилбар) зэрэг нэмэлт функцуудыг хангахаар төлөвлөж байна.

Нээлттэй эх сурвалж руу шилжих нь мөн адил бус байдал нь ALM-д тулгарч буй сорилтуудтай холбоотой юм. Хэд хэдэн Eclipse санаачлагуудын зорилго (Application Lifecycle Framework (ALF), Corona болон Eclipse Process Framework (EPF)) нь Borland Open ALM-тэй төстэй юм. Борланд эдгээр төслийн цаад сэдлийг ойлгож байгаа ч тэдний арга барил хангалтгүй гэж тус компани үзэж байна. ALF болон Корона хоёулаа зөвхөн Open ALM дэд бүтцийн бүрэлдэхүүн хэсгүүдийг хангахыг хичээдэг. Гэсэн хэдий ч Open ALM нь илүү цогц арга юм. Энэхүү арга нь үйлчлүүлэгчдэд нэмэлт програмуудын иж бүрдэлээр дамжуулан урьдчилан барьсан дэд бүтцийн бизнесийн үнэ цэнийг ашиглах боломжийг олгодог. Нээлттэй ALM руу шилжихдээ Borland бусад ALM үйлдвэрлэгчдээс илүү урагшилдаг. Тус компани саяхан цар хүрээгээ тэлж, нэмэлт програм хөгжүүлэх домэйнүүдийг хамрах зорилготой. Borland нь мөн SAP NetWeaver болон Oracle Fusion платформууд дээр багцалсан програм хөгжүүлэх төслүүдийг дэмжих шилдэг арга замыг хайж байна.

Дүгнэлт

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

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

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

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

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

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

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

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

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

Ерөнхийдөө DevOps-ийн мэтгэлцээн нь борлуулагчид болон интеграторуудад ашигтай байх нь гарцаагүй. Асуудал нь мэдээллийн технологийн хэт олон төслийг зэрэгцүүлэн явуулах гэсэн дотоод зөрчилдөөнд автахгүй байх явдал юм. Хэрэв үйлчлүүлэгч ALM-ийн үзэл баримтлалыг хүлээн зөвшөөрөхгүй бол энэ нь үнэндээ түүний төлөвшил дутмаг, мэдээллийн технологийн менежментийн чадвар сул байгааг илтгэх маш сайн үзүүлэлт юм. Энэ нь өөрөө борлуулагчийн хувьд ийм үйлчлүүлэгчээс хол байх нь дээр гэдгийг харуулж байна, учир нь ийм үйлчлүүлэгч ашиг олохоос илүү асуудал авчрах магадлал өндөр байдаг.

Каролин Пампино (IBM)
Хэрэглээнд суурилсан: Rational Team Concert Beta 3, Rational Quality Manager Бета 3, Бета 3

Хяналт

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

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

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

• Бодит цагийн хуваарийг ашиглах;
• Холбогдох олдворуудын амьдралын мөчлөгийг хянах боломжийг олгох;
• Нөхцөл байдлын хүрээнд харилцан ажиллах боломжийг олгох;
• Бизнесийн аналитикийг хөгжүүлэхэд ашиглах;
• Хөгжлийн үйл явцад тасралтгүй сайжруулалтыг хэрэгжүүлэх.

Бодит цагийн төлөвлөлт

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

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

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

Цагаан будаа. 1. Ажлын зүйлээс зарцуулсан цагийг шинэчлэх нь төлөвлөгөөг үнэн зөв байлгадаг

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

Цагаан будаа. 2. Хуваарьт цагийн харагдац нь багийн зарим гишүүд бусдаас илүү ажилтай байхыг харуулдаг

Цагаан будаа. 3. Цахим даалгаврын самбарын харагдацыг газарзүйн байрлалд байрлах уян хатан багууд ашиглаж болно

Цагаан будаа. 4. Хөгжлийн төлөвлөгөөний харагдац нь даалгаврын хуваарилалтыг өдөр, долоо хоногоор нь илүү уламжлалт аргаар харуулдаг

Доорх зурган дээр Rational Team Concert-ийн хувилбарын төлөвлөгөө, түүнтэй холбоотой Бүтээгдэхүүний нөөц бүртгэл, Rational Requirements Composer дахь шаардлагуудын цуглуулга, Rational Quality Manager-ийн туршилтын төлөвлөгөөг харуулсан байна.

Цагаан будаа. 5. Төлөвлөлттэй холбоотой нь шаардлагын цуглуулга, туршилтын төлөвлөгөө юм.

IBM Rational хамтын амьдралын мөчлөгийн удирдлагын шийдэл нь бүрэн нэгдсэн, бодит цагийн төлөвлөлтийг агуулдаг.

Амьдралын мөчлөгийн ул мөр

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

Амьдралын мөчлөгийн олдворуудыг хянах боломжийг олгодог PLC шийдэл нь багууд төслийнхөө байдлын талаарх хэцүү асуултуудад хариулахад тусалдаг. Олдворуудын хооронд холбоосыг бий болгосноор багууд "Аливаа шаардлагад согог нөлөөлж байна вэ?" гэх мэт асуултад хариулахад хялбар болгодог. болон "Ажлын ямар зүйл туршилтанд бэлэн байна?"

Цагаан будаа. 6. LCA шийдлээр хариулсан чухал асуултууд

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

Дараах нь мөрдөхтэй холбоотой ердийн хийх болон болохгүй зүйлс юм:

зайлсхийх үйлдлүүд
Хэрэглэгчдийг олдворуудын хооронд холбоос үүсгэхэд саад болох нарийн төвөгтэй интерфейс бүхий шийдлүүдээс зайлсхий. Зөвхөн мөшгих зорилгоор ул мөрийн холбоос үүсгэх, ул мөр хийх зэргээр хэтрүүлж болохгүй.	Энгийн, олон талт хэрэглэгчийн интерфэйсийн тусламжтайгаар ул мөр холбоосыг хялбархан үүсгэх, хадгалах боломжийг олгодог шийдлийг ашигла, ингэснээр хэн ч хоёр олдворыг хооронд нь холбохын тулд бусад хэрэгсэл рүү шилжих шаардлагагүй болно. Та хариулахыг хүсч буй хэд хэдэн чухал асуултуудыг тодорхойлж, тохирох холбоосыг бий болгох стратегийг тодорхойлох. Нэгийг туршиж үзээд дараагийнх руу шилжихээсээ өмнө амжилтанд хүрсэн эсэхээ шалгаарай.
Хурдан хуучирсан тайлан гаргахаас зайлсхийж, төслийн гүйцэтгэлийг ойлгоход нэмэргүй шийдлүүдийг хайхаас зайлсхий.	Төслийн гүйцэтгэлийн түвшинг үнэлэх, олдворуудын хоорондын харилцаанд үндэслэн бүрэн мэдээлэлтэй шийдвэр гаргах боломжийг олгодог асуулга, тайлан, үзэл баримтлал бүхий системийг ашигла. Та мөн төлөвлөгөөнөөс шууд чиглүүлэлтийн холбоосыг харах боломжтой байх ёстой. Цоорхойг илрүүлэхэд туслах асуултуудын жишээ бол "шаардлагагүй зүйл төлөвлөх" болон "туршилтын тохиолдолгүйгээр төлөвлөх зүйл" юм. Бүрэн байдлыг үнэлэхэд туслах асуулгад "амжилтгүй туршилттай төлөвлөгөөний зүйлүүд", "туршилтыг хааж буй согогууд", "нээлттэй согогтой шаардлага" орно.
Гадны зохицуулалт, аудит байгаа эсэхийг харгалздаггүй шийдлүүдийг ашиглахаас зайлсхий.	Засварлахад хялбар, тайлагнахад хялбар ул мөр холбоос үүсгэх чадварыг багтаасан шийдэлд хөрөнгө оруулаарай.
Нэгдмэл бус дизайны мэдээллийн санг ашиглахаас зайлсхийж, хувийн API-д суурилсан өөрийн интеграцчлалыг хөгжүүлэх, хамааралгүй багц хэрэгслийг хослуулахыг оролдохоос зайлсхий. Холбогдох өгөгдлийг үүсгэхийн тулд нийтийн интерфейсгүй шийдлүүдийг бүү ашигла. Өмчлөлийн интеграци бүхий PLC репозиторуудыг бүү сонго.	Амьдралын мөчлөгийн туршид нээлттэй өгөгдөл холбох үйлчилгээ бүхий шийдлийг сонгох замаар олон талт багуудаа нэгтгэ. Нийтийн интерфейсийг хэрэгжүүлэх шийдлийг сонгоно уу нээлттэй үйлчилгээ(OSLC) нь амьдралын мөчлөг дэх өгөгдөл хоорондын холбоосыг бий болгох. Амьдралын мөчлөгийн удирдлагын цогц интеграцийн сорилтуудыг ойлгож, дэмждэг бүтээгдэхүүн үйлдвэрлэгчийг сонго. Урт хугацааны интеграцийн төлөвлөгөөг тодорхойлсон хэрэгслүүдэд хөрөнгө оруулаарай, учир нь энэ нь төсөл хэрэгжих явцад холбоос, ул мөр үүсгэхэд хялбар болгоно. Ирээдүйд хэрэгцээгээ хангахын тулд нээлттэй, уян хатан интеграцчилал бүхий өргөтгөх боломжтой шийдлийг сонгоорой. Цаг үе өөрчлөгдөж, шинэ бүтээгдэхүүнүүд гарч ирж байгаа бөгөөд таны LCA шийдэл цаашид хөгжих шаардлагатай болно.

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

Цагаан будаа. 7. Хөгжүүлэлт, шаардлага, туршилтыг багтаасан хувилбарын төлөвлөгөө

Мөрийн холбоосыг үүсгэсэн тохиолдолд IBM Rational Collaborative Lifecycle Management нь туршилтын явцад илэрсэн согог дээр үндэслэн ул мөрийн холбоосыг автоматаар үүсгэдэг. Доорх зураг нь түүнд зориулж үүсгэсэн чиглүүлэлтийн холбоос бүхий согогийг харуулж байна. Туршилтын явцад согог нэмэх үед сорилтын үр дүн, туршилтын тохиолдол, туршилтын төлөвлөгөө, төлөвлөгөөний зүйл, шаардлага зэрэгт согогийн ул мөрийн холбоосууд автоматаар үүсгэгдэнэ.

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

Контекст дахь харилцан үйлчлэл

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

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

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

Доорх зурган дээр Rational Team Concert , Rational Requirements Composer , Rational Quality Manager - ийн мэдээллийг агуулсан виджет бүхий хяналтын самбаруудыг харуулав. Хяналтын самбар дээрх өгөгдөл нь төслийн одоогийн байдлыг харуулдаг.

Цагаан будаа. 9. Төрөл бүрийн эх сурвалжаас авсан мэдээлэл бүхий хяналтын самбар нь бүх функциональ багуудын ажлын ил тод байдлыг хангадаг

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

Цагаан будаа. 10. Хэрэглэгчийн интерфейсийн хаанаас ч хандах боломжтой мини самбар

Дараах зураг нь Rational Team Concert дахь хувийн минибарыг харуулж байна. Энэ самбар нь Rational Requirements Composer доторх шаардлагуудын өөрчлөлтийг харуулах виджеттэй. Энэ бол янз бүрийн эх сурвалжаас авсан мэдээлэл бүхий мини самбарын жишээ юм. Шаардлагын дээр хулганыг аваачихад Урьдчилан харах хэсэг Шаардлагыг Зохиогчийн хэсэгт шаардлагын төлөвийн талаарх мэдээлэлтэй гарч ирнэ. Мэдээлэлд хурдан хандах шаардлагатай хэрэглэгчид мини самбарт хурдан дасах болно.

Хөгжлийн бизнесийн оюун ухаан

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

Каперс Жонс 1-ийн хэлснээр хэмжилтийн практикийг өргөнөөр ашигладаг төслүүд нь ашигладаггүй төслүүдээс хамаагүй илүү амжилттай байдаг.

Цагаан будаа. 12. Хэмжилтийн практикийг ашигладаг төслүүд амжилтанд хүрэх магадлал өндөр байдаг

Жишээлбэл, Capers Jones судалгааны байгууллагуудын 50-иас бага хувь нь дараах гурван хэмжигдэхүүнийг ашигладаг.

• Чанарын үзүүлэлтүүд 45%
• Бүтээмжийн үзүүлэлтүүд 30%
• Бэлэн байдлын хэмжүүр 15%

зайлсхийх үйлдлүүд
Төсөлдөө бусад байгууллага эсвэл гадны эх сурвалжаас авсан гүйцэтгэлийн хэмжүүрийг бүү ашигла.	Байгууллагадаа тохирсон гүйцэтгэлийн хэмжүүрүүдийг тохируул.
Статусын шинэчлэлтийн талаар багаас санал асуулга авах, хатуу диск дээрээ хүснэгт хадгалах гэх мэт гараар цуглуулсан мэдээлэлд бүү найд.	Багийн үйл ажиллагааны мэдээлэлд үндэслэн автоматаар үүсгэсэн шууд хяналтын самбар болон тайланд тулгуурлан баримтад суурилсан шийдвэр гаргаарай.
Төслийн бүх хэмжүүрийг нэг дор тодорхойлох гэж бүү оролдоорой.	Хэмжилтийг тодорхойлохдоо бага багаас эхэл. Өвдөлт намдаах цэгийг олж, шийдвэр гаргаж, сайжруулах аргыг сонгох; Энэхүү сайжруулалтад хүрэх ахиц дэвшлийг хэрхэн хэмжихээ тодорхойл. Багийг хүссэн үр дүнд хүргэхийн тулд багийнхаа үйл ажиллагааны талаар мэдээлэл цуглуулдаг хэрэгслийг ашиглана уу.

Доорх зураг нь төслийн хяналтын самбар дээрх хөгжүүлэлтийн багийн тайланг харуулж байна. Ажлын зүйлийг шинэчлэх үед тайлангууд нь багийн үйл ажиллагаа, чиглэлийг тусгасан байдаг. Төлөвлөсөн ажлаа дуусгахын тулд багийнхаа ахиц дэвшлийг хянахын тулд явцын графикийг ашиглана уу. Эсвэл "Нээлттэй", "Явж байна" болон "Хаалттай" төлөв дэх ажлын зүйлийн тооны өөрчлөлтийг харуулсан диаграммыг ашиглана уу (хамгийн тохиромжтой нь "Нээлттэй", "Явцтай" төлөв дэх ажлын зүйлийн тоо. буурах ёстой, харин "Хаалттай" -д байгаа хүмүүс ургадаг).

Цагаан будаа. 13. Сайжруулалтыг хэмжих тайлан, хэмжүүр бүхий хяналтын самбар

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

Хөгжлийн үйл явцыг тасралтгүй сайжруулах

Процесс гэдэг нь баримтжуулсан үйл ажиллагааны багцаас илүү зүйл юм. Бид багийн харилцаа холбоог сайжруулах, багийн амжилтанд хүрэх боломжийг нэмэгдүүлэх арга хэрэгсэл болох салбарын туршлагаас авсан шилдэг туршлага дээр үндэслэн үйл явцыг боловсруулдаг. Зан төлөвийг ихэвчлэн зуршил тодорхойлдог. Та үйл явцыг тодорхойлох эсвэл өөрчлөхдөө бүх багийг зуршлаа өөрчлөх, анх харахад ойлгомжгүй байж болох зан үйлийг хэрэгжүүлэхийг үр дүнтэй хүсч байна. Нэг хүний ​​зуршлыг өөрчлөх нь нэлээд хэцүү байдаг. Үйл явцыг өөрчлөх нь ихэвчлэн хүмүүсийн сэтгэх, биеэ авч явах байдлыг өөрчлөхийг шаарддаг. Сайн зохион бүтээгдсэн LCM шийдэл нь үйл явцыг аажмаар өөрчлөх, багийн динамикийг сайжруулж, илүү үр дүнтэй ажиллахыг үргэлжлүүлэх боломжийг олгодог.

зайлсхийх үйлдлүүд
Процессын чанарыг үл тоомсорлож, нэмэлт ачаалал гэж бүү бодоорой.	Тасралтгүй сайжруулалт нь танай багийнхныг хүлээн авахад тусална гэдгийг ойлгоорой шилдэг туршлагууд, ажлын хэмнэлийг бий болгож, урьдчилан тооцоолоогүй асуудлуудыг багасгах.
Бүх зүйлийг нэг дор сайжруулах уруу таталтыг эсэргүүц. Нэг алхамаар үйл явцыг хэт нарийн тодорхойлох гэж бүү оролд.	Төслийн одоогийн байдалд тулгуурлан багийн асуудлыг шийдвэрлэхийн тулд төлөвлөгөө, хяналтын самбарыг байнга шинэчилж, ахисан сайжруулалтыг ашиглана. Одоогийн нөхцөл байдлаасаа сайжирч эхлэхэд туслах арга барилыг ашигла.
Нэгэнт тодорхойлогдсон процессыг хатуу диск рүү бичиж, дахин харахгүй байх нөхцөл байдлаас зайлсхий.	Олон баг нэг хэрэгсэлд ашиглаж болох үйл явцын тодорхойлолт, загвар, автоматжуулалт зэрэг шилдэг туршлагуудыг нэвтрүүлэх замаар ахиц дэвшилд хүрэхийг зорь.
Процессын хэт хатуу хяналтаас зайлсхий.	Тасралтгүй сайжруулалтыг хөнгөвчлөх систем болон хүн бүрийн ашигладаг хэрэгслээр хийж болох зүйлийг сонгох замаар багийн гишүүдийг үйл явцыг сайжруулахад оролцоход нь урамшуул.
Эцсийн үр дүнг харахгүйгээр үйл явцын сайжруулалтыг бүү тодорхойл.	Процессын сайжруулалтыг тодорхойлохдоо сайжруулалтын үр дүнг хяналтын самбарт харуул.
Эхний удаад зөв болно гэж бүү найд.	Цаашид сайжруулах боломж үргэлж байдаг гэдгийг ойлгох хэрэгтэй. Тиймээс сайжруулалтыг байнга хянаж, дараагийн багцыг тодорхойлох шаардлагатай. Чанарын зорилгодоо хүрэх чадвараа сайжруулахыг хүсч буй багууд Rational Team Concert болон Rational Requirements Composer-тэй нэгтгэсэн Rational Quality Manager-ийг ашигладаг. IBM Rational Quality Manager нь аливаа зорилтот платформ болон тестийн төрөлд зориулсан амьдралын мөчлөгийн нэгдсэн дэмжлэгийг үзүүлдэг тестийн удирдлагын нэг лавлах цэгээр хангаснаар байгууллагуудад төслийн чанарыг оновчтой болгоход тусалдаг. Энэ нь тестийг төлөвлөх, тест үүсгэх, гүйцэтгэх, дараалал тогтоох, удирдах, төгсгөлөөс төгсгөл хүртэл хянахад зориулагдсан дүрд суурилсан шийдлийг хэрэгжүүлдэг. Эдгээр бүтээгдэхүүнийг хамтад нь ашигласнаар энэ нийтлэлд дурдсан амьдралын мөчлөгийн менежментийн 5 зарчмыг хэрэгжүүлэх боломжийг багт олгоно. Эдгээр зарчмууд нь багаж хэрэгсэлд суурилагдсан бөгөөд өндөр чанартай програм хангамжийн шинэчлэлийг бий болгох чадварыг сайжруулахад тань туслахад бэлэн байна. Өөр нэг сайн зүйл бол өгөөж авахын тулд бүх гурван хэрэгслийг ашиглах шаардлагагүй юм - тэдгээрийг хосоор нь болон хамтдаа ашиглаж болно. ___________________________________________________________________________________________________________

гэх мэт..

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

• мэдээллийн менежмент(“Зөв мэдээлэл нь зөв оролцогч талуудад цаг тухайд нь, ашиглахад хялбар хэлбэрээр байх ёстой”)
• тохиргооны удирдлага("зураг төслийн мэдээлэл нь шаардлагад нийцсэн байх ёстой, "барьсан" мэдээлэл нь дизайнтай тохирч байх ёстой, түүний дотор дизайны үндэслэл, физик систем нь "барьсан" мэдээлэлтэй тохирч байх ёстой, дизайны өөр өөр хэсгүүд хоорондоо таарч байх ёстой", заримдаа Энэ практикийн нэг хэсгийг "өөрчлөлтийн менежмент" гэж нэрлэдэг).

LCMS vs PLM

Шинээр боловсруулсан LCMS нь PLM-ийг шаардлагатай анги болгон ашигладаггүй програм хангамжийн хэрэгслүүдэргэн тойронд нь ийм систем баригдсан. Томоохон инженерийн төслүүдэд янз бүрийн үйлдвэрлэгчдийн хэд хэдэн (ихэнхдээ "хөгжөөгүй") PLM-ийг нэг дор ашигладаг бөгөөд LCMS-ийг бий болгохдоо бид ихэвчлэн тэдний байгууллага хоорондын интеграцийн талаар ярьдаг. Мэдээжийн хэрэг, үүнтэй зэрэгцэн өргөтгөсөн аж ахуйн нэгжийн PLM системүүдтэй хараахан холбогдоогүй байгаа эдгээр системийн мэдээллийг LCMS-д хэрхэн нэгтгэх вэ гэсэн асуултууд бас шийдэгддэг. "Өргөтгөсөн аж ахуйн нэгж" (өргөтгөсөн аж ахуйн нэгж) гэсэн нэр томъёо нь ихэвчлэн янз бүрийн инженерийн төсөлд хамрагдсан нөөцөөс (хүмүүс, багаж хэрэгсэл, материал) гэрээний системээр бий болсон байгууллагыг хэлдэг. хуулийн этгээд. Өргөтгөсөн аж ахуйн нэгжүүдэд CAD / CAM / ERP / EAM / CRM / гэх мэт системүүдийн өгөгдөл нь ямар PLM-д нэгтгэгддэг вэ гэсэн асуултын хариулт нь үл тоомсорлодог: эзэмшигчид. янз бүрийн аж ахуйн нэгжүүднэг үйлдвэрлэгчийн програм хангамжийг ашиглахыг бүү заа.

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

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

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

LCMS-ийн зорилго

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

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

Тиймээс LCMS-ийн санаа нь янз бүрийн "дизайн автоматжуулалт", юуны түрүүнд "үүсгүүрийн дизайн" (үүсгүүрийн дизайн) ба "үүсгүүрийн үйлдвэрлэл" (generative үйлдвэрлэл) -тэй холбоогүй юм. LCMS нь синтез хийхээ больсон, харин дүн шинжилгээ хийхтэй холбоотой болсон: энэ нь янз бүрийн технологийг ашиглан бие даасан дэд системүүдийг нэгтгэх үед тэдгээрийн дизайны үр дүнгийн зөрчилдөөнийг илрүүлж, / эсвэл урьдчилан сэргийлдэг.

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

Загварт суурилсан хандлага

LCMS ашиглах нь гэсэн үг юм Зөвхөн дизайн дахь цаас төдийгүй "цахим цаас" -аас татгалзах(.tiff эсвэл бусад растер форматууд) болон мэдээллийн өгөгдөлд төвлөрсөн дүрслэлд шилжих. Зарим тэмдэглэгээнд цаасан дээр байгаа хоёр загварыг харьцуулж, тэдгээрийн зөрчилдөөнийг олох нь бүтэц зохион байгуулалттай зөрчилдөөнөөс урьдчилан сэргийлэхээс хамаагүй хэцүү бөгөөд урт юм. цахим баримт бичигЭнэ нь растер график биш харин инженерийн өгөгдлийн загваруудыг ашигладаг.

Өгөгдлийн загварыг зарим хэлний дагуу боловсруулж болно, жишээлбэл:

• ISO 24744 боловсруулах аргын тодорхойлолтын стандартын хувьд)
• метамодель (OMG стандартчиллын консорциумын хувьд),
• өгөгдлийн загвар/лавлагаа өгөгдөл (ISO 15926 амьдралын мөчлөгийн өгөгдлийг нэгтгэх стандартын хувьд).

Энэ нь дизайны эхний үе шатанд аль хэдийн бий болсон бүтцийн хувьд дүрслэгдсэн загвар руу шилжих шилжилтийг "Загварт суурилсан системийн инженерчлэл" (MBSE, загварт суурилсан системийн инженерчлэл) гэж нэрлэдэг. Бүтцийн бүрэн хэмжээний 3D загвар гарч ирэхээс өмнө амьдралын мөчлөгийн хамгийн эхний үе шатанд компьютерийн өгөгдөл боловсруулах тусламжтайгаар мөргөлдөөнийг арилгах боломжтой болно.

LCMS нь дараахь зүйлийг хийх ёстой.

• CAD/CAM/ERP/PM/EAM/ гэх мэт нэг програмаас өгөгдөл дамжуулах механизмаар хангах. нөгөө рүү- мөн "цахим цаасны багц" хэлбэрээр биш цахим бүтэцтэй хэлбэрээр. Нэг инженерийн мэдээллийн системээс өгөгдөл дамжуулах (хаана, хаана, хэзээ, юу, яагаад, хэрхэн гэсэн тодорхой ойлголттой) нь LCMS-ийн өгсөн функцүүдийн нэг хэсэг юм. Тиймээс LCMS нь ажлын урсгалыг (хэсэг хэсэг нь хүмүүс, зарим нь компьютерийн системээр гүйцэтгэдэг ажлын урсгалыг) дэмжих ёстой.
• хувилбарын хяналт, өөрөөр хэлбэл системийн загвар болон физик хэсгүүдийн тохиргооны удирдлагын функцийг хангах. LCMS нь шаталсан шаардлагуудын ангилал зүйг хадгалж, шаталсан дизайны шийдвэрүүд болон тэдгээр шаардлагуудтай зөрчилдөж байгаа үндэслэлийг шалгах арга хэрэгслээр хангадаг. Инженерийн хөгжлийн явцад системийн аливаа тодорхойлолт, түүний аль ч загвар нь олон удаа өөрчлөгдөж, нэмэгддэг тул янз бүрийн түвшний зөв, өөр өөр түвшинд тохирсон олон хувилбарт байдаг. LCMS нь зөвхөн эдгээр хувилбаруудын зөв хослолыг одоогийн ажилд ашиглахыг баталгаажуулах ёстой.

LCMS архитектур

LCMS-ийн архитектурын олон шийдэл байж болох бөгөөд ижил функцийг янз бүрийн бүтэц, ажлын механизмаар дэмжиж болно. Гурван төрлийн архитектур байдаг:

1. LCMS үүсгэх уламжлалт оролдлогонь өөр өөр програмуудын хооронд чухал цэгээс цэг рүү өгөгдөл дамжуулалтыг хангах явдал юм. Энэ тохиолдолд зарим тусгай ажлын урсгалыг дэмжих систем (BPM хөдөлгүүр, "бизнесийн үйл явцын удирдлагын хөдөлгүүр") эсвэл үйл явдлыг боловсруулах систем (цогцолбор үйл явдал боловсруулах хөдөлгүүр) ашиглаж болно. Харамсалтай нь, нэг цэгээс цэг рүү солилцоход шаардагдах ажлын хэмжээ асар их болж хувирдаг: холбогдох систем, мэдээлэл дамжуулах аргыг хоёуланг нь ойлгодог мэргэжилтнүүд шаардлагатай болдог.
2. Амьдралын мөчлөгийн өгөгдлийг нэгтгэх стандартыг ашиглах"ISO 15926 гадна" аргын дагуу ISO 15926 стандартад нийцсэн төвийг сахисан дүрслэл болгон инженерийн програм тус бүрд зориулж адаптер боловсруулсан тохиолдолд. Тиймээс бүх өгөгдөл нь зарим програмд ​​​​ таарах боломжийг олж авдаг бөгөөд тэдгээрийн хоорондын мөргөлдөөнийг илрүүлэх боломжтой байдаг - гэхдээ програм нь хэд хэдэн ийм адаптер биш харин зөвхөн нэг өгөгдөл дамжуулах адаптер боловсруулах шаардлагатай байдаг (бусад програмын тооноос хамааран). харилцах шаардлагатай).
3. PLM(Teamcenter, ENOVIA, SPF, NET Platform гэх мэт) - стандартчилсан архитектурыг ашигладаг бөгөөд зөвхөн эдгээр PLM-д ашиглагдаж буй өгөгдлийн загвар нь инженерийн аливаа сэдвийг тусгах тал дээр тийм ч түгээмэл биш гэдгийг эс тооцвол. төвийг сахисан бөгөөд бүх хэлбэрээр ашиглах боломжтой. Тиймээс LCMS руу өгөгдөл дамжуулахдаа ISO 15926 стандартыг үндсэн дүрслэл болгон ашиглахыг авч үзэж болно. Цаашдын хөгжилорчин үеийн PLM-д хэрэгжсэн санаанууд.

Тохиргооны удирдлагын архитектурын дагуу LCMS-ийг гурван төрөлд хувааж болно.

• "хадгалах газар"(Өгөгдлийг боловсруулсан газраас нь хуулж авдаг нэг LCMS репозитор дахь төслийн бүх өгөгдлийг хамгийн сүүлийн үеийн хадгалалт),
• "бүртгэх"(LCMS нь бусад CAD систем, инженерийн симуляцийн систем, PLM, ERP гэх мэт олон тооны агуулах дахь амьдралын мөчлөгийн өгөгдлийн хаягуудын жагсаалтыг хөтөлдөг),
• "эрлийз архитектур"-- өгөгдлийн нэг хэсгийг LCMS төв репозитор руу хуулж, өгөгдлийн нэг хэсгийг бусад газраас холбоосоор дамжуулан авах боломжтой үед.

LCMS-ийн архитектор дараахь зүйлийг тайлбарлах ёстой.

• "портал"("вэб портал" гэх мэт), түүний чиг үүрэг, хэрэгжүүлэх арга. Портал байгаа нь зөрчилдөөн байхгүйг харуулах замаар шилдэг менежерүүдийг тайвшруулах боломжийг олгодог. LCMS порталын архитектурын шийдэлд тодорхой шаардлага тавьдаг.
• өгөгдлийн бүрэн бүтэн байдал/тууштай байдлыг шалгах алгоритмуудамьдралын мөчлөг, түүнчлэн эдгээр алгоритмуудын үйл ажиллагааны тайлбар:
  • энэ програмын репозитор дахь өгөгдөл дээр ажилладаг тусдаа програм дахь стандарт модуль - энэ нь CAD эсвэл PLM байх;
  • LCMS-ийн төв репозиторт байрлах өөр өөр програмуудын өгөгдөлд хандах боломжтой LCMS-д тусгайлан боловсруулсан мөргөлдөөнийг шалгах программ хангамж;
  • Интернэтээр дамжуулан өөр өөр байгууллагад байрлах өөр өөр мэдээллийн сан руу аюулгүй сувгаар нэвтрэх тусгайлан боловсруулсан програм хангамжийн хэрэгсэл;
  • Янз бүрийн инженерийн өгөгдлийн багцыг LCMS төв репозитор руу ачаалах үед мөргөлдөөнийг хянах тусгай программчлагдсан шалгалтууд;
  • дээрх бүх аргуудын хослол - өөр өөр янз бүрийн төрөлмөргөлдөөн; гэх мэт.
• LCMS хэрэглэгчдийн харилцах арга(дизайны инженер, худалдан авагч, суурилуулагч, байгууламжийн төслийн менежер гэх мэт) болон LCMS програм хангамж нь энэхүү харилцан үйлчлэлийг мөргөлдөөнгүй байдлаар хэрхэн дэмждэг. Системийн инженерчлэлийн стандартууд (ялангуяа ISO 15288 системийн инженерчлэлийн практик стандарт) инженерийн нарийн төвөгтэй объектуудын амьдралын мөчлөгийн төрлийг сонгох, системийн инженерчлэлийн практикийн аль хувилбаруудыг ашиглахыг зааж өгөхийг шаарддаг. Амьдралын мөчлөгийн загвар нь өргөтгөсөн инженерийн төслийн байгууллагын ажлыг зохицуулах зохион байгуулалтын зохицуулалт болдог гол олдворуудын нэг юм. Хамтарсан инженерчлэлийн явцад уялдаа холбоотой ажиллах нь дизайны цөөн тооны зөрчилдөөний гол түлхүүр юм. LCMS амьдралын мөчлөгийн загвар үүнийг яг хэрхэн дэмжих вэ? Тиймээс, PLM системүүд нь амьдралын мөчлөгийн загваруудад, тэр ч байтугай байгууллагын загваруудад ихэвчлэн газар олдоггүй. Тиймээс LCMS-ийн хувьд эдгээр загваруудын програм хангамжийг дэмжих өөр шийдлүүдийг хайх шаардлагатай байна.
• LCMS-ийн хэрэглээнд шилжих зохион байгуулалтын асуудал. LCMS-ийг ашиглахад шилжих нь бүтэц, тэр байтугай боловсон хүчний хувьд мэдэгдэхүйц өөрчлөлтийг үүсгэж болзошгүй юм инженерийн компани: бүх ухагчийг эксковатороор авдаггүй, бүх таксины жолоочийг таксины жолоочоор авдаггүй.

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

Тиймээс LCMS-ийн архитектор хоёр үндсэн үүрэгтэй:

• нэр дэвшигчдийн хэд хэдэн шилдэг архитектурууд болон тэдгээрийн эрлийзүүдийг төрүүлэв
• Эдгээр архитектуруудын дунд олон шалгуурын сонголт хийх.
  • утга учиртай анхаарах (сонголтын шалгуурын утга учир)
  • үр дүнг танилцуулах (үндэслэл).

LCMS-ийн архитектурын шийдлийг сонгох шалгуурууд

1. Гол зорилго нь LCMS-ийн гүйцэтгэлийн чанар: мөргөлдөөнийг илрүүлэх, урьдчилан сэргийлэхГол шалгуур нь: санал болгож буй LCMS архитектурыг ашиглан мөргөлдөөнийг илрүүлэх эсвэл зайлсхийх ажлыг хурдасгах замаар инженерийн дэвшлийг хэр хурдасгах вэ? Хэрэв ажлын цагийг багасгах боломжгүй бол ижил нөөцийг ашиглан нэг цагт ажлын хэмжээг хэд дахин нэмэгдүүлэх боломжтой вэ? Дараахь аргуудыг санал болгож байна.
   • Голдраттын хязгаарлалтын онол(TOC, хязгаарлалтын онол) - архитектур нь инженерийн төслийн чухал нөөцийн зам дээр ямар системийн хязгаарлалтыг арилгахыг зааж өгөх ёстой (чухал замтай андуурч болохгүй).
   • ROI(хөрөнгө оруулалтын өгөөж) нэр дэвшигчдийн архитектурыг бодитой хянан үзэх үр дүнг албан ёсны болгох үе шатанд LCMS-д оруулсан хөрөнгө оруулалт.
   Харгалзах хил хязгаарыг сонгох нь чухал: инженерийн төслийн нийт хурдыг зөвхөн авч үзэж буй зохион байгуулалтын системийн хил дээр хэмжиж болно. Ганц хуулийн этгээдийн хил хязгаар нь томоохон инженерийн төсөл хэрэгжүүлж буй өргөтгөсөн аж ахуйн нэгжийн хил хязгаартай давхцахгүй байж болох бөгөөд амьдралын мөчлөгийн зөвхөн нэг үе шатанд оролцож буй аж ахуйн нэгж нь түүний амьдралын бүтэн мөчлөгт ашиг тус, чухал чанарыг буруу үнэлж болно. системийн талаар болон LCMS-д өөрийгөө нэгтгэх буруу аргыг сонгох. Дараа нь LCMS-ийг бий болгох нь төслийн нийт хугацаа, төсөвт нөлөөлөхгүй байх магадлалтай, учир нь хамгийн таагүй зөрчилдөөнийг шинэ LCMS шийдвэрлэхгүй хэвээр байх болно.
2. Өсөн нэмэгдэж буй LCMS хөгжүүлэлтийн амьдралын мөчлөгийг нэвтрүүлэх чадвар ISO 15288-ийн өсөлт нь хэрэглэгчдэд функцийг нэг дор өгдөггүй, харин үе шаттайгаар өгдөг амьдралын мөчлөг юм, гэхдээ хөгжилд оруулсан хөрөнгө оруулалт нь нэг дор биш, харин үе шаттайгаар явагддаг. Мэдээжийн хэрэг, энэ тохиолдолд ашиг тусыг багасгах хуулийг анхаарч үзэх хэрэгтэй: LCMS-ийн өсөлт бүр (шинэ төрлийн мөргөлдөөнийг урьдчилан илрүүлсэн) илүү үнэтэй бөгөөд үүнээс гарах ашиг тус бүр нь бага, бага байх болно. олон жил үргэлжилж буй LCMS нь өөрөө алга болдог. Хэрэв санал болгож буй зарим архитектурын хувьд LCMS-ийг бий болгоход нэг дор их хэмжээний хөрөнгө оруулалт хийх шаардлагатай болох нь тогтоогдвол үр ашгийг нь шууд 100%, зөвхөн таван жилийн дараа түлхүүр гардуулах замаар авах боломжтой. суурь, тэгвэл энэ нь муу архитектур юм. Хэрэв зарим нэг авсаархан LCMS цөм, дараа нь тэдгээрийг хөгжүүлэх тодорхой механизм бүхий янз бүрийн төрлийн мөргөлдөөнд зориулагдсан ижил төрлийн олон, олон модулиудыг боловсруулж ашиглалтад оруулах боломжтой болох нь тогтоогдвол (жишээлбэл, ашиглахад үндэслэсэн). ISO 15926), тэгвэл энэ нь маш сайн. Энэ нь "agile development" (agile methodologies) -ийг ашиглах тухай биш, харин LCMS-ийн модульчлагдсан архитектурыг хангах, модулиудын тэргүүлэх жагсаалтыг хэрэгжүүлэх төлөвлөгөөг санал болгох явдал юм - эхлээд хамгийн тулгамдсан, дараа нь бага дарагдсан гэх мэт. ICM (өсөлттэй амлалтын загвар) -тай андуурч болохгүй, гэхдээ энд байгаа утга нь адилхан: архитектур нь илүү сайн, ингэснээр та системийн төлбөрийг аль болох эрт авах боломжтой бөгөөд шаардлагатай функцийг аль болох эрт авах боломжтой. тэтгэмжийг (ядаж бага хэмжээгээр) эрт авах, хожимдсон тэтгэмжийг дараа нь төлөх.
3. Технологийг эзэмших, хадгалах санхүүгийн болон оюуны үндсэн чадварХэрэв бид зөвхөн LCMS-д төдийгүй төслийг хэрэгжүүлэхэд шаардагдах бүх боловсон хүчин болон бусад дэд бүтцийн зардлыг тооцвол боловсрол, компьютер, зохион байгуулалтын хүчин чармайлтын хөрөнгө оруулалтаас хэр их хөрөнгө оруулалт үлдэхийг ойлгох хэрэгтэй. Төлбөр төлөгч, LCMS-ийн эзэмшигч, мөн хэдийг гаднаас нь шийдвэрлэх вэ - олон тооны гүйцэтгэгчид мэдээжийн хэрэг эхлээд шинэ технологи хөгжүүлэх "тэтгэлэг" авч, дараа нь өөрсдийн бий болгосон системийг дэмжсэнд талархах болно. Шинэ нь ихэвчлэн маш үнэтэй байдаг бөгөөд энэ нь өөрөө үнэтэй учраас биш, харин өөрчлөлтийн нуранги үүсгэдэг. Энэ нь би LCMS-ийн өмчлөлийн нийт зардлыг харгалзан үзэж байгаа бөгөөд ижил зүйлд инженерийн системээс зайлсхийж болох мөргөлдөөнтэй байхаа больсон, харин LCMS-ийн бүх амьдралын мөчлөгийг авч үзэх болно.
4. LCMS архитектурын өргөтгөх чадварЭнэ шалгуур нь томоохон инженерийн төслүүдэд хамаатай. Нэгэнт энэ системийг өргөтгөсөн байгууллагын бүх мянга мянган хүн ашиглахыг хүсч байгаа тул тэр хэмжээгээр хурдацтай хөгжих шаардлагатай болно. LCMS-ийн "нисгэгч" эсвэл "полигон" нь архитектурын үндсэн өөрчлөлтгүйгээр хэр хурдан өсөх боломжтой вэ? Тэд ургаж чадахгүй байх магадлалтай. Тиймээс, архитектурын хувьд бидэнд "нисгэгч" эсвэл "олон өнцөгт" биш, харин нэн даруй "эхний шат" хэрэгтэй. Өргөтгөх шалгуурын шаардлага нь өсөлтийн шалгуурын шаардлагатай нягт огтлолцож байгаа боловч арай өөр зүйлд нөлөөлдөг - LCMS-ийн бүтээн байгуулалтыг цаг хугацаанд нь сунгах биш, харин хамрах хүрээг өргөтгөх боломж. Туршлагаас харахад бүх системүүд дизайны өгөгдлийн туршилтын хэмжээг даван туулж чаддаг боловч үйлдвэрлэлийнх нь хувьд үүнийг даван туулж чаддаггүй. Эзлэхүүн / хурд нэмэгдэх тусам техник хангамж, програм хангамжийн үнэ шугаман бус байдлаар хэрхэн өсөх вэ? Хэзээ болтол тэд журмаа боловсруулах юм бэ, дараа нь тодорхой болох юм ажлын байрНэг хүний ​​үзэж чадахаас илүү их мэдээлэл дамждаг уу? Өргөтгөх чадвар муу байгаа нь зөвхөн програм хангамж, техник хангамжийн шийдлийн архитектурын техникийн талаас төдийгүй санхүүгийн архитектурын талаас нь хүлээж байж болно. Тиймээс, CLMS-ийн суудалд ногдох лицензийн үнэ бага байх эсвэл репозиторын сервер дээрх шинэ холболтын бага үнэ нь арван суудалд зориулсан илүү их сонирхол татахуйц шийдлийг зорилтот мянган суудлын хувьд туйлын санхүүгийн хувьд тогтворгүй шийдэл болгон хувиргаж чадна.
5. Байгууллагын зайлшгүй сорилтуудыг шийдвэрлэх чадварөргөтгөсөн байгууллагад хайртай өв залгамжлалын тогтолцоонд хандах хандлагыг багтаасан болно. Санал болгож буй төвлөрсөн эсвэл хуваарилагдсан архитектур нь LCMS-гүй одоогийн нөхцөл байдалтай харьцуулахад "бусад хэлтэст чиг үүрэг өгөх", "бидний өгөгдлийг өгөх" болон ерөнхийдөө ямар нэг зүйлийг "өгөх" нь хэр их шаардлагатай вэ? Мэнфрэймүүд нь мини-компьютер, хувийн компьютерт өрсөлдөхдөө их хэмжээгээр ялагдсан. Бүх өгөгдөл нь тусдаа хэрэглээнд байдаг тул (LCMS зайлшгүй үзүүлдэг төвлөрсөн систем рүү) буцах зам бараг байхгүй бөгөөд эдгээр өгөгдлийг шинэ системд татах нь зохион байгуулалтын маш хэцүү ажил юм. LCMS архитектур хэрхэн бүтэцлэгдсэн бэ: энэ нь одоо байгаа инженерийн программуудыг орлох уу, одоогийн мэдээллийн технологийн дэд бүтцийн дээр бүтээгдсэн үү, янз бүрийн үйлчилгээнүүдэд "үнэгүй" суулгасан уу? Зохион байгуулалтын/удирдлагын/зөвлөхөд хэр их хүчин чармайлт гаргах вэ? шинэ технологи? Хичнээн хүнийг халах, хэд нь шинээр мэргэжилтэн хайж, ажиллуулах вэ? Байгууллагын хүлээн зөвшөөрөгдсөн энэхүү шалгуур нь зөвхөн төвлөрөл/төвлөрлийг сааруулахаас гадна өргөтгөсөн аж ахуйн нэгж дэх урам зоригийн системийг авч үзэхтэй нягт холбоотой юм. LCMS-ийн архитектурыг энэ шалгуурын дагуу үнэлэх нь зөвхөн LCMS-ийг нарийн авч үзэхээс хамаагүй илүү боловч өргөтгөсөн байгууллагыг бий болгох зарчмуудыг нарийвчлан шинжлэх, түүний дагуу гэрээнд үндэслэсэн зарчмуудыг хянан үзэх хүртэл шаардлагатай. үүсгэсэн. Гэхдээ энэ бол системийн хандлагын мөн чанар юм: аливаа зорилтот системийг (энэ тохиолдолд LCMS) юуны өмнө "гүнзгий, аль хэсгээс" биш, харин "гадаад, юуны нэг хэсэг" гэж үздэг - түүний загвар биш. болон үйл ажиллагааны механизм нь үндсэндээ сонирхолтой боловч дэмжигдсэн LCMS нь гадаад суперсистем дэх мөргөлдөөнөөс зайлсхийх функц бөгөөд гадаад суперсистем энэхүү шинэ функцэд төлөхөд бэлэн байгаа үнэ юм. Тиймээс, боломжит LCMS архитектурыг үндсэндээ "хэрэглэгдэж буй зохистой технологи, жишээ нь програм хангамжийн үйлдвэрлэгч XYZ"-ийн хувьд биш гэж үздэг (энэ нь анхдагч: бүх санал болгож буй архитектурууд нь ихэвчлэн технологийн хувьд тохиромжтой байдаг, эс тэгвээс тэдгээр нь сонголт биш юм!) дээрх таван шалгуур.

LCMS функцууд

1. Мөргөлдөөнөөс зайлсхийх
   1. Тохиргооны удирдлага
      1. Тодорхойлолт (ангилал, кодчилол)
      2. Тохиргооны нягтлан бодох бүртгэл (бүх боломжит суурь үзүүлэлтүүд - ConOp, Архитектур, дизайн, баригдсан байдлаар), LCMS репозитор руу өгөгдөл дамжуулах, түүний дотор ажлын урсгалын өөрчлөлтийг дэмжих, түүний дотор зэрэгцээ инженерчлэлийн дэмжлэг (бүрэн бус суурь нөхцөлд ажиллах)
      3. Хувилбар (салаа оруулаад)
   2. Гарын авлагын өгөгдөл дамжуулах дутагдал (хуучин дизайны бүтээн байгуулалтын "дижитал руу өсөх" арлуудаас өгөгдөл дамжуулах зэрэг аль хэдийн байгаа автоматжуулалтын арлуудын хооронд оролт, гаралтын өгөгдлийг дамжуулах)
   3. NSI тохиргоо
   4. Хамтарсан инженерийн дэмжлэгийн систем (видео хурал, алсын төслийн сесс гэх мэт. Магадгүй LCMS системийг өөрөө бий болгоход ашигладаггүй байж магадгүй)
2. Мөргөлдөөнийг илрүүлэх
   1. Шалгасан мөргөлдөөний төрлүүдийн бүртгэлийг дэмжих, бүртгэлд тохирох технологийг шалгах
   2. Автоматжуулалтын арлуудын хоорондох мөргөлдөөнийг шалгах өгөгдөл дамжуулах (LCMS репозиторт угсрахгүйгээр, гэхдээ LCMS интеграцийн технологийн тусламжтайгаар)
   3. Янз бүрийн төрлийн мөргөлдөөнийг шалгах ажлын урсгалыг ажиллуулж байна
      1. LCMS хадгалах санд
      2. хадгалах санд биш, харин LCMS интеграцийн технологийн тусламжтайгаар
   4. Олдсон зөрчлийг шийдвэрлэхийн тулд ажлын урсгалыг эхлүүлэх (мөргөлдөөний талаар мэдэгдэл илгээх, учир нь шийдвэрлэх ажлын урсгал нь CLMS-ийн асуудал биш юм)
   5. Дэмжлэг одоогийн жагсаалтшийдэгдээгүй мөргөлдөөн
3. Хөгжил(энд LCMS нь автопоэтик систем гэж тооцогддог, учир нь "өсөлттэй хэрэгжилт" нь LCMS-ийн хамгийн чухал шинж чанаруудын нэг юм - тиймээс энэ нь LCMS-ийг дэмжих системийн функц биш харин LCMS-ийн өөрийнх нь үүрэг юм)
   1. LCMS-ийн хөгжлийн талаархи харилцаа холбоог хангах
      1. LCMS-ийг хөгжүүлэх ажлын төлөвлөлт (замын зураг, үйл ажиллагааны төлөвлөгөө боловсруулах)
      2. LCMS төслийн оффисын үйл ажиллагаа,
      3. Мөргөлдөөний шалгалтын төрлүүдийн бүртгэл хөтлөх ("Хүслийн жагсаалт" нь өөрөө болон шалгалтыг хэрэгжүүлэх замын зураглал)
      4. LCMS-д зориулсан зохион байгуулалт, техникийн загварчлал (Enterprise Architecture).
      5. LCMS хөгжүүлэгчдэд зориулсан холбооны дэд бүтэц (интернет хурал, видео хурал, мэдлэгийн менежмент гэх мэт. -- магадгүй LCMS ашиглан хамтын инженерчлэлд ашигладаггүй)
   2. Өгөгдлийн интеграцийн технологийн жигд байдал (жишээлбэл, ISO 15926 технологи)
      1. Төвийг сахисан өгөгдлийн загварыг ашиглах
         1. Лавлагаа мэдээллийн сангийн дэмжлэг
         2. Лавлах өгөгдлийг боловсруулах
      2. Төвийг сахисан өгөгдлийн загварт адаптеруудыг дэмжих технологи
   3. Нэг төрлийн ажлын урсгал/BPM нэгтгэх технологи (өргөн аж ахуйн нэгж)
4. Өгөгдлийн аюулгүй байдал(LCMS-ийн хүрээнд ажилладаг мэдээллийн системийн хэмжээнд)
   1. Хандалтын нэгдмэл байдлыг хангах (бүгд нэг нэвтрэх, нууц үг мэдээллийн системажлын урсгалд оролцох)
   2. Өгөгдлийн элементүүдэд хандах эрхийг удирдах
   3. Нөөц

Сүүлийн 10-15 жилийн хугацаанд хөгжүүлэлтийн хэрэгслийн зах зээлийн хөгжилд дүн шинжилгээ хийж үзэхэд программ бичих технологиос (90-ээд оны эхэн үеэс эхлэн 90-ээд оны эхэн үеэс эхлэн хөгжиж ирсэн) онцлох хандлага өөрчлөгдсөнийг тэмдэглэж болно. RAD хэрэгслүүд - "түргэн програм хөгжүүлэх") хэрэгцээг нэгтгэсэн хэрэглээний бүх амьдралын мөчлөгийн менежмент - ALM (Application Lifecycle Management) .

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

шаардлагын тодорхойлолт (Шаардлага);

дизайн ба шинжилгээ (Дизайн ба дүн шинжилгээ);

Хөгжил (хөгжил);

туршилт (туршилт);

байршуулалт ба засвар үйлчилгээ (Байршуулах & Үйл ажиллагаа).

Эдгээр алхам бүрийг сайтар хянаж, хянах ёстой. Зөв зохион байгуулалттай ALM систем нь танд дараахь зүйлийг хийх боломжийг олгоно.

Бүтээгдэхүүнийг зах зээлд гаргахад шаардагдах хугацааг багасгах (хөгжүүлэгчид зөвхөн өөрсдийн хөтөлбөрийг боловсруулсан шаардлагад нийцүүлэхэд анхаарах ёстой);

програм нь хэрэглэгчдийн хэрэгцээ, хүлээлтийг хангахын зэрэгцээ чанарыг сайжруулах;

бүтээмжийг нэмэгдүүлэх (хөгжүүлэгчид хөгжүүлэлт, хэрэгжилтийн шилдэг туршлагыг хуваалцах боломжийг олж авдаг);

Хэрэгслийг нэгтгэх замаар хөгжлийг хурдасгах;

Аппликешн болон түүний хоорондын уялдааг байнга хадгалах замаар засвар үйлчилгээний зардлыг бууруулна төслийн баримт бичиг;

Ур чадвар, үйл явц, технологид оруулсан хөрөнгө оруулалтаа хамгийн их ашиглаарай.

Үнэнийг хэлэхэд, ALM-ийн тухай ойлголт нь мэдээжийн хэрэг цоо шинэ зүйл биш юм - програм хангамжийг бий болгох асуудлын талаархи ийм ойлголт нь дөчин жилийн өмнө, үүсэх эхэн үед үүссэн. үйлдвэрлэлийн аргуудхөгжил. Гэсэн хэдий ч харьцангуй саяхан болтол програм хангамж боловсруулах ажлыг автоматжуулах гол хүчин чармайлт нь хамгийн их цаг хугацаа шаардсан үе шат болгон програмчлалын хэрэгслийг шууд бий болгоход чиглэгдэж байв. Зөвхөн 80-аад онд програм хангамжийн төслүүдийн хүндрэлээс болж нөхцөл байдал эрс өөрчлөгдөж эхлэв. Үүний зэрэгцээ, хоёр үндсэн чиглэлээр хөгжүүлэх хэрэгслүүдийн үйл ажиллагааг (өргөн утгаараа) өргөжүүлэх ач холбогдол эрс нэмэгдсэн: 1) програм хангамжийн амьдралын мөчлөгийн бусад бүх үе шатыг автоматжуулах, 2) хэрэгслүүдийг нэгтгэх. бие биенээ.

Олон компаниуд эдгээр ажлыг гүйцэтгэдэг байсан ч энд маргаангүй удирдагч нь Rational компани байсан бөгөөд байгуулагдсан цагаасаа хойш хорь гаруй жилийн турш програм хангамж боловсруулах үйл явцыг автоматжуулах чиглэлээр мэргэшсэн. Нэгэн цагт тэрээр программ зохиоход визуал аргуудыг өргөнөөр ашиглах анхдагчдын нэг болсон (мөн энэ чиглэлээр стандарт гэж хүлээн зөвшөөрөгдсөн UML хэлний бараг зохиогч) нийтлэг ALM-ийг бий болгосон. арга зүй болон холбогдох хэрэгслүүд. Энэ зууны эхэн гэхэд Rational нь нэг ангиллын хэрэгслийг эс тооцвол ALM-ийг (бизнесийн дизайнаас эхлээд засвар үйлчилгээ хүртэл) дэмжих бүрэн хэмжээний бүтээгдэхүүнтэй цорын ганц компани байсан гэж хэлж болно. энгийн кодлох хэрэгсэл. Гэсэн хэдий ч 2003 оны 2-р сард энэ нь оршин тогтнохоо больсон бие даасан байгууллагамөн IBM Rational нэртэй IBM корпорацийн хэлтэс болсон.

Саяхныг хүртэл Rational нь ALM ангиллын нэгдсэн хөгжүүлэлтийн хэрэгслүүдийн бараг цорын ганц үйлдвэрлэгч байсан ч програм хангамжийг хөгжүүлэх тодорхой үе шатуудад бусад үйлдвэрлэгчдээс өрсөлдөх хэрэгсэл байсан бөгөөд одоо ч байгаа. Гэсэн хэдий ч, хэд хэдэн жилийн өмнө Borland корпораци нь уламжлалт програм хөгжүүлэх хэрэгслүүдийн (Delphi, JBuilder гэх мэт) салбарт үргэлж хүчтэй байр суурь эзэлсээр ирсэн бөгөөд энэ нь үнэндээ корпорацийн ALM цогцолборын үндэс суурь болсон бөгөөд үүнийг өргөтгөсөн. ижил төстэй бүтээгдэхүүн үйлдвэрлэдэг бусад компаниудыг худалдан авах. Энэ нь хоёр компанийн бизнесийн загваруудын үндсэн ялгаа бөгөөд бодит өрсөлдөөний боломжуудыг нээж өгдөг. Rational IBM-ийн нэг хэсэг болсны дараа Borland өнөөдөр ALM иж бүрэн платформын цорын ганц бие даасан ханган нийлүүлэгч болж байна (өөрөөр хэлбэл, өөрийн үйлдлийн систем, хэл гэх мэтийг сурталчилдаггүй). Хариуд нь өрсөлдөгчид Borland өөрт байгаа хэрэглүүрүүдийг нэгтгэх үндэс болох тодорхой ALM аргачлалыг хараахан боловсруулаагүй байгааг тэмдэглэж байна.

Хөгжүүлэлтийн хэрэгслүүдийн өөр нэг томоохон тоглогч бол Microsoft корпораци юм. Тэрээр өөрийн ALM платформыг бий болгоно гэж сүрдүүлээгүй ч; Энэ чиглэлд сурталчлах нь зөвхөн бусад ханган нийлүүлэгчидтэй ижил Rational болон Borland (тэдгээрийн аль аль нь Visual Studio Industry Partner хөтөлбөрийн анхны оролцогчид болсон) хамтын ажиллагааны хүрээнд явагддаг. Үүний зэрэгцээ Microsoft-ын тэргүүлэх Visual Studio .NET хөгжүүлэлтийн хэрэгсэл нь Microsoft Visio болон Microsoft Project-тэй нэгтгэх зэрэг өндөр түвшний загварчлал, төслийн менежментийн хэрэгслүүдийг ашиглах замаар үйл ажиллагаагаа байнга өргөжүүлж байна.

Өнөөдөр технологи, програм хангамжийн бүтээгдэхүүн хөгжүүлдэг бараг бүх тэргүүлэгч компаниуд (дээр дурьдсанаас бусад нь Oracle, Computer Associates гэх мэт) програм хангамжийг бий болгох технологийг боловсруулсан бөгөөд эдгээрийг өөрсдөө болон өөрсдийн гараар бүтээжээ. бүтээгдэхүүн худалдан авах.болон төрөлжсөн жижиг компаниудын бүтээсэн технологи. Хэдийгээр Microsoft-ын нэгэн адил тэд өөрсдийн ALM платформыг бүтээхээр хараахан төлөвлөөгүй байгаа ч эдгээр компаниудын гаргасан CASE хэрэгслийг програм хангамжийн амьдралын мөчлөгийн тодорхой үе шатанд өргөн ашигладаг.