نحوه نوشتن نمونه کار فنی هدف و هدف از ایجاد سیستم. آمادگی برای کارهای آزمایشگاهی

در این مقاله سعی کردم به طور مفصل مشکل توسعه شرایط مرجع را در نظر بگیرم. موضوع به اندازه مشکل قدیمی است. اما هنوز هم اغلب حل می شود "چگونه پیش می رود". همانطور که هنری شاو گفت: "این چیزهای کوچک است که ما را بیشتر نگران می کند: فرار از یک فیل آسان تر از یک مگس است."

این مقاله درباره چیست؟

• در قسمت اول " توسعه مشخصات فنی. چیست، چرا لازم است، از کجا شروع کنیم و چگونه باید به نظر برسد? من سعی خواهم کرد به سؤالات موضوع به طور مفصل پاسخ دهم، ساختار و هدف شرایط مرجع را در نظر بگیرم و توصیه هایی در مورد تدوین الزامات ارائه دهم.
• بخش دوم " توسعه مشخصات فنی. نحوه تدوین الزامات? به طور کامل به شناسایی و تدوین الزامات سیستم اطلاعاتی اختصاص داده خواهد شد.

• یک سازمان تجاری تصمیم به پیاده سازی یک سیستم خودکار گرفت. این سرویس فناوری اطلاعات خود را ندارد و تصمیم به انجام این کار گرفت: فرد علاقه مند باید شرایط مرجع را توسعه دهد و آن را برای توسعه ارسال کند. سازمان شخص ثالث;
• یک سازمان تجاری تصمیم به پیاده سازی یک سیستم خودکار گرفت. سرویس آی تی خود را دارد. ما تصمیم گرفتیم این کار را انجام دهیم: یک شرایط مرجع ایجاد کنیم، سپس آن را بین سرویس فناوری اطلاعات و اشخاص ذینفع هماهنگ کنیم و اجرا کنیم. به تنهایی;
• ساختار دولتی تصمیم به شروع یک پروژه فناوری اطلاعات گرفت. اینجا همه چیز خیلی گل آلود است، تشریفات زیاد، رشوه، بریدگی و... من این گزینه را در این مقاله در نظر نخواهم گرفت.
• یک شرکت فناوری اطلاعات در خدمات توسعه و / یا پیاده سازی سیستم های خودکار مشغول است. این سخت ترین مورد است، زیرا شما باید در شرایط مختلفی کار کنید:
  • مشتری متخصصان خاص خود را دارد که نظرات خود را دارند و آنها الزامات خاصی برای شرایط مرجع دارند.
  • شرایط مرجع برای توسعه دهندگان خود ما ایجاد شده است (کارفرما اهمیتی نمی دهد).
  • شرایط مرجع برای انتقال به پیمانکار (به عنوان مثال گروهی از برنامه نویسانی که خارج از کارکنان شرکت هستند یا یک متخصص فردی) ایجاد می شود.
  • در مورد نتیجه به دست آمده بین شرکت ها و مشتری سوء تفاهم وجود دارد و شرکت بارها و بارها این سوال را مطرح می کند: "شرایط مرجع چگونه باید تدوین شود؟" مورد دوم ممکن است یک پارادوکس به نظر برسد، اما حقیقت دارد.
  • گزینه های دیگر، کمتر رایج نیز ممکن است.

• چرا نمی توان شرایط مرجع را همیشه به یک شکل توسعه داد؟
• آیا استانداردها، روش ها، توصیه هایی وجود دارد؟ آنها را از کجا تهیه کنیم؟
• چه کسی باید شرایط مرجع را توسعه دهد؟ آیا این فرد نیاز به دانش خاصی دارد؟
• چگونه بفهمیم که شرایط مرجع به خوبی نوشته شده است یا خیر؟
• با هزینه چه کسی باید توسعه یابد و آیا اصلاً به آن نیاز است؟

وظیفه فنی چیست؟

بله، واقعاً GOST ها و استانداردهایی وجود دارد که در آنها سعی می شود این بخش از فعالیت (توسعه نرم افزار) تنظیم شود. روزی روزگاری، همه این GOST ها مرتبط بودند و به طور فعال مورد استفاده قرار می گرفتند. اکنون نظرات مختلفی در مورد مرتبط بودن این اسناد وجود دارد. برخی استدلال می کنند که GOST ها توسط افراد بسیار دوراندیش ساخته شده اند و هنوز هم مرتبط هستند. برخی دیگر می گویند که به طرز ناامیدکننده ای منسوخ شده اند. شاید کسی اکنون فکر می کرد که حقیقت جایی در وسط است. من با سخنان گوته پاسخ می‌دهم: «آنها می‌گویند که بین دو عقیده متضاد، حقیقت نهفته است. در هیچ موردی! بین آنها یک مشکل نهفته است." پس هیچ حقیقتی بین این نظرات وجود ندارد. زیرا GOST ها مشکلات عملی را آشکار نمی کنند طراحی مدرنو کسانی که از آنها انتقاد می کنند، جایگزینی (بدون و سیستمی) ارائه نمی دهند.

توجه داشته باشید که GOST به وضوح حتی تعریفی ارائه نمی دهد ، فقط می گوید: "TOR برای NPP سند اصلی است که الزامات و روش ایجاد (توسعه یا نوسازی - ایجاد بیشتر) یک سیستم خودکار را مطابق با آن تعریف می کند. که با آن توسعه NPP و پذیرش آن پس از راه اندازی انجام می شود.

اگر کسی متعجب است که من در مورد چه GOST صحبت می کنم، در اینجا آنها هستند:

• GOST 2.114-95 یک سیستممستندات طراحی مشخصات فنی؛
• GOST 19.201-78 سیستم یکپارچه اسناد برنامه. وظیفه فنی الزامات محتوا و طراحی؛
• GOST 34.602-89 فناوری اطلاعات. مجموعه ای از استانداردها برای سیستم های خودکار. شرایط مرجع برای ایجاد یک سیستم خودکار.

و بنابراین، همانطور که از تعریف بر می آید، هدف اصلی شرایط مرجع، فرموله کردن الزامات برای شی در حال توسعه، در مورد ما، برای یک سیستم خودکار است.

اصلی ترین است، اما تنها. وقت آن است که چیز اصلی را به عهده بگیریم: همانطور که وعده داده شده همه چیز را "در قفسه ها" قرار دهیم.

در مورد الزامات چه چیزی باید بدانید؟ باید به وضوح درک کرد که همه الزامات باید بر اساس نوع و ویژگی ها تقسیم شوند. اکنون نحوه انجام آن را یاد خواهیم گرفت. برای جدا کردن الزامات بر اساس نوع، GOST فقط به ما کمک می کند. فهرستی از انواع الزامات که در آنجا ارائه شده است، نمونه خوبی از این است که چه نوع الزاماتی باید در نظر گرفته شود. مثلا:

• الزامات عملکرد؛
• الزامات امنیت و حقوق دسترسی؛
• شرایط لازم برای صلاحیت پرسنل؛
• …. و غیره. می توانید در مورد آنها در GOST ذکر شده بخوانید (و در زیر آنها را نیز با جزئیات بیشتری در نظر خواهم گرفت).

در مورد انواع نیازمندی ها گفتم اما املاک چطور؟ اگر انواع الزامات می تواند متفاوت باشد (بسته به اهداف پروژه)، پس با ویژگی ها همه چیز ساده تر است، 3 مورد از آنها وجود دارد:

1. لازمه باید باشد قابل درک;
2. لازمه باید باشد بتن;
3. لازمه باید باشد تست شده;

در این داستان در مورد اینکه شرایط مرجع چیست، می توان کامل کرد و به موضوع اصلی رفت: چگونگی تدوین الزامات. اما همه چیز آنقدر سریع نیست. یکی دیگر از فوق العاده وجود دارد نکته مهم:

• شرایط مرجع باید به چه زبانی (از نظر پیچیدگی درک) نوشته شود؟
• آیا باید مشخصات در آن شرح داده شود؟ توابع مختلف، الگوریتم ها، انواع داده ها و سایر موارد فنی؟
• و طراحی فنی که اتفاقاً در GOST ها نیز ذکر شده چیست و چه ارتباطی با شرایط مرجع دارد؟

وظیفه فنیسندی مبتنی بر الزامات است که به زبانی قابل درک (معمول، آشنا) برای مشتری تنظیم شده است. در این مورد، اصطلاحات صنعتی قابل درک برای مشتری می تواند و باید استفاده شود. نباید هیچ گونه الزامی برای ویژگی های پیاده سازی فنی وجود داشته باشد. آن ها در مرحله TK، در اصل، مهم نیست که این الزامات بر روی کدام پلت فرم اجرا می شود. اگرچه استثنائاتی وجود دارد. اگر ما در مورد پیاده سازی یک سیستم مبتنی بر یک محصول نرم افزاری موجود صحبت می کنیم، چنین الزام آور می تواند اتفاق بیفتد، اما فقط در سطح فرم های صفحه نمایش، فرم های گزارش و غیره. تحلیلگر کسب و کار.و مطمئناً برنامه نویس نیست (مگر اینکه این نقش ها را ترکیب کند، این اتفاق می افتد). آن ها این شخص باید با مشتری به زبان تجارت خود صحبت کند.

پروژه فنی - این سندی است که برای اجرای فنی الزامات تدوین شده در شرایط مرجع در نظر گرفته شده است. فقط این سند ساختارهای داده، راه‌اندازها و رویه‌های ذخیره‌شده، الگوریتم‌ها و سایر موارد مورد نیاز را توضیح می‌دهد. متخصصان فنی. به هیچ وجه لازم نیست که مشتری به این موضوع بپردازد (ممکن است چنین اصطلاحاتی را درک نکند). پروژه فنی انجام می دهد معمار سیستم(در اینجا ترکیب این نقش با برنامه نویس کاملا عادی است). یا بهتر است بگوییم گروهی از متخصصان به رهبری یک معمار. هرچه پروژه بزرگتر باشد، افراد بیشتری روی شرایط مرجع کار می کنند.

در عمل چه داریم؟ تماشای زمانی که کارگردان توسط شرایط مرجع برای تایید آورده می شود خنده دار است، که مملو از اصطلاحات فنی، توصیف انواع داده ها و مقادیر آنها، ساختار پایگاه داده و غیره است. او البته سعی می کند بفهمد، زیرا لازم است. برای ادعا، تلاش برای پیدا کردن کلمات آشنا بین خطوط و از دست دادن الزامات کسب و کار زنجیره ای. چه وضعیتی آشنا؟ و چگونه به پایان می رسد؟ به عنوان یک قاعده ، چنین TOR تأیید می شود ، سپس اجرا می شود و در 80٪ موارد به هیچ وجه با واقعیت کار انجام شده مطابقت ندارد ، زیرا آنها تصمیم گرفتند خیلی چیزها را تغییر دهند، دوباره انجام دهند، اشتباه فهمیدند، اشتباه فکر کردند و غیره. و غیره و سپس سری تحویل آغاز می شود. "اما اینجا آنطور که ما به آن نیاز داریم نیست"، "برای ما کار نخواهد کرد"، "خیلی پیچیده است"، "ناخوشایند است"، و غیره. آشنا؟! بنابراین می‌دانم، باید به موقع این برجستگی‌ها را پر می‌کردم.

پس در عمل چه داریم؟ اما در عمل، ما یک مرز مبهم بین شرایط مرجع و طراحی فنی داریم. به طرق مختلف بین TK و TP شناور است. و این بد است. و به این دلیل است که فرهنگ توسعه ضعیف شده است. این تا حدی به دلیل صلاحیت متخصصان است، تا حدی به دلیل تمایل به کاهش بودجه و مهلت‌ها (از همه اینها، مستندسازی زمان زیادی می‌برد - این یک واقعیت است). عامل مهم دیگری نیز وجود دارد که بر استفاده از طرح فنی به عنوان یک سند جداگانه تأثیر می گذارد: توسعه سریعابزارهای توسعه سریع و روش های توسعه. اما این یک داستان جداگانه است که در زیر چند کلمه در مورد آن خواهم گفت.

یک نکته کوچک اما مهم دیگر. گاهی اوقات شرایط مرجع را یک قطعه کوچک از الزامات، ساده و قابل فهم می نامند. به عنوان مثال، برای اصلاح جستجوی یک شی با توجه به برخی شرایط، یک ستون به گزارش اضافه کنید، و غیره. این رویکرد کاملا موجه است، چرا زندگی را پیچیده می کند. اما نه در پروژه های بزرگ، بلکه در پیشرفت های جزئی استفاده می شود. من می گویم این به نگهداری محصول نرم افزاری نزدیک تر است. در این مورد، شرایط مرجع ممکن است یک مورد خاص را نیز توصیف کند راه حل فنیاجرای الزام به عنوان مثال، "ایجاد فلان تغییر در الگوریتم"، نشان دهنده یک رویه خاص و یک تغییر خاص برای برنامه نویس است. این در صورتی است که مرز بین شرایط مرجع و پروژه های فنی به طور کامل پاک شود، زیرا هیچ امکان اقتصادی برای افزایش کاغذ در جایی که نیاز نیست وجود ندارد و یک سند مفید ایجاد می شود. و درست است.

آیا واقعاً به مشخصات فنی نیاز دارید؟ پروژه مهندسی چطور؟

پروژه فنی چطور؟ این سند بسیار مفید است و ارتباط خود را از دست نداده است. علاوه بر این، اغلب انجام بدون آن به سادگی غیرممکن است. به خصوص وقتی صحبت از برون سپاری کار توسعه باشد، یعنی. بر اساس برون سپاری اگر این کار انجام نشود، این خطر وجود دارد که چیزهای زیادی در مورد نحوه ظاهر سیستمی که در ذهن دارید یاد بگیرید. آیا مشتری باید او را بشناسد؟ اگر بخواهد چرا که نه، اما نیازی به اصرار و تایید این سند نیست، فقط کار را مهار و تداخل می کند. طراحی یک سیستم تا کوچکترین جزئیات تقریبا غیرممکن است. در این صورت باید به طور مداوم تغییراتی در طراحی فنی ایجاد کنید که زمان زیادی می برد. و اگر سازمان به شدت بوروکراتیزه شده است، به طور کلی تمام اعصاب را در آنجا رها کنید. دقیقاً کاهش این نوع طراحی است که در متدولوژی های توسعه سریع مدرن مورد بحث قرار می گیرد که در بالا به آن اشاره کردم. به هر حال، همه آنها بر اساس رویکرد کلاسیک XP (برنامه نویسی شدید) هستند که در حال حاضر حدود 20 سال از عمر آن می گذرد. بنابراین یک شرایط مرجع با کیفیت بالا، قابل درک برای مشتری تهیه کنید و از طراحی فنی به عنوان یک سند داخلی برای ارتباط بین معمار سیستم و برنامه نویسان استفاده کنید.

یک جزئیات جالب در مورد طراحی فنی: برخی از ابزارهای توسعه که بر اساس اصل جهت‌گیری موضوعی مرتب شده‌اند (مانند 1C و موارد مشابه) نشان می‌دهند که طراحی (به معنای فرآیند مستندسازی) فقط در مناطق واقعاً پیچیده که تعامل بین کل زیرسیستم‌ها مورد نیاز است، مورد نیاز است. در ساده ترین حالت، به عنوان مثال، برای ایجاد یک کتاب مرجع، یک سند، تنها الزامات تجاری که به درستی فرموله شده اند کافی است. این را استراتژی تجاری این پلتفرم در زمینه آموزش متخصصان نشان می دهد. اگر به بلیط امتحان یک متخصص نگاه کنید (این چیزی است که به آن می گویند و نه "برنامه نویس") ، خواهید دید که فقط الزامات تجاری در آنجا وجود دارد و نحوه پیاده سازی آنها در یک زبان برنامه نویسی وظیفه این است. یک متخصص آن ها آن قسمت از وظیفه ای که طراحی فنی برای حل آن طراحی شده است، متخصص باید "در سر" حل کند (ما در مورد وظایف با پیچیدگی متوسط ​​صحبت می کنیم)، و اینجا و اکنون، پیروی از استانداردهای خاصی از توسعه و طراحی، که دوباره توسط شرکت 1C برای پلتفرم خود تشکیل شده است. بنابراین، از بین دو متخصص که نتیجه کارشان یکسان است، یکی می تواند در امتحان قبول شود و دومی نمی تواند، زیرا. استانداردهای توسعه را به شدت نقض کرده است. بدیهی است که فرض بر این است که متخصصان باید چنین صلاحیت هایی داشته باشند که بتوانند کارهای معمولی را به تنهایی و بدون دخالت معماران سیستم طراحی کنند. و این رویکرد کار می کند.

بیایید بررسی این سوال را ادامه دهیم: "چه الزاماتی باید در شرایط مرجع گنجانده شود؟"

تدوین الزامات سیستم اطلاعاتی ساختار شرایط مرجع

مانند هر فعالیت دیگری، تدوین الزامات را می توان (و باید) به مراحل تقسیم کرد. هر چیزی زمان خودش را دارد. این کار فکری سختی است. و اگر با توجه کافی درمان نشود، نتیجه مناسب خواهد بود. بر اساس برآوردهای کارشناسان، هزینه توسعه شرایط مرجع می تواند 30-50٪ باشد. من هم بر همین عقیده هستم. اگرچه 50 شاید خیلی زیاد باشد. پس از همه، شرایط مرجع هنوز نیست آخرین سند، که قرار است توسعه یابد. بالاخره باید طراحی فنی هم وجود داشته باشد. این تنوع به دلیل پلتفرم ها، رویکردها و فناوری های مختلف اتوماسیون است که توسط تیم های پروژه در طول توسعه استفاده می شود. به عنوان مثال، اگر ما در مورد توسعه در یک زبان کلاسیک مانند C ++ صحبت می کنیم، طراحی فنی دقیق ضروری است. اگر در مورد اجرای یک سیستم بر روی پلت فرم 1C صحبت می کنیم، همانطور که در بالا دیدیم، وضعیت طراحی تا حدودی متفاوت است (اگرچه، هنگام توسعه یک سیستم از ابتدا، طبق طرح کلاسیک طراحی شده است).

با وجود اینکه بیانیه الزامات بخش اصلی شرایط مرجع است و در برخی موارد تنها بخش TOR می شود، باید توجه داشته باشید که این یک سند مهم است و باید ترسیم شود. بر این اساس بالا از کجا شروع کنیم؟ اول از همه، باید از محتوا شروع کنید. محتوا را بنویسید و سپس شروع به باز کردن آن کنید. من شخصاً این کار را انجام می دهم: ابتدا محتوا را ترسیم می کنم ، اهداف ، تمام اطلاعات مقدماتی را شرح می دهم و سپس بخش اصلی - تدوین الزامات را بر عهده می گیرم. چرا برعکس نه؟ نمی دونم برای من راحت تره اولاً، این بخش بسیار کوچک‌تری از زمان است (در مقایسه با الزامات)، و ثانیاً، در حالی که تمام اطلاعات مقدماتی را توصیف می‌کنید، به موضوع اصلی توجه می‌کنید. خب هر کی دوست داره با گذشت زمان، شما الگوی خود را از شرایط مرجع توسعه خواهید داد. برای شروع، من توصیه می کنم دقیقا همان چیزی را که در GOST توضیح داده شده است، به عنوان محتوا انتخاب کنید. برای محتوا عالی است! سپس هر بخش را می‌گیریم و شروع به توصیف می‌کنیم، بدون اینکه توصیه‌هایی را برای سه ویژگی زیر فراموش کنیم: قابل درک بودن، اختصاصی بودن و آزمایش‌پذیری. چرا اینقدر روی این موضوع اصرار دارم؟ بیشتر در این مورد در بخش بعدی. و اکنون من تمام تدبیر را پیشنهاد می کنم تا از آن نقاط TK که در GOST توصیه می شود عبور کنیم.

1. اطلاعات کلی؛
2. هدف و اهداف ایجاد (توسعه) سیستم؛
3. ویژگی های اشیاء اتوماسیون؛
4. سیستم مورد نیاز؛
5. ترکیب و محتوای کار در ایجاد سیستم؛
6. روش کنترل و پذیرش سیستم؛
7. الزامات ترکیب و محتوای کار برای آماده سازی شی اتوماسیون برای راه اندازی سیستم.
8. ملزومات مستندسازی؛
9. منابع توسعه

بخش 1. اطلاعات عمومی.

و بنابراین، ما تمام بخش هایی را که می تواند در شرایط مرجع گنجانده شود در نظر گرفته ایم. "می توان"، نه "باید" دقیقاً به این دلیل که هر سندی باید برای دستیابی به نتیجه تدوین شود. بنابراین، اگر برای شما واضح است که برخی از بخش های جداگانه شما را به نتیجه نزدیک نمی کند، پس نیازی به آن ندارید و نیازی به اتلاف وقت برای آن ندارید.

اما بدون نکته اصلی: الزامات عملکردی، هیچ یک از شرایط مرجع کامل نیست. من می خواهم توجه داشته باشم که در عمل با چنین شرایط مرجعی مواجه می شویم و چگونه! ارقامی وجود دارند که می توانند آب ها را در همه بخش ها رقیق کنند، الزامات کلی را به طور کلی توصیف کنند و سند بسیار سنگین است و کلمات هوشمندانه زیادی در آن وجود دارد و حتی ممکن است مشتری دوست داشته باشد. آن را (یعنی آن را تایید خواهد کرد). اما ممکن است نتوان روی آن کار کرد، یعنی. کاربرد عملی کمی برای آن وجود دارد. در بیشتر موارد، چنین اسنادی زمانی متولد می شوند که شما به طور خاص برای شرایط مرجع نیاز به دریافت پول زیادی دارید و باید آن را به سرعت و بدون غوطه ور شدن در جزئیات انجام دهید. و به خصوص اگر معلوم باشد که کارها جلوتر نخواهد رفت یا افراد کاملاً متفاوتی این کار را انجام خواهند داد. به طور کلی، فقط برای توسعه بودجه، به ویژه دولت.

در مقاله دوم، ما فقط در مورد بخش 4 "نیازهای سیستم" صحبت خواهیم کرد و به طور خاص، الزامات را به دلایل وضوح، ویژگی و آزمایش پذیری فرمول بندی خواهیم کرد.

چرا الزامات باید واضح، مشخص و قابل آزمایش باشد.

وظیفه فنی چیست؟ چگونه این کار را انجام دهیم و چرا لازم است؟ مثال ها، نمونه ها، نکات و ترفندها.

به نظر می رسد چقدر عالی است وقتی شما را کاملاً درک می کنند. او چند عبارت را بیان کرد و این همان چیزی است که شما تصور می کردید. متاسفانه اینطوری کار نمیکنه

مشکل درک اطلاعات ابدی است. اثر "تلفن خراب" یک اتفاق رایج است. و اگر نمی دانید چگونه یک وظیفه تعیین کنید چه باید بگویید؟ بله، این نیز اتفاق می افتد و شما باید به نوعی با آن کار کنید، اما چگونه؟ برای اینکه نتایج کارهایی که تعیین می کنید انتظارات شما را برآورده کند، شرایط مرجع را بنویسید.

کار فنی چیست

شرایط مرجع (یا TOR) - سندی که شامل الزامات مشتری برای محصولات یا خدمات ارائه شده توسط پیمانکار است. به زبان ساده: من می خواهم به طوری و به طوری که هفت خط عمود بر هم وجود داشته باشد، و حتی برخی به رنگ قرمز، و برخی از رسم بی رنگ (ویدئویی در مورد این موضوع در پایان مطالب، توصیه می کنم آن را تماشا کنید).

واحد طراحی

این سند می تواند یک صفحه A4 یا یک جلد کامل داشته باشد، همه اینها به وظایف و خواسته هایی بستگی دارد که در آن گنجانده شده است. به عنوان مثال، می توانید یک کار فنی برای یک صفحه فرود کوچک (سایت یک صفحه ای) یا برای نرم افزارهای پیچیده با یادگیری ماشین و سایر ویژگی ها بنویسید.

چرا به یک کار فنی نیاز دارید؟

• برای تعیین تکلیف برای مجریان.
• برای توصیف جزئیات آنچه می خواهید در پایان به دست آورید.
• برای توافق بر سر ترتیب کار.
• ارزیابی و پذیرش کار پس از اجرا.
• به ... (گزینه های خود را در نظرات اضافه کنید).

در واقع، قرارها و مزایای کار فنی بسیار بیشتر از لیست بالا است. برای من شخصا، وظیفه اصلی که TK حل می کند، اجرای چیزی است که نیاز دارم، با حداقل انحراف از انتظارات (انتظارات من).

با تشکر از TK، همیشه می توانید در مورد زمان اجرا، هزینه و مطابقت با ویژگی های اعلام شده محصول یا خدمات نهایی سوال کنید.

در واقع این یک سند جدی است که توسط مشتری و پیمانکار تنظیم می شود. تا جایی که مجازات ها و تعهدات طرفین مقرر شده است. تعدادی GOST وجود دارد، در Habré بیشتر بخوانید.

توسعه مشخصات فنی

اگر ما در مورد بازی "به روش بزرگسالان" صحبت می کنیم، به عنوان مثال، شرایط مرجع برای توسعه اپلیکیشن موبایلیا یک وب سایت، پس این یک کار جداگانه است که برای آن پول زیادی پرداخت می شود. شما یک نفر را که معمولاً یک مدیر فنی سابق یا فعلی است، می آورید و از آنها می خواهید که به شما کمک کنند.

ریش اختیاری است

بسته به حجم پروژه / وظایف، این شخص تمام "لیست آرزوهای شما" را جمع آوری می کند، آنها را به زبان فنی، شاید طرح هایی را آماده کند (تقریبا چگونه باید باشد) و سند تمام شده را به شما می دهد. سپس این سند را به مجریان (یک تیم در شرکت خود یا برای برون سپاری) انتقال می دهید، روی پول، شرایط توافق می کنید و دست به کار می شوید.

نکته: CTO باید در تیم شما باشد، در غیر این صورت به احتمال زیاد در فرآیند اجرا متوجه چیزی نخواهید شد. شما به سادگی برای همه چیز دانش کافی ندارید. چه کسی در نوشتن TK شرکت کرده است، او بررسی می کند.

مشخصاتش چیه

همه چیز به قالبی که انتخاب می‌کنید بستگی دارد (من کمی بعد پیوندهایی به الگوها/مثال‌ها خواهم داد)، اما بلوک‌های اساسی وجود دارد که در شرایط مرجع گنجانده شده‌اند:

1. شرح پروژه/وظیفه. به طور خلاصه می نویسیم که چه نوع پروژه یا وظیفه ای باید تکمیل شود.
2. هدف و اهداف. اهداف پروژه چیست.
3. الزامات. طراحی، ویژگی ها، فناوری های مورد نیاز.
4. شرح آثار. چه، چه زمانی و چگونه انجام خواهد شد.
5. مراحل کنترل و پذیرش نحوه پذیرش کار، چه چیزی را می توان تکمیل شده در نظر گرفت.
6. برنامه های کاربردی. طرح ها، طرح ها، نمونه های اولیه.

هزینه کار معمولاً در داخل گرفته می شود برنامه جداگانهبه قرارداد، اما زمانی اتفاق می افتد که طرفین مبالغ را در خود شرایط مرجع تعیین کنند.

ببخشید که خواندنم را قطع کردم. به کانال تلگرام من بپیوندید. اعلامیه های جدید مقالات، توسعه محصولات دیجیتال و هک رشد، همه چیز وجود دارد. در انتظار شما! ادامه می دهیم...

نمونه هایی از شرایط مرجع

با وجود این واقعیت که توسعه مشخصات فنی یک فرآیند پیچیده است، اما بسیار جالب است. وظیفه شما این است که تصویری از نتیجه نهایی را دوباره ایجاد کنید و سپس آن را در قسمت‌هایی توصیف کنید.

نمونه ای از یکی از مشخصات فنی من برای به روز رسانی برنامه تلویزیون هوشمند. وظایف برای محصولات پیچیده تر و پیچیده تر از قبل با کمک همکاران بخش فنی جمع آوری شده بود. با خیال راحت از همکاران خود کمک بخواهید، تا جایی که ممکن است آنها را در این فرآیند مشارکت دهید. و بازخورد را فراموش نکنید! هیچ چیز بدتر از صرف زمان و تلاش برای چیزی بدون اطلاع از نتایج نیست. به ما بگویید که مشاوره آن شخص در کار شما چقدر مفید بوده است، در غیر این صورت یک بازی یک طرفه است.

شرایط مرجع برای توسعه یک فروشگاه آنلاین

شرایط مرجع برای توسعه یک برنامه تلفن همراه

TK در سایت

ToR برای خدمات/به روز رسانی

اگر به نمونه های بیشتری نیاز دارید، فقط آن را در گوگل جستجو کنید.

توصیه اصلی انجام آن است. مشکل اینجاست که تنبلی مادر بر همه چیره می شود و مقاومت در برابر او آسان نیست. تمام اراده خود را در یک مشت جمع کنید و شروع به نوشتن شرایط مرجع کنید، فقط بنویسید و متوقف نشوید. نگران نباشید که "کاملا" کار نمی کند، من رازی را فاش خواهم کرد، این اتفاق نمی افتد. فقط بنویس، هر بار بهتر و بهتر خواهد شد.

این طوری باید باشد

اولین اصول اولیه نوشتن مشخصات فنی من چند سال پیش ظاهر شد. من با طراحان کار کردم و وظیفه ایجاد خلاقیت برای کمپین های تبلیغاتی را تعیین کردم. نامنسجم آن را می‌خواهد و به انبوهی از وقت تلف شده و توضیحات تبدیل شد. با گذشت زمان، تنظیم وظایف به نوعی بلوک های معنایی و سپس به نوعی کار فنی تبدیل شد.

به عنوان مثال، برای کار "دکمه لایک در سایت":

1. توضیحات: شما باید یک دکمه "پسندیدن" در وب سایت ما ایجاد کنید.
2. هدف و اهداف: مشارکت کاربر، صدور / رتبه بندی مطالب بر اساس تعداد لایک ها.
3. الزامات: چنین طراحی (مثال: پیوند به چیزی مشابه)، عملکرد (هر کاربری می تواند به تصویر امتیاز دهد و آن را دوست داشته باشد، سیستم سایت تعداد لایک ها را در نظر می گیرد و خروجی مواد را تغییر می دهد)، فناوری (موجود در دسکتاپ). و نسخه های موبایلسایت).
4. شرح کار: ترسیم 3 طرح بندی برای دکمه ها (تاریخ تکمیل: 10/01/17)، توسعه یک سیستم برای صدور مواد بر اساس لایک (تاریخ: 10/14/17)، تست عملکرد (تاریخ: 10/16/17) ، انتشار (تاریخ: 17/10/17)
5. پذیرش آثار: کاربر روی دکمه لایک کلیک می کند، سیستم کلیک را می شمارد، تحویل مواد تغییر می کند.
6. برنامه‌ها: طرح‌ها، طرح‌ها، نمونه‌هایی از پروژه‌هایی که عملکرد مشابهی در آنها کار می‌کند.

بخش‌ها و بخش‌هایی از ساختار را که برای کارهای شما لازم است، برای خود بگذارید. به عنوان مثال، بلوک ششم "برنامه ها" را می توان در الزامات عملکردی توصیف کرد. توصیه اصلی: به هر طریقی کار را با توجه به ساختار شرایط مرجع توصیف کنید. بنابراین، لحظات مهم را از دست نخواهید داد و خود را از سؤالات غیر ضروری نجات نمی دهید و زندگی همکاران خود را ساده می کنید.

بفرمایید

ما تجزیه و تحلیل کرده ایم که یک کار فنی چیست و چگونه آن را انجام دهیم. اکنون شما این توانایی را دارید که به وضوح و واضح اهداف را تعیین کنید، افکار خود را به افراد دیگر منتقل کنید و در وقت خود برای توضیحات اضافی صرفه جویی کنید. امیدوارم اکنون بدانید که با همه اینها چه کار کنید.

شرایط مرجع منبعی برای ایجاد یک سیستم اطلاعاتی یا محصول دیگر است. بنابراین، شرایط مرجع (به اختصار TOR) باید قبل از هر چیز حاوی الزامات فنی اصلی برای محصول باشد و به این سؤال پاسخ دهد که این سیستم باید چه کاری انجام دهد، چگونه کار کند و در چه شرایطی کار کند.

به عنوان یک قاعده، مرحله تنظیم شرایط مرجع با نظرسنجی انجام می شود موضوع، که با تهیه گزارش تحلیلی به پایان می رسد. این گزارش تحلیلی (یا یادداشت تحلیلی) است که اساس سند شرایط مرجع را تشکیل می دهد.

اگر بتوان نیازهای مشتری را در گزارش خلاصه کرد و با نمودارهای UML نشان داد، شرایط مرجع باید با جزئیات تمام الزامات کاربردی و کاربری سیستم را شرح دهد. هرچه شرایط مرجع دقیق تر باشد، اختلافات کمتری بین مشتری و توسعه دهنده در طول آزمون های پذیرش ایجاد می شود.

بنابراین، شرایط مرجع سندی است که به توسعه‌دهنده و مشتری اجازه می‌دهد محصول نهایی را ارائه کنند و متعاقباً مطابقت با الزامات را بررسی کنند.

استانداردهای راهنمایی برای نوشتن شرایط مرجع GOST 34.602.89 "شرایط مرجع برای ایجاد یک سیستم خودکار" و GOST 19.201-78 "شرایط مرجع". الزامات محتوا و طراحی استاندارد اول برای توسعه دهندگان سیستم های خودکار در نظر گرفته شده است، استاندارد دوم برای ابزارهای نرم افزاری(ما تفاوت بین این سری ها را در مقاله "GOST چیست" مورد بحث قرار دادیم).

بنابراین، در زیر لیست و شرح بخش هایی را ارائه می دهیم که شرایط مرجع باید مطابق با GOST ها باشد.

بنابراین، سند شرایط مرجع باید در واقع تمام الزامات محصول در حال طراحی را که در مرحله مطالعه تحلیلی شی اتوماسیون شناسایی شده است، منعکس کند.

بر اساس جدول بالا، می‌توانیم بخش‌های اصلی شرایط مرجع را برجسته کنیم:

• اطلاعات عمومی در مورد سیستم (برنامه)؛
• هدف، اهداف و اهداف سیستم (برنامه)؛
• الزامات سیستم (نیازهای عملکردی، نیازهای کاربر، الزامات سیستم به عنوان یک کل و غیره)؛
• الزامات انواع وثیقه؛
• ملزومات مستندسازی؛
• مراحل و مراحل توسعه؛
• دستور کنترل و پذیرش سیستم (برنامه).

اطلاعات کلی
این بخش از سند شرایط مرجع باید شامل نام کامل سیستم و تمام اختصاراتی باشد که در توسعه اسناد استفاده می شود.

مثال:

"که در این سندسیستم اطلاعاتی در حال ایجاد "پنجره واحد برای دسترسی به منابع آموزشی" نامیده می شود که به اختصار SW نامیده می شود.
پنجره واحد سیستم برای دسترسی به منابع آموزشی از این پس ممکن است به عنوان پنجره واحد یا سیستم نامیده شود.

همچنین باید شامل بخش های فرعی گزارش جزئیات سازمان های درگیر در توسعه (مشتری و پیمانکار) باشد.

بخش فرعی "مبانی توسعه" سند شرایط مرجع، اسناد اصلی را فهرست می کند که بر اساس آنها این کارها انجام می شود. به عنوان مثال، برای سیستمی که توسط دولت یک کشور یا ارگان دولتی دیگر راه اندازی شده است، قوانین، فرامین و قطعنامه های دولت باید مشخص شود.

بخشی جدایی ناپذیر از سند شرایط مرجع نیز باید فهرستی از اصطلاحات و اختصارات باشد. اصطلاحات و اختصارات بهتر است در قالب یک جدول با دو ستون "Term" و "Full Form" ارائه شوند.

اصطلاحات و اختصارات در قرار دارند به ترتیب حروف الفبا. اول از همه، مرسوم است که رمزگشایی به اصطلاحات و اختصارات روسی زبان، سپس به انگلیسی زبان داده شود.

هدف و اهداف ایجاد سیستم

این بخش از سند شرایط مرجع باید شامل هدف و اهداف ایجاد سیستم باشد.

مثال:

"سیستم اطلاعات "پنجره واحد برای دسترسی به منابع آموزشی" برای ارائه اطلاعات کامل، عملیاتی و راحت در مورد سیستم آموزشی فدراسیون روسیه، سازمان هایی که عملکرد موسسات آموزشی را انجام می دهند، طراحی شده است.

هدف اصلی سیستم، تشکیل یک نظام واحد است محیط اطلاعاتیو اتوماسیون فرآیندهای تجاری موسسات آموزشی فدراسیون روسیه.

ایجاد سیستم اطلاعاتی "پنجره واحد" باید فراهم کند:

• ارائه طیف گسترده ای از منابع اطلاعاتی به کاربران؛
• سطح بالا امنیت اطلاعات;
• بهبود کارایی مؤسسات و بخش‌های آموزشی با بهینه‌سازی تعدادی از فرآیندهای تجاری؛
• افزایش کارایی فرآیند تعامل بین سیستم های اطلاعاتی و خدمات درون بخش.

ایجاد سیستم در نتیجه افزایش کارایی بخش، هزینه های عملیاتی را کاهش می دهد.

سیستم مورد نیاز

این بخش از سند شرایط مرجع برای توصیف الزامات عملکردی اصلی سیستم در نظر گرفته شده است. این مهمترین بخش شرایط مرجع است، زیرا بحث اصلی شما در اختلافات با مشتری در فرآیند راه اندازی سیستم خواهد بود. از این رو باید با دقت بیشتری به نگارش آن پرداخت.

سند شرایط مرجع باید شامل تمام الزامات شناسایی شده در مرحله تجزیه و تحلیل شی اتوماسیون باشد. بهتر است فرآیندهای تجاری اصلی را برجسته کنید، که باید از طریق شرح الزامات عملکردی افشا شوند.

مثال:

"4.1 فرآیند کسب و کار" ارائه اطلاعات در مورد موسسات آموزشی فدراسیون روسیه

شرکت کنندگان زیر در این فرآیند تجاری متمایز هستند:

مدیر - کارمند بخش که بخشی از پرسنل خدمات سیستم است و مسئول صحت داده های ارائه شده است.

کاربر - شهروندی که نیاز به دریافت اطلاعات در مورد کار موسسات آموزشی فدراسیون روسیه دارد.

4.1.1 ثبت موسسه آموزشی در سامانه

ثبت نام یک مؤسسه آموزشی فدراسیون روسیه توسط کارمند مسئول مؤسسه انجام می شود ("فرمان دولتی ...").

فرآیند ثبت نام موسسه آموزشی شامل مراحل زیر است:

• نویسنده یک رکورد سازمانی ایجاد می کند.
• نویسنده داده های سازمان را وارد می کند.
• سیستم برای مجوز این سازمان بررسی می کند

• اگر مجوز در پایگاه داده وجود داشته باشد، سیستم پیامی در مورد ثبت موفقیت آمیز به نویسنده ارسال می کند.
• اگر مجوز در پایگاه داده یافت نشد، سیستم پیامی در مورد عدم وجود مجوز برای این سازمان به نویسنده ارسال می کند.

اگر زمان اجازه دهد، اطلاعات ارائه شده در این بخش باید به طور کامل در پیوست سند شرایط مرجع افشا شود. در ضمیمه شرایط مرجع، می توانید یک فرم صفحه نمایش بیاورید و در زیر تمام رویدادهایی را که روی آن وجود دارد (ایجاد، مشاهده، ویرایش، حذف و غیره) شرح دهید.

الزامات برای سیستم به عنوان یک کل شامل افشای معماری آن با توصیف همه زیرسیستم ها است. این بخش از شرایط مرجع باید الزامات یکپارچه سازی سیستم با سایر محصولات (در صورت وجود) را شرح دهد. علاوه بر این، شرایط مرجع باید شامل موارد زیر باشد:

• الزامات برای حالت های عملکرد سیستم
• شاخص های مقصد
• الزامات قابلیت اطمینان
• الزامات ایمنی
• الزامات مربوط به تعداد و صلاحیت پرسنل و نحوه کار آنها
• الزامات امنیت اطلاعات
• الزامات ایمنی اطلاعات در صورت بروز حوادث
• الزامات ترخیص اختراع
• الزامات استانداردسازی و یکسان سازی
• و غیره.

الزامات انواع وثیقه

در این بخش از سند شرایط مرجع، الزامات مربوط به پشتیبانی ریاضی، اطلاعاتی، زبانی، نرم افزاری، فنی و سایر انواع پشتیبانی (در صورت وجود) باید ارائه شود.

ملزومات مستندسازی

بخش «الزامات مستندات» شرایط مرجع شامل فهرستی از اسناد طراحی و عملیاتی است که باید در اختیار مشتری قرار گیرد.

این بخش از شرایط مرجع به اندازه شرح الزامات عملکردی مهم است، بنابراین نباید به عبارت "کلیه اسناد و مدارک مطابق با GOST 34 به مشتری ارائه شود." این بدان معنی است که شما باید کل بسته اسناد از جمله "فرم"، "گذرنامه" و غیره را ارائه دهید. اکثر اسناد لیست مشخص شده در GOST 34.201-89 نه توسط شما و نه برای مشتری مورد نیاز نیست، بنابراین بهتر است بلافاصله در مرحله تدوین سند شرایط مرجع، با لیست موافقت کنید.

حداقل بسته اسناد معمولاً شامل:

• وظیفه فنی؛
• بیانیه طراحی پیش نویس (فنی)؛
• یادداشت توضیحی طراحی فنی؛
• شرح سازمان پایگاه اطلاع رسانی;
• راهنمای کاربر؛
• راهنمای مدیر؛
• روش برنامه و آزمون؛
• پروتکل آزمون پذیرش؛
• مدرک اتمام کار

فهرست اسناد در شرایط مرجع بهتر است در قالب یک جدول ارائه شود که نشان دهنده نام سند و استانداردی است که بر اساس آن باید توسعه یابد.

مراحل و مراحل توسعه

در این بخش از سند شرایط مرجع، باید اطلاعاتی در مورد تمام مراحل انجام کار ارائه شود.

شرح مرحله باید شامل نام، شرایط، شرح کار و نتیجه نهایی باشد.

مراحل کنترل و پذیرش سیستم

در این بخش از سند شرایط مرجع، لازم است مدرکی را مشخص کنید که بر اساس آن آزمون های قبولی باید انجام شود.

در صورت لزوم، شرایط مرجع را می توان با بخش های دیگر تکمیل یا با حذف موارد نامناسب کاهش داد.

هنگام تغییر ساختار شرایط مرجع، برای جلوگیری از موقعیت های تضاد، باید قبل از تدوین سند با مشتری توافق شود.

این متن صرفاً به خاطر وجود یک پیوند دائمی ایجاد شده است که خود نویسنده و همه شما با خیال راحت می‌توانید آن را در قالب یک پاسخ استاندارد به این سؤال برای مشتریان، همکاران، بستگان و آشنایان آینده خود ارسال کنید: "آیا به TK شما و به طور کلی این نیاز دارم؟"

همانطور که می گویند - "به جای هزار کلمه"، زیرا هر بار بشارت دادن به مدت 4-5 ساعت در اسکایپ در مورد این موضوع از قبل خسته کننده می شود و تمایل جهانی به لغزش بیهوده های صریح تحت تعریف "شرایط مرجع" در طول سال ها فقط تشدید می شود.

مسئله

واقعیت این است که وقتی یک قالب خاص و همچنین یک تعریف واضح و قابل درک از یک اصطلاح وجود دارد، تمام دستکاری ها و جایگزینی ها برای خلاصه ها، نمونه های اولیه، پرسشنامه های اختراع شده، توضیحات و برنامه های کاربردی ساده حداقل غیرحرفه ای به نظر می رسند. بنابراین، با تعریف علمی مفهوم خود، شروع می کنیم:

شرایط مرجع - سند اصلی برای طراحی یک شی فنی (محصول). TOR هدف اصلی شی در حال توسعه، مشخصات فنی، شاخص های کیفیت و الزامات فنی و اقتصادی، نسخه تکمیل مراحل لازم ایجاد اسناد (طراحی، فناوری، نرم افزار و غیره) و ترکیب آن را تعیین می کند. به عنوان الزامات خاص شرایط مرجع یک سند قانونی است - به عنوان یک پیوست در قرارداد بین مشتری و پیمانکار برای کار طراحی گنجانده شده است و مبنای آن است: روش و شرایط کار را تعیین می کند، از جمله هدف، اهداف، اصول، نتایج و مهلت های مورد انتظار یعنی باید معیارهای عینی وجود داشته باشد که با آن بتوان تشخیص داد که این یا آن کار انجام شده است یا خیر. کلیه تغییرات، اضافات و توضیحات در متن TOR باید با مشتری توافق شده و توسط او تأیید شود. این نیز ضروری است زیرا در صورت کشف نادرستی یا داده های اولیه اشتباه در روند حل مشکل طراحی، تعیین میزان گناه هر یک از طرفین درگیر در توسعه، توزیع زیان های وارده در توسعه ضروری است. ارتباط با این شرایط مرجع، به عنوان یک اصطلاح در حوزه فناوری اطلاعات، یک سند قانونی مهم است که حاوی اطلاعات جامعی است که برای تعیین وظایف مجریان برای توسعه، پیاده‌سازی یا یکپارچه‌سازی محصول نرم‌افزاری، سیستم اطلاعاتی، وب‌سایت، پورتال یا سایر خدمات فناوری اطلاعات ضروری است.

ما به زبان قابل فهم ترجمه می کنیم

1) شرایط مرجع - وظیفه را تعیین می کند. این بدان معنی است که باید قبل از یک نمونه اولیه، طرح، آزمایش، پروژه طراحی باشد، زیرا هر نقشه ذهنی، نمودار جریان داده، معماری قبلاً انجام یک کار خاص است، این پاسخ به یک سؤال است. و قبل از اینکه خود این سؤال هنوز توسط همه طرف ها پرسیده، فرموله و امضا نشده باشد - هر پاسخی پیشینی اشتباه خواهد بود، درست است؟ بنابراین، شروع هر کار بر روی هر پروژه ای بیان مشکل است و نه جستجوی دیوانه وار برای طرح کلی ده ها گزینه برای حل آن.

2) در واقع، یک مورد جدید به طور منطقی از پاراگراف اول دنبال می شود - متن خود TK باید با فصل "اهداف و اهداف" شروع شود، که به وضوح مشخص می کند که این تلاش بعدی برای افزایش آنتروپی در جهان چه اهداف تجاری را دنبال می کند. یک کار بی هدف که هیچ مشکلی را حل نمی کند، به هیچ چیز نمی رسد و "از سر کسالت" انجام می شود - رسماً یک شرایط مرجع محسوب نمی شود و از این پس در وضعیت "یک تکه کاغذ معمولی" قرار می گیرد.

3) چگونه می توانید بفهمید که طرح مفهومی پیشنهادی یا نمونه اولیه تعاملی یا حتی یک سایت آماده برای استفاده، مشکل تجاری فوق را حل می کند؟ هیچ کاری نمی‌توان کرد، باید دوباره به تعریف بازگردیم: «نتایج و مهلت‌های مورد انتظار را تعریف می‌کند. یعنی باید معیارهای عینی وجود داشته باشد که با آن بتوان تشخیص داد که این یا آن کار انجام شده است یا خیر.» یعنی هیچ TK بدون شاخص های قابل اندازه گیری واضح در روبل، ثانیه، تن کیلومتر یا درجه سانتیگراد نمی تواند وجود داشته باشد. خلاصه می تواند، یا یک نمونه اولیه، یا هر تکه کاغذ پوچ دیگری، اما نه شرایط مرجع.

از این نتیجه می‌گیریم که در این TOR باید یک فصل "رویه پذیرش و ارزیابی" وجود داشته باشد، زمانی که همین شاخص‌ها گرفته می‌شوند، اندازه‌گیری می‌شوند و طرفین یا دست می‌دهند یا پروژه را برای دوباره کاری ارسال می‌کنند.

4) شرایط مرجع باید لزوماً با طرح تجاری کلی مشتری، با استراتژی توسعه کسب و کار و تجزیه و تحلیل بخش بازار سازگار باشد. همه اینها به شما امکان می دهد اهداف درستی را تعیین کنید ، معیارهای دقیق را بدست آورید ، که براساس آن می توانید محصول اطلاعات نهایی را به اندازه کافی بپذیرید. فقدان طرح تجاری توسط مشتری به طور خودکار اجرای غیرحرفه ای شرایط مرجع را تضمین می کند.

آیا استودیوی برون سپاری اهداف تجاری و شاخص های قابل اندازه گیری کسب و کار را بهتر از صاحب خود می داند؟ بدیهی است که خیر، به این معنی که TOR صحیح باید توسط نمایندگان مشتری نوشته شود، نه توسط کارمندان پیمانکار. پوچ است وقتی مجری برای خود وظیفه ای تعیین می کند، سپس راه هایی برای ارزیابی آن ارائه می دهد و در پایان برای خود علامت نهایی کار انجام شده را می گذارد. در حالت ایده‌آل، نباید چنین «فعالیت ابتکاری» وجود داشته باشد، اگرچه در عمل این دقیقاً همان چیزی است که در همه جا اتفاق می‌افتد، در نتیجه شرایط مرجع کمک لازم را به پروژه ارائه نمی‌کند، زیرا اغلب اساساً یک سند ساختگی است. این کار را انجام ندهید.

5) هر اصلاحیه TK تمام شده باید هزینه داشته باشد. فقط به این دلیل که یکی از طرفین نظر خود را تغییر داده، خواب کافی نداشته، ناگهان تصمیم به صرفه جویی در پول گرفته است، نمی توانید "قانون اساسی پروژه خود" را به صورت رایگان و بی پایان ویرایش کنید. هزینه هر تغییر در TOR نیز باید از قبل در فصل مربوطه به وضوح بیان شود.

ضمناً، از نظر تئوری، درست مانند هر ویرایش در طراحی یا ایجاد تغییرات در لیست صفحات یا عملکردها، باید قیمت مشخصی داشته باشد که قبل از شروع ساخت، پیش پرداخت می شود. این تغییر. من شخصاً پیشنهاد می کنم که هر تجدید نظر در TOR تایید شده 30٪ از کل بودجه پروژه برآورد شود، اما شما می توانید در غیر این صورت انجام دهید.

آیا لازم به ذکر است که در TOR فقط لازم است که از قبل بازه زمانی و بودجه کل توسعه و همچنین فهرستی از تمام منابع و محدودیت های موجود را مشخص کنید؟ نه، این خیلی واضح خواهد بود.

بنابراین: چه کنیم؟ برای چی؟ چگونه بفهمیم چه کرده ایم؟ ارزش هر پیوت چقدر است؟ - پاسخ به تمام این سؤالات که روی یک تکه کاغذ نوشته شده است، "گلوله نقره ای" است که می تواند حتی شکست خورده ترین پروژه را نیز از بین ببرد.

کنترل سوالات

1) بنابراین، آیا یک GOST رسمی برای نوشتن شرایط مرجع وجود دارد؟ - بله، حتی چند.

2) و چه، توضیحات در شرایط مرجع گنجانده نشده است صفحات مورد نظر، تعداد دکمه ها، کتابخانه های استفاده شده، دستورالعمل ها و غیره؟ - نه در خود TOR، بلکه در برنامه ها می توانید همه اینها را قرار دهید، البته با تنظیم همه اینها با اهداف، محدودیت ها و روش های بالا برای ارزیابی بیشتر نتیجه به دست آمده. حداقل تمام محتوای آینده، حداقل شرحی از شخصیت های معمولی را ارسال کنید - اما نه به جای بیانیه واضح کار، بلکه بعد از آن.

3) پس شاید من به آن نیاز ندارم؟ - شاید امروزه هزاران سایت اصلاً بدون مشخصات فنی ساخته شده باشند، همانطور که هزاران نفر در جهان از بدو تولد نابینا هستند، کاملاً خوب زندگی می کنند. اما اگر می خواهید ببینید اصلاً به کجا می روید، تصمیمات آگاهانه بگیرید و به طور مستقل نتایج به دست آمده را ارزیابی کنید، بدون مشخصات فنی نمی توانید انجام دهید.

4) پس شما و ویکی پدیا بنویسید که TK توسط مشتری ایجاد شده است. اما نمی دانم چگونه / وقت ندارم / فقط نمی خواهم خودم این کار را انجام دهم. چگونه بودن؟ - توسعه مشخصات فنی را در اختیار شخص ثالثی قرار دهید که با کسب و کار شما، وظایف آن، مخاطبان هدف و نیازهای آن آشنایی کامل داشته باشد و در عین حال از تمامی مراحل توسعه وب نیز آگاهی کامل داشته باشد. این شخص ثالث به نوعی "دفتر اسناد رسمی وب" تبدیل می شود، یعنی تضمینی برای اینکه پیمانکار شاخص های مورد نیاز شما را دست کم نگیرد یا ضرب الاجل ها را به تعویق نیندازد، و اینکه مشتری معیارهای دست یافتنی را تعیین کند و به طور ذهنی موارد ایجاد شده را ارزیابی نکند. محصول در پذیرش نهایی، تغییر موارد ثبت شده قبلی در حال حرکت.

5) و اگر TK یک سند قانونی باشد، پس من می توانم از برون سپاری شکایت کنم، نه اینکه به او پول بدهم، او را مجبور کنم همه چیز را برای بار دهم دوباره انجام دهد؟ - اگر سند به درستی تنظیم شود، اهداف و روش ارزیابی دستاورد آنها مشخص می شود. اگر سند توسط طرفین امضا شده باشد و در توافق نامه ذکر شده باشد (شرایط مرجع خود یک قرارداد نیست)، مطمئناً می توانید. اما با مختصر معمول، نمونه های اولیه، طرح هنری خلاقانه، معامله ایمن در FL - نه بیشتر.

6) آنها به من می گویند که کار بر اساس نوعی اسکرام یا چابک انجام می شود. به این معنی که من دیگر نیازی به TK قدیمی ندارم. درست است؟ - خودتان قضاوت کنید: آنها شما را کلمه ای نامفهوم می نامند، بدیهی است که چیزی پوشاننده است، و اکنون، بر اساس اصطلاحی که برای شما ناآشنا است، پیشنهاد می کنند سندی را که از نظر قانونی صلاحیت دارد و پر از اهداف و معیارها است، کنار بگذارید. Agile خود نمی تواند اهدافی مانند "دستیابی به حداقل 10000 بازدید تا پایان سال" یا "دستیابی به بیش از 25 سفارش از سایت در یک ماه" تعیین کند - نمی توان آن را تعیین کرد، این فقط راهی برای برگزاری جلسات است. و سازمان جدیدکارکنان بی دقت چندین بار فکر کنید: "آیا در چشمان شما خاک می ریزند؟". در واقع، TK حرفه ای نمی تواند به هیچ اسکرام جدید آسیب برساند، اما مطمئنا کمک خواهد کرد.

اغلب از من می پرسند: "چگونه یک کار فنی برای یک سیستم خودکار ایجاد کنیم؟". موضوعی مشابه به طور مداوم در انجمن های مختلف مورد بحث قرار می گیرد. این سوال به قدری گسترده است که نمی توان به طور خلاصه به آن پاسخ داد. بنابراین تصمیم گرفتم مقاله ای طولانی در این زمینه بنویسم.

• در قسمت اول " توسعه مشخصات فنی. چیست، چرا لازم است، از کجا شروع کنیم و چگونه باید به نظر برسد? من سعی خواهم کرد به سؤالات موضوع به طور مفصل پاسخ دهم، ساختار و هدف شرایط مرجع را در نظر بگیرم و توصیه هایی در مورد تدوین الزامات ارائه دهم.
• بخش دوم " توسعه مشخصات فنی. نحوه تدوین الزامات? به طور کامل به شناسایی و تدوین الزامات سیستم اطلاعاتی اختصاص داده خواهد شد.

ابتدا باید بفهمید چه سوالی واقعاً مورد علاقه کسانی است که می پرسند "چگونه یک کار فنی را توسعه دهیم؟" واقعیت این است که رویکرد توسعه مشخصات فنی تا حد زیادی به اهدافی که برای آن انجام می شود و همچنین توسط چه کسی استفاده می شود بستگی دارد. در مورد چه گزینه هایی صحبت می کنم؟

• یک سازمان تجاری تصمیم به پیاده سازی یک سیستم خودکار گرفت. این سرویس فناوری اطلاعات خود را ندارد و تصمیم به انجام این کار گرفت: فرد علاقه مند باید شرایط مرجع را توسعه دهد و آن را برای توسعه به یک سازمان شخص ثالث بدهد.
• یک سازمان تجاری تصمیم به پیاده سازی یک سیستم خودکار گرفت. سرویس آی تی خود را دارد. ما تصمیم گرفتیم این کار را انجام دهیم: یک شرایط مرجع ایجاد کنیم، سپس آن را بین سرویس فناوری اطلاعات و طرف های ذینفع هماهنگ کنیم و آن را به تنهایی پیاده سازی کنیم.
• ساختار دولتی تصمیم به شروع یک پروژه فناوری اطلاعات گرفت. اینجا همه چیز خیلی گل آلود است، تشریفات زیاد، رشوه، بریدگی و... من این گزینه را در این مقاله در نظر نخواهم گرفت.

• یک شرکت فناوری اطلاعات در خدمات توسعه و / یا پیاده سازی سیستم های خودکار مشغول است. این سخت ترین مورد است، زیرا شما باید در شرایط مختلفی کار کنید:

  • مشتری متخصصان خاص خود را دارد که نظرات خود را دارند و آنها الزامات خاصی برای شرایط مرجع دارند.
  • شرایط مرجع برای توسعه دهندگان خود ما ایجاد شده است (کارفرما اهمیتی نمی دهد).
  • شرایط مرجع برای انتقال به پیمانکار (به عنوان مثال گروهی از برنامه نویسانی که خارج از کارکنان شرکت هستند یا یک متخصص فردی) ایجاد می شود.
  • در مورد نتیجه به دست آمده بین شرکت ها و مشتری سوء تفاهم وجود دارد و شرکت بارها و بارها این سوال را مطرح می کند: "شرایط مرجع چگونه باید تدوین شود؟" مورد دوم ممکن است یک پارادوکس به نظر برسد، اما حقیقت دارد.
  • گزینه های دیگر، کمتر رایج نیز ممکن است.

فکر می کنم اکنون خواننده باید سؤالاتی داشته باشد:

• چرا نمی توان شرایط مرجع را همیشه به یک شکل توسعه داد؟
• آیا استانداردها، روش ها، توصیه هایی وجود دارد؟ آنها را از کجا تهیه کنیم؟
• چه کسی باید شرایط مرجع را توسعه دهد؟ آیا این فرد نیاز به دانش خاصی دارد؟
• چگونه بفهمیم که شرایط مرجع به خوبی نوشته شده است یا خیر؟
• با هزینه چه کسی باید توسعه یابد و آیا اصلاً به آن نیاز است؟

این لیست می تواند بی پایان باشد. من با اطمینان خاطر از این واقعیت صحبت می کنم که 15 سال است که در توسعه نرم افزار حرفه ای بوده ام و در هر تیم توسعه ای که باید با آنها کار کنم، سؤال شرایط مرجع مطرح می شود. دلایل این امر متفاوت است. با مطرح کردن موضوع توسعه شرایط مرجع، به خوبی می دانم که نمی توانم آن را 100٪ برای همه علاقه مندان به موضوع ارائه کنم. اما، همانطور که می گویند، سعی می کنم "همه چیز را در قفسه ها بگذارم." کسانی که قبلاً با مقالات من آشنا هستند می دانند که من از "کپی پیست" کارهای دیگران استفاده نمی کنم، کتاب های دیگران را تجدید چاپ نمی کنم، استانداردهای چند صفحه ای و سایر اسنادی را که خودتان می توانید در اینترنت پیدا کنید، نقل قول نمی کنم. آنها را به عنوان افکار درخشان خود در نظر بگیرید. کافی است در موتور جستجو «چگونه شرایط مرجع را توسعه دهیم» تایپ کنید و می توانید مطالب جالب زیادی را بخوانید، اما متأسفانه بارها تکرار شده است. به عنوان یک قاعده، کسانی که دوست دارند در انجمن ها باهوش باشند (در نهایت سعی کنید جستجو کنید!)، هرگز خود شرایط مرجع معقولی را ایجاد نکردند و به طور مداوم توصیه های GOST را در مورد این موضوع نقل قول می کنند. و کسانی که واقعاً به طور جدی با این موضوع سروکار دارند معمولاً فرصتی برای نشستن در انجمن ندارند. به هر حال، ما همچنین در مورد GOST ها صحبت خواهیم کرد. در طول سال‌های کارم، انواع مختلفی از اسناد فنی را دیده‌ام که هم توسط متخصصان فردی و هم تیم‌های برجسته و شرکت‌های مشاور گردآوری شده‌اند. گاهی اوقات من چنین فعالیت هایی را انجام می دهم: برای خودم وقت می گذارم و از منابع غیرمعمول در مورد یک موضوع مورد علاقه اطلاعاتی را جستجو می کنم (مثلا کمی هوش). در نتیجه، من مجبور شدم اسناد مربوط به هیولاهایی مانند گازپروم، راه آهن روسیه و بسیاری از شرکت های جالب دیگر را ببینم. البته با وجود اینکه این اسناد از منابع عمومی به دست من می رسد یا بی مسئولیتی مشاوران (اطلاعات را در اینترنت پراکنده می کنند) از سیاست محرمانگی پیروی می کنم. بنابراین بلافاصله می گویم: اطلاعات محرمانه ای که متعلق به شرکت های دیگر است را بدون توجه به منابع وقوع (اخلاق حرفه ای) به اشتراک نمی گذارم.

وظیفه فنی چیست؟

اولین کاری که اکنون انجام خواهیم داد این است که بفهمیم این چه نوع حیوانی است، "شرایط مرجع".

بله، واقعاً GOST ها و استانداردهایی وجود دارد که در آنها سعی می شود این بخش از فعالیت (توسعه نرم افزار) تنظیم شود. روزی روزگاری، همه این GOST ها مرتبط بودند و به طور فعال مورد استفاده قرار می گرفتند. اکنون نظرات مختلفی در مورد مرتبط بودن این اسناد وجود دارد. برخی استدلال می کنند که GOST ها توسط افراد بسیار دوراندیش ساخته شده اند و هنوز هم مرتبط هستند. برخی دیگر می گویند که به طرز ناامیدکننده ای منسوخ شده اند. شاید کسی اکنون فکر می کرد که حقیقت جایی در وسط است. من با سخنان گوته پاسخ می‌دهم: «آنها می‌گویند که بین دو عقیده متضاد، حقیقت نهفته است. در هیچ موردی! بین آنها مشکل وجود دارد.» پس هیچ حقیقتی بین این نظرات وجود ندارد. زیرا GOST ها مشکلات عملی توسعه مدرن را آشکار نمی کنند و کسانی که آنها را مورد انتقاد قرار می دهند جایگزین هایی (خاص و سیستمیک) ارائه نمی دهند.

توجه داشته باشید که GOST به وضوح حتی تعریفی ارائه نمی دهد ، فقط می گوید: "TOR برای NPP سند اصلی است که الزامات و روش ایجاد (توسعه یا نوسازی - ایجاد بیشتر) یک سیستم خودکار را مطابق با آن تعریف می کند. که با آن توسعه NPP و پذیرش آن پس از راه اندازی انجام می شود.

اگر کسی متعجب است که من در مورد چه GOST صحبت می کنم، در اینجا آنها هستند:

• GOST 2.114-95 سیستم یکپارچه برای اسناد طراحی. مشخصات فنی؛
• GOST 19.201-78 سیستم یکپارچه اسناد برنامه. وظیفه فنی الزامات محتوا و طراحی؛
• GOST 34.602-89 فناوری اطلاعات. مجموعه ای از استانداردها برای سیستم های خودکار. شرایط مرجع برای ایجاد یک سیستم خودکار.

تعریف بسیار بهتری در ویکی پدیا ارائه شده است (حقیقت در مورد TK به طور کلی، و نه فقط برای نرم افزار): وظیفه فنیسند طراحی اصلی است فنیهدف - شی. وظیفه فنیهدف اصلی شیء در حال توسعه، ویژگی های فنی و تاکتیکی و فنی آن، شاخص های کیفیت و الزامات فنی و اقتصادی، دستورالعمل های تکمیل مراحل لازم برای ایجاد اسناد (طراحی، فناوری، نرم افزار و غیره) و ترکیب آن را تعیین می کند. و همچنین الزامات خاص یک کار به عنوان یک سند منبع برای ایجاد یک چیز جدید در همه زمینه های فعالیت وجود دارد، از نظر نام، محتوا، ترتیب اجرا و غیره متفاوت است (به عنوان مثال، یک کار طراحی در ساخت و ساز، یک کار رزمی، تکالیف، یک قرارداد برای یک اثر ادبی و غیره). ه.)"

و بنابراین، همانطور که از تعریف بر می آید، هدف اصلی شرایط مرجع، فرموله کردن الزامات برای شی در حال توسعه، در مورد ما، برای یک سیستم خودکار است.

اصلی ترین است، اما تنها. وقت آن است که چیز اصلی را به عهده بگیریم: همانطور که وعده داده شده همه چیز را "در قفسه ها" قرار دهیم.

در مورد الزامات چه چیزی باید بدانید؟ باید به وضوح درک کرد که همه الزامات باید بر اساس نوع و ویژگی ها تقسیم شوند. اکنون نحوه انجام آن را یاد خواهیم گرفت. برای جدا کردن الزامات بر اساس نوع، GOST فقط به ما کمک می کند. فهرستی از انواع الزامات که در آنجا ارائه شده است، نمونه خوبی از این است که چه نوع الزاماتی باید در نظر گرفته شود. مثلا:

• الزامات عملکرد؛
• الزامات امنیت و حقوق دسترسی؛
• شرایط لازم برای صلاحیت پرسنل؛
• …. و غیره. می توانید در مورد آنها در GOST ذکر شده بخوانید (و در زیر آنها را نیز با جزئیات بیشتری در نظر خواهم گرفت).

من فکر می کنم برای شما واضح است که الزامات به خوبی فرمول بندی شده برای عملکرد، کلید موفقیت آمیز شرایط مرجع است. این الزامات است که به بیشتر کارها و روش هایی که در مورد آنها صحبت کردم اختصاص دارد. الزامات عملکرد 90٪ از پیچیدگی توسعه شرایط مرجع است. هر چیز دیگری اغلب "استتار" است که بر اساس این الزامات قرار می گیرد. اگر الزامات ضعیف فرموله شوند، مهم نیست که چه استتار زیبایی روی آنها قرار دهید، یک پروژه موفق کار نخواهد کرد. بله، به طور رسمی تمام الزامات برآورده خواهد شد (طبق GOST J)، TOR توسعه یافته، تایید و امضا شده است و پول برای آن دریافت شده است. و چی؟ و سپس سرگرمی شروع می شود: چه باید کرد؟ اگر این یک پروژه در سفارش دولتی است، پس هیچ مشکلی وجود ندارد - چنین بودجه ای وجود دارد که در هیچ جیب قرار نمی گیرد، همه چیز در روند اجرا (در صورت وجود) روشن می شود. به این ترتیب است که بیشتر بودجه های پروژه های مربوط به سفارشات دولتی اره می شود (آنها "TK" را شلیک کردند، ده ها میلیون را ادغام کردند، اما شروع به انجام پروژه نکردند. همه تشریفات انجام شد، هیچ گناهی وجود نداشت، یک ماشین جدید نزدیک خانه. زیبایی!). اما ما در مورد سازمان های تجاری صحبت می کنیم که در آنها پول حساب می شود و نتیجه متفاوت است. بنابراین، بیایید به موضوع اصلی، نحوه توسعه بپردازیم شرایط مرجع مفید و کاربردی.

در مورد انواع نیازمندی ها گفتم اما املاک چطور؟ اگر انواع الزامات می تواند متفاوت باشد (بسته به اهداف پروژه)، پس با ویژگی ها همه چیز ساده تر است، 3 مورد از آنها وجود دارد:

1. لازمه باید باشد قابل درک;
2. لازمه باید باشد بتن;
3. لازمه باید باشد تست شده;

علاوه بر این، آخرین خاصیت بدون دو مورد قبلی، یعنی. نوعی "آزمایش تورنسل" است. اگر نتیجه یک نیاز قابل آزمایش نباشد، در این صورت یا مشخص نیست یا مشخص نیست. در مورد آن فکر کنید. در اختیار داشتن این سه ویژگی از الزامات است که مهارت و حرفه ای بودن نهفته است. در واقع همه چیز بسیار ساده است. وقتی فهمیدی

در این داستان در مورد اینکه شرایط مرجع چیست، می توان کامل کرد و به موضوع اصلی رفت: چگونگی تدوین الزامات. اما همه چیز آنقدر سریع نیست. نکته بسیار مهم دیگری نیز وجود دارد:

• شرایط مرجع باید به چه زبانی (از نظر پیچیدگی درک) نوشته شود؟
• آیا باید مشخصات توابع مختلف، الگوریتم ها، انواع داده ها و سایر موارد فنی در آن شرح داده شود؟
• و طراحی فنی که اتفاقاً در GOST ها نیز ذکر شده چیست و چه ارتباطی با شرایط مرجع دارد؟

در پاسخ به این سوالات یک چیز بسیار موذیانه وجود دارد. به همین دلیل است که اغلب در مورد کافی بودن یا نبودن جزئیات لازم از الزامات، در مورد قابل فهم بودن سند توسط مشتری و پیمانکاران، در مورد افزونگی، قالب ارائه و غیره اختلاف نظر وجود دارد. و مرز بین شرایط مرجع و طراحی فنی کجاست؟

وظیفه فنیسندی مبتنی بر الزامات است که به زبانی قابل فهم (معمول، آشنا) برای مشتری فرموله شده است. در این مورد، اصطلاحات صنعتی قابل درک برای مشتری می تواند و باید استفاده شود. نباید هیچ گونه الزامی برای ویژگی های پیاده سازی فنی وجود داشته باشد. آن ها در مرحله TK، در اصل، مهم نیست که این الزامات بر روی کدام پلت فرم اجرا می شود. اگرچه استثنائاتی وجود دارد. اگر ما در مورد پیاده سازی یک سیستم مبتنی بر یک محصول نرم افزاری موجود صحبت می کنیم، چنین الزام آور می تواند اتفاق بیفتد، اما فقط در سطح فرم های صفحه نمایش، فرم های گزارش و غیره. تحلیلگر کسب و کار.و مطمئناً برنامه نویس نیست (مگر اینکه این نقش ها را ترکیب کند، این اتفاق می افتد). آن ها این شخص باید با مشتری به زبان تجارت خود صحبت کند.

پروژه فنیسندی است که برای اجرای فنی الزامات تدوین شده در شرایط مرجع در نظر گرفته شده است. فقط این سند ساختارهای داده، راه‌اندازها و رویه‌های ذخیره‌شده، الگوریتم‌ها و سایر موارد مورد نیاز را توضیح می‌دهد. متخصصان فنی. به هیچ وجه لازم نیست که مشتری به این موضوع بپردازد (ممکن است چنین اصطلاحاتی را درک نکند). پروژه فنی انجام می دهد معمار سیستم(در اینجا ترکیب این نقش با برنامه نویس کاملا عادی است). به طور دقیق تر، گروهی از متخصصان AO به رهبری یک معمار. هرچه پروژه بزرگتر باشد، افراد بیشتری روی شرایط مرجع کار می کنند.

در عمل چه داریم؟ تماشای زمانی که کارگردان توسط شرایط مرجع برای تایید آورده می شود خنده دار است، که مملو از اصطلاحات فنی، توصیف انواع داده ها و مقادیر آنها، ساختار پایگاه داده و غیره است. او البته سعی می کند بفهمد، زیرا لازم است. برای ادعا، تلاش برای پیدا کردن کلمات آشنا بین خطوط و از دست دادن الزامات کسب و کار زنجیره ای. چه وضعیتی آشنا؟ و چگونه به پایان می رسد؟ به عنوان یک قاعده ، چنین TOR تأیید می شود ، سپس اجرا می شود و در 80٪ موارد به هیچ وجه با واقعیت کار انجام شده مطابقت ندارد ، زیرا آنها تصمیم گرفتند خیلی چیزها را تغییر دهند، دوباره انجام دهند، اشتباه فهمیدند، اشتباه فکر کردند و غیره. و غیره و سپس سری تحویل آغاز می شود. "اما اینجا آنطور که ما به آن نیاز داریم نیست"، "برای ما کار نخواهد کرد"، "خیلی پیچیده است"، "ناخوشایند است"، و غیره. آشنا؟! بنابراین می‌دانم، باید به موقع این برجستگی‌ها را پر می‌کردم.

پس در عمل چه داریم؟ اما در عمل، ما یک مرز مبهم بین شرایط مرجع و طراحی فنی داریم. به طرق مختلف بین TK و TP شناور است. و این بد است. و به این دلیل است که فرهنگ توسعه ضعیف شده است. این تا حدی به دلیل صلاحیت متخصصان است، تا حدی به دلیل تمایل به کاهش بودجه و مهلت‌ها (از همه اینها، مستندسازی زمان زیادی می‌برد - این یک واقعیت است). عامل مهم دیگری نیز وجود دارد که بر استفاده از طراحی فنی به عنوان یک سند جداگانه تأثیر می گذارد: توسعه سریع ابزارهای توسعه سریع و همچنین روش های توسعه. اما این یک داستان جداگانه است که در زیر چند کلمه در مورد آن خواهم گفت.

یک نکته کوچک اما مهم دیگر. گاهی اوقات شرایط مرجع را یک قطعه کوچک از الزامات، ساده و قابل فهم می نامند. به عنوان مثال، برای اصلاح جستجوی یک شی با توجه به برخی شرایط، یک ستون به گزارش اضافه کنید، و غیره. این رویکرد کاملا موجه است، چرا زندگی را پیچیده می کند. اما نه در پروژه های بزرگ، بلکه در پیشرفت های جزئی استفاده می شود. من می گویم این به نگهداری محصول نرم افزاری نزدیک تر است. در این مورد، شرایط مرجع ممکن است یک راه حل فنی خاص برای اجرای الزامات را نیز توصیف کند. به عنوان مثال، "ایجاد فلان تغییر در الگوریتم"، نشان دهنده یک رویه خاص و یک تغییر خاص برای برنامه نویس است. این در صورتی است که مرز بین شرایط مرجع و پروژه های فنی به طور کامل پاک شود، زیرا هیچ امکان اقتصادی برای افزایش کاغذ در جایی که نیاز نیست وجود ندارد و یک سند مفید ایجاد می شود. و درست است.

آیا واقعاً به مشخصات فنی نیاز دارید؟ پروژه مهندسی چطور؟

آیا من بیش از حد گرم شده ام؟ آیا این حتی بدون شرایط مرجع? شاید تصور کنید (به طور دقیق تر، این اتفاق می افتد) و این رویکرد پیروان زیادی دارد و تعداد آنها در حال افزایش است. به عنوان یک قاعده، پس از اینکه متخصصان جوان کتاب هایی در مورد Scrum، Agile و سایر فناوری های توسعه سریع مطالعه کردند. در واقع، اینها فناوری‌های فوق‌العاده‌ای هستند، و کار می‌کنند، فقط به معنای واقعی کلمه نمی‌گویند «نیازی به انجام کارهای فنی نیست». آنها می گویند "حداقل کاغذبازی"، به ویژه موارد غیر ضروری، نزدیک تر به مشتری، جزئیات بیشتر و نتایج سریع تر. اما هیچ کس تثبیت الزامات را لغو نکرد و در آنجا به وضوح بیان شده است. در آنجاست که الزامات بر اساس سه ویژگی فوق العاده ای که در بالا در مورد آنها صحبت کردم ثابت می شوند. فقط شعور بعضی ها طوری چیده شده که اگر چیزی را می توان ساده کرد، آن را به غیبت کامل ساده کنیم. همانطور که انیشتین گفت: آن را تا حد امکان ساده کنید، اما نه ساده تر از آن." . کلمات طلایی با همه چیز همراه است. بنابراین وظیفه فنیلازم است، در غیر این صورت پروژه موفقی نخواهید دید. سوال دیگر این است که چگونه باید آهنگسازی کرد و چه چیزی را در آنجا گنجاند. در پرتو روش‌های توسعه سریع، شما باید فقط روی الزامات تمرکز کنید و همه "استتار" را می توان دور انداخت. اصولا من با این موافقم.

پروژه فنی چطور؟ این سند بسیار مفید است و ارتباط خود را از دست نداده است. علاوه بر این، اغلب انجام بدون آن به سادگی غیرممکن است. به خصوص وقتی صحبت از برون سپاری کار توسعه باشد، یعنی. بر اساس برون سپاری اگر این کار انجام نشود، این خطر وجود دارد که چیزهای زیادی در مورد نحوه ظاهر سیستمی که در ذهن دارید یاد بگیرید. آیا مشتری باید او را بشناسد؟ اگر بخواهد چرا که نه، اما نیازی به اصرار و تایید این سند نیست، فقط کار را مهار و تداخل می کند. طراحی یک سیستم تا کوچکترین جزئیات تقریبا غیرممکن است. در این صورت باید به طور مداوم تغییراتی در طراحی فنی ایجاد کنید که زمان زیادی می برد. و اگر سازمان به شدت بوروکراتیزه شده است، به طور کلی تمام اعصاب را در آنجا رها کنید. دقیقاً کاهش این نوع طراحی است که در متدولوژی های توسعه سریع مدرن مورد بحث قرار می گیرد که در بالا به آن اشاره کردم. به هر حال، همه آنها بر اساس رویکرد کلاسیک XP (برنامه نویسی شدید) هستند که در حال حاضر حدود 20 سال از عمر آن می گذرد. بنابراین یک شرایط مرجع با کیفیت بالا، قابل درک برای مشتری تهیه کنید و از طراحی فنی به عنوان یک سند داخلی برای ارتباط بین معمار سیستم و برنامه نویسان استفاده کنید.

یک جزئیات جالب در مورد طراحی فنی: برخی از ابزارهای توسعه که بر اساس اصل جهت‌گیری موضوعی مرتب شده‌اند (مانند 1C و موارد مشابه) نشان می‌دهند که طراحی (به معنای فرآیند مستندسازی) فقط در مناطق واقعاً پیچیده که تعامل بین کل زیرسیستم‌ها مورد نیاز است، مورد نیاز است. در ساده ترین حالت، به عنوان مثال، برای ایجاد یک کتاب مرجع، یک سند، تنها الزامات تجاری که به درستی فرموله شده اند کافی است. این را استراتژی تجاری این پلتفرم در زمینه آموزش متخصصان نشان می دهد. اگر به بلیط امتحان یک متخصص نگاه کنید (این چیزی است که به آن می گویند و نه "برنامه نویس") ، خواهید دید که فقط الزامات تجاری در آنجا وجود دارد و نحوه پیاده سازی آنها در یک زبان برنامه نویسی وظیفه این است. یک متخصص آن ها آن قسمت از وظیفه ای که طراحی فنی برای حل آن طراحی شده است، متخصص باید "در سر" حل کند (ما در مورد وظایف با پیچیدگی متوسط ​​صحبت می کنیم)، و اینجا و اکنون، پیروی از استانداردهای خاصی از توسعه و طراحی، که دوباره توسط شرکت 1C برای پلتفرم خود تشکیل شده است. بنابراین، از بین دو متخصص که نتیجه کارشان یکسان است، یکی می تواند در امتحان قبول شود و دومی نمی تواند، زیرا. استانداردهای توسعه را به شدت نقض کرده است. بدیهی است که فرض بر این است که متخصصان باید چنین صلاحیت هایی داشته باشند که بتوانند کارهای معمولی را به تنهایی و بدون دخالت معماران سیستم طراحی کنند. و این رویکرد کار می کند.

بیایید بررسی این سوال را ادامه دهیم: "چه الزاماتی باید در شرایط مرجع گنجانده شود؟"

تدوین الزامات سیستم اطلاعاتی ساختار شرایط مرجع

بیایید فوراً آن را روشن کنیم: ما در مورد تدوین الزامات یک سیستم اطلاعاتی صحبت خواهیم کرد، یعنی. با فرض اینکه کار توسعه نیازمندی های کسب و کار، رسمی کردن فرآیندهای تجاری و کلیه کارهای مشاوره قبلی قبلاً تکمیل شده است. البته در این مرحله می توان برخی اصلاحات را انجام داد، اما فقط اصلاحات. پروژه اتوماسیون خود مشکل کسب و کار را حل نمی کند - این را در نظر داشته باشید. این یک بدیهیات است. بنا به دلایلی، برخی از مدیران سعی می کنند آن را رد کنند و معتقدند که اگر برنامه را بخرند، در یک تجارت آشفته نظم ایجاد می شود. اما به هر حال، بدیهیات بدیهی است که نیازی به اثبات ندارد.

مانند هر فعالیت دیگری، تدوین الزامات را می توان (و باید) به مراحل تقسیم کرد. هر چیزی زمان خودش را دارد. این کار فکری سختی است. و اگر با توجه کافی درمان نشود، نتیجه مناسب خواهد بود. بر اساس برآوردهای کارشناسان، هزینه توسعه شرایط مرجع می تواند 30-50٪ باشد. من هم بر همین عقیده هستم. اگرچه 50 شاید خیلی زیاد باشد. به هر حال، شرایط مرجع آخرین سندی نیست که باید توسعه یابد. بالاخره باید طراحی فنی هم وجود داشته باشد. این تنوع به دلیل پلتفرم ها، رویکردها و فناوری های مختلف اتوماسیون است که توسط تیم های پروژه در طول توسعه استفاده می شود. به عنوان مثال، اگر ما در مورد توسعه در یک زبان کلاسیک مانند C ++ صحبت می کنیم، طراحی فنی دقیق ضروری است. اگر در مورد اجرای یک سیستم بر روی پلت فرم 1C صحبت می کنیم، همانطور که در بالا دیدیم، وضعیت طراحی تا حدودی متفاوت است (اگرچه، هنگام توسعه یک سیستم از ابتدا، طبق طرح کلاسیک طراحی شده است).

اگرچه تدوین الزامات بخش اصلی است شرایط مرجعو در برخی موارد تنها بخش ToR می شود، باید به این نکته توجه کنید که این یک سند مهم است و باید بر اساس آن تنظیم شود. از کجا شروع کنیم؟ اول از همه، باید از محتوا شروع کنید. محتوا را بنویسید و سپس شروع به باز کردن آن کنید. من شخصاً این کار را انجام می دهم: ابتدا محتوا را ترسیم می کنم ، اهداف ، تمام اطلاعات مقدماتی را شرح می دهم و سپس بخش اصلی - تدوین الزامات را بر عهده می گیرم. چرا برعکس نه؟ نمی دونم برای من راحت تره اولاً، این بخش بسیار کوچک‌تری از زمان است (در مقایسه با الزامات)، و ثانیاً، در حالی که تمام اطلاعات مقدماتی را توصیف می‌کنید، به موضوع اصلی توجه می‌کنید. خب هر کی دوست داره با گذشت زمان، شما الگوی خود را از شرایط مرجع توسعه خواهید داد. برای شروع، من توصیه می کنم دقیقا همان چیزی را که در GOST توضیح داده شده است، به عنوان محتوا انتخاب کنید. برای محتوا عالی است! سپس هر بخش را می‌گیریم و شروع به توصیف می‌کنیم، بدون اینکه توصیه‌هایی را برای سه ویژگی زیر فراموش کنیم: قابل درک بودن، اختصاصی بودن و آزمایش‌پذیری. چرا اینقدر روی این موضوع اصرار دارم؟ بیشتر در این مورد در بخش بعدی. و اکنون من تمام تدبیر را پیشنهاد می کنم تا از آن نقاط TK که در GOST توصیه می شود عبور کنیم.

1. اطلاعات کلی؛
2. هدف و اهداف ایجاد (توسعه) سیستم؛
3. ویژگی های اشیاء اتوماسیون؛
4. سیستم مورد نیاز؛
5. ترکیب و محتوای کار در ایجاد سیستم؛
6. روش کنترل و پذیرش سیستم؛
7. الزامات ترکیب و محتوای کار برای آماده سازی شی اتوماسیون برای راه اندازی سیستم.
8. ملزومات مستندسازی؛
9. منابع توسعه

مجموعا 9 بخش که هر کدام به زیربخش ها نیز تقسیم می شوند. بیایید آنها را به ترتیب در نظر بگیریم. برای راحتی، من همه چیز را در قالب یک جدول برای هر مورد ارائه می کنم.

بخش 1. اطلاعات عمومی.

بخش 2. هدف و اهداف ایجاد (توسعه) سیستم.

به طور کلی توانایی شناسایی اهداف، تدوین آنها، ساخت درخت اهداف موضوعی کاملاً مجزا است. نکته اصلی را به خاطر بسپارید: اگر می دانید چگونه - بنویسید، اگر مطمئن نیستید - اصلا ننویسید. اگر هدف گذاری نکنید چه اتفاقی می افتد؟ شما طبق الزامات کار خواهید کرد، این اغلب تمرین می شود.

بخش 3. ویژگی های اشیاء اتوماسیون.

بخش 4 الزامات سیستم

GOST لیست چنین الزاماتی را رمزگشایی می کند:

• الزامات ساختار و عملکرد سیستم؛
• الزامات تعداد و صلاحیت پرسنل سیستم و نحوه کار آن؛
• شاخص های مقصد؛
• الزامات قابلیت اطمینان؛
• الزامات ایمنی؛
• الزامات ارگونومی و زیبایی فنی؛
• الزامات حمل و نقل برای تلفن همراه AS.
• الزامات برای بهره برداری، نگهداری، تعمیر و ذخیره سازی اجزای سیستم؛
• الزامات حفاظت از اطلاعات از دسترسی غیرمجاز؛
• الزامات ایمنی اطلاعات در صورت بروز حوادث؛
• الزامات حفاظت از تأثیرات خارجی؛
• الزامات برای خلوص حق ثبت اختراع؛
• الزامات استانداردسازی و یکسان سازی؛

اگرچه بخش اصلی قطعاً بخش با الزامات خاص (عملکردی) خواهد بود، اما این بخش نیز می تواند از اهمیت زیادی برخوردار باشد (و در بیشتر موارد همینطور است). آنچه ممکن است مهم و مفید باشد:

• شرایط صلاحیت. این امکان وجود دارد که سیستم در حال توسعه نیاز به آموزش مجدد متخصصان داشته باشد. اینها می توانند هم کاربران سیستم آینده باشند و هم متخصصان فناوری اطلاعات که برای پشتیبانی از آن مورد نیاز خواهند بود. توجه ناکافی به این موضوع اغلب به مشکلات تبدیل می شود. اگر صلاحیت کارکنان موجود به وضوح کافی نیست، بهتر است شرایط لازم برای سازماندهی آموزش، برنامه آموزشی، شرایط و غیره را تجویز کنید.
• الزامات حفاظت از اطلاعات در برابر دسترسی غیرمجاز.اینجا هیچ نظری وجود ندارد. این دقیقاً الزامات کنترل دسترسی به داده ها است. اگر چنین الزاماتی برنامه ریزی شده باشد، باید به طور جداگانه نوشته شوند، تا حد امکان با جزئیات بیشتر مطابق با قوانین مشابه الزامات عملکردی (قابلیت درک، ویژگی، آزمایش پذیری). بنابراین، این الزامات را می توان در بخش با الزامات عملکردی گنجاند.
• الزامات استانداردسازیاگر استانداردهای توسعه ای وجود داشته باشد که برای پروژه قابل اجرا باشد، می توان آنها را در الزامات گنجاند. به عنوان یک قاعده، چنین الزاماتی توسط خدمات فناوری اطلاعات مشتری آغاز می شود. به عنوان مثال ، شرکت 1C دارای الزامات طراحی کد برنامه ، طراحی رابط و غیره است.
• الزامات ساختار و عملکرد سیستم.در اینجا الزامات یکپارچه سازی سیستم ها با یکدیگر را می توان شرح داد، شرحی از معماری کلی ارائه می شود. اغلب، الزامات یکپارچه سازی به طور کلی در یک بخش جداگانه یا حتی یک شرایط مرجع جداگانه مشخص می شود، زیرا این الزامات می تواند بسیار پیچیده باشد.

همه الزامات دیگر اهمیت کمتری دارند و می توان آنها را کنار گذاشت. به نظر من آنها فقط مستندات را سنگین تر می کنند و کاربرد عملی کمی دارند. و توصیف الزامات ارگونومی در قالب الزامات عمومی بسیار دشوار است، بهتر است آنها را به موارد کاربردی منتقل کنید. به عنوان مثال، شرط "دریافت اطلاعات در مورد قیمت یک محصول تنها با فشار دادن یک دکمه" می تواند فرموله شود. به نظر من، این هنوز به الزامات عملکردی خاص نزدیکتر است، اگرچه به ارگونومی مربوط می شود. الزامات برای عملکردها (وظایف) انجام شده توسط سیستم در اینجا، نکته اصلی و کلیدی است که موفقیت را تعیین می کند. حتی اگر همه چیز به خوبی انجام شود، و این بخش در "3" باشد، نتیجه برای پروژه در بهترین حالت "3" خواهد بود، یا حتی پروژه شکست خواهد خورد. اینها مواردی هستند که در مقاله دوم که در ویرایش پنجم لیست پستی قرار خواهد گرفت، با جزئیات بیشتری به آنها خواهیم پرداخت. تا اینجاست که "قاعده سه ویژگی الزامات" که من در مورد آن صحبت کردم اعمال می شود. الزامات برای انواع امنیت

GOST انواع زیر را متمایز می کند:

• ریاضی
• اطلاعاتی
• وابسته به زبانشناسی
• نرم افزار
• فنی
• مترولوژیک
• سازمانی
• روشمند
• و دیگران…

در نگاه اول، ممکن است به نظر برسد که این الزامات مهم نیستند. این برای اکثر پروژه ها صادق است. اما نه همیشه. چه زمانی این الزامات را شرح دهیم:

• هیچ تصمیمی در مورد اینکه توسعه در کدام زبان (یا پلتفرم) انجام خواهد شد، گرفته نشده است.
• این سیستم تابع الزامات یک رابط چند زبانه است (به عنوان مثال، روسی / انگلیسی)
• برای عملکرد سیستم، باید یک واحد جداگانه ایجاد شود یا کارکنان جدید استخدام شوند.
• برای عملکرد سیستم، مشتری باید در روش های کاری تغییراتی داشته باشد و این تغییرات باید مشخص و برنامه ریزی شود.
• ادغام با هر تجهیزاتی فرض می شود و الزاماتی بر آن تحمیل می شود (به عنوان مثال، گواهینامه، سازگاری و غیره)
• موقعیت های دیگر ممکن است، همه اینها به اهداف خاص پروژه بستگی دارد.

بخش 5. ترکیب و محتوای کار در ایجاد سیستم

بخش 6. رویه کنترل و پذیرش سیستم

الزامات کلی برای پذیرش کار به تفکیک مراحل (فهرست شرکت ها و سازمان های شرکت کننده، مکان و زمان بندی)، روند موافقت و تایید مدارک پذیرش؛ اکیداً توصیه می کنم که مسئولیت روند واگذاری کار و بررسی سیستم را بر عهده بگیرید. این همان چیزی است که نیازمندی های قابل آزمایش است، اما حتی وجود الزامات قابل آزمایش نیز ممکن است در هنگام تحویل سیستم کافی نباشد، اگر رویه پذیرش و انتقال کار به طور واضح مشخص نشده باشد. به عنوان مثال، یک تله رایج: سیستم انجام شده است، کاملاً کاربردی است، اما مشتری، به دلایلی، آماده کار در آن نیست. این دلایل می تواند هرکدام باشد: یک بار، اهداف تغییر کرده اند، کسی ترک کرده و غیره. و می‌گوید: «از آنجایی که ما هنوز در سیستم جدید کار نمی‌کنیم، نمی‌توانیم مطمئن باشیم که کار می‌کند.» پس یاد بگیرید که مراحل کار را به درستی شناسایی کنید، راه هایی برای بررسی نتایج این مراحل. علاوه بر این، چنین روش هایی باید از همان ابتدا برای مشتری واضح باشد. اگر آنها در سطح شرایط مرجع ثابت هستند، در صورت لزوم می توانید همیشه با آنها تماس بگیرید و کار را با انتقال کامل کنید.

بخش 7. الزامات ترکیب و محتوای کار برای آماده سازی شی اتوماسیون برای راه اندازی سیستم

ممکن است قوانین دیگری برای وارد کردن اطلاعات اتخاذ شده توسط شرکت (یا برنامه ریزی شده) وجود داشته باشد. به عنوان مثال، قبلاً اطلاعات مربوط به قرارداد به صورت خط متنی به صورت دلخواه وارد می شد، اما اکنون شماره جداگانه، تاریخ به طور جداگانه و غیره لازم است. چنین شرایطی می تواند زیاد باشد. برخی از آنها را می توان با مقاومت کارکنان درک کرد، بنابراین بهتر است همه این موارد را در سطح الزامات ترتیب ورود داده ها ثبت کنید تغییراتی که باید در شی اتوماسیون ایجاد شود.

ایجاد شرایطی برای عملکرد شی اتوماسیون، که تحت آن انطباق سیستم ایجاد شده با الزامات مندرج در TOR تضمین می شود. هر گونه تغییری که ممکن است مورد نیاز باشد. به عنوان مثال، این شرکت یک شبکه محلی، یک ناوگان قدیمی از کامپیوترها که سیستم روی آنها کار نخواهد کرد، ندارد.

شاید برخی اطلاعات لازم روی کاغذ پردازش شده و اکنون باید وارد سیستم شود. اگر این کار انجام نشود، برخی از ماژول ها کار نمی کنند و غیره.

شاید چیزی ساده شده باشد، اما اکنون باید با جزئیات بیشتری مورد توجه قرار گیرد، بنابراین شخصی باید اطلاعات را طبق قوانین خاصی جمع آوری کند.

این لیست می تواند طولانی باشد، به مورد خاص پروژه خود نگاه کنید ایجاد بخش ها و خدمات لازم برای عملکرد سیستم.

مهلت‌ها و روش‌های آموزش کارکنان و کارکنان قبلاً در این مورد بحث کرده‌ایم. شاید این سیستم برای ساختار یا نوع جدیدی از فعالیت که قبلا وجود نداشته است، توسعه یافته است. اگر پرسنل مناسب و حتی آموزش دیده وجود نداشته باشد، سیستم کار نخواهد کرد، هر چقدر هم که شایسته ساخته نشده باشد.

بخش 8 مدارک مورد نیاز

نحوه ارائه راهنماهای کاربر را در نظر بگیرید.

شاید مشتری استانداردهای شرکتی را پذیرفته باشد، بنابراین باید با آنها تماس بگیرید.

نادیده گرفتن الزامات مستندات اغلب منجر به غیرمنتظره ترین عواقب در پروژه ها می شود. به عنوان مثال، همه چیز انجام می شود و همه چیز کار می کند. کاربران همچنین می دانند که چگونه کار کنند. ما اصلا در مورد مستندات به توافق نرسیدیم و صحبتی نکردیم. و ناگهان وقتی کار تحویل داده می شود، یکی از مدیران ارشد مشتری که حتی در پروژه شرکت نکرده است، اما در پذیرش کار مشارکت می کند، از شما می پرسد: "دفترچه راهنمای کاربر کجاست؟" و او شروع به متقاعد کردن شما می کند که لازم نیست در مورد در دسترس بودن کتابچه راهنمای کاربر توافق کنید ، ظاهراً این "به خودی خود" ضمنی است. و بس، او نمی خواهد کار شما را بگیرد. با هزینه چه کسی دستورالعمل ها را توسعه خواهید داد؟ بسیاری از تیم ها قبلاً به این قلاب افتاده اند.

بخش 9 منابع توسعه

بنابراین بهتر است صرفاً به گزارش نظرسنجی، الزامات افراد کلیدی مراجعه شود.

و بنابراین، ما تمام بخش هایی را که می تواند در شرایط مرجع گنجانده شود در نظر گرفته ایم. "می توان"، نه "باید" دقیقاً به این دلیل که هر سندی باید برای دستیابی به نتیجه تدوین شود. بنابراین، اگر برای شما واضح است که برخی از بخش های جداگانه شما را به نتیجه نزدیک نمی کند، پس نیازی به آن ندارید و نیازی به اتلاف وقت برای آن ندارید.

اما بدون نکته اصلی: الزامات عملکردی، هیچ یک از شرایط مرجع کامل نیست. من می خواهم توجه داشته باشم که در عمل با چنین شرایط مرجعی مواجه می شویم و چگونه! ارقامی وجود دارند که می توانند آب ها را در همه بخش ها رقیق کنند، الزامات کلی را به طور کلی توصیف کنند و سند بسیار سنگین است و کلمات هوشمندانه زیادی در آن وجود دارد و حتی ممکن است مشتری دوست داشته باشد. آن را (یعنی آن را تایید خواهد کرد). اما ممکن است نتوان روی آن کار کرد، یعنی. کاربرد عملی کمی برای آن وجود دارد. در بیشتر موارد، چنین اسنادی زمانی متولد می شوند که شما به طور خاص برای شرایط مرجع نیاز به دریافت پول زیادی دارید و باید آن را به سرعت و بدون غوطه ور شدن در جزئیات انجام دهید. و به خصوص اگر معلوم باشد که کارها جلوتر نخواهد رفت یا افراد کاملاً متفاوتی این کار را انجام خواهند داد. به طور کلی، فقط برای توسعه بودجه، به ویژه دولت.

در مقاله دوم، ما فقط در مورد بخش 4 "نیازهای سیستم" صحبت خواهیم کرد و به طور خاص، الزامات را به دلایل وضوح، ویژگی و آزمایش پذیری فرمول بندی خواهیم کرد.

چرا الزامات باید واضح، مشخص و قابل آزمایش باشد.

زیرا تمرین نشان می دهد: در ابتدا، بیشتر مشخصات فنی که توسط متخصصان تهیه می شود یا مورد تقاضا نیستند (با واقعیت مطابقت ندارد) یا برای کسی که باید آنها را اجرا کند مشکل ساز می شود. مشتری شروع به دستکاری شرایط و الزامات غیر خاص می کند. من چند نمونه از عباراتی را که با آن مواجه شدم، به چه چیزی منجر شد، ارائه خواهم کرد و سپس سعی خواهم کرد توصیه هایی در مورد چگونگی جلوگیری از چنین مشکلاتی ارائه دهم.

آیا این یک نیاز قابل آزمایش است؟ به نظر می رسد چیز ساده، اما اگر مشخصات خاصی وجود ندارد چگونه آن را بررسی کنیم؟

چگونه می توان آن را مجدداً فرمول کرد: "میزان هزینه های مندرج در سند باید به نسبت بهای تمام شده این کالاها به کلیه کالاهای مندرج در این سند تقسیم شود." واضح و مشخص بود. نحوه بررسی نیز دشوار نیست.

ارگونومی برنامه باید یک رابط کاربرپسند داشته باشد.راستش را بخواهید، من مجبور شدم خودم یک بار مشترک این عبارت باشم - پس از آن هیچ مشکلی برای شمارش وجود نداشت. البته چنین فرمولاسیونی نباید باشد. هیچ ویژگی خاصی وجود ندارد و توانایی تأیید این نیاز وجود ندارد. اگر چه، البته، قابل درک (ذهنی). در اینجا غیرممکن است که به هیچ وجه فرمول بندی مجدد انجام شود، لازم است هر عنصر "راحتی" را با جزئیات شرح دهیم، زیرا مشتری بر این امر اصرار دارد. مثلا:

• خطوط باید با کلیک بر روی دکمه "افزودن" و با فشار دادن کلیدهای "درج" و همچنین با وارد کردن بخشی از نام توسط کاربر به سند اضافه شود.
• هنگام مشاهده لیست کالاها، باید امکان جستجو بر اساس نام، بارکد و مقاله وجود داشته باشد.
• و غیره.

تمایز حقوق دسترسی دسترسی به داده‌های مربوط به سود باید فقط برای مدیر مالی در دسترس باشد. فهمیده‌اید؟ تقریبا. درسته سودش فرق میکنه باید توضیح بدی.به طور خاص؟ البته که نه. در اجرا چگونه به نظر می رسد؟ اگر ما در مورد سود ناخالص صحبت می کنیم، لازم است دسترسی به داده ها در مورد هزینه خرید محدود شود، زیرا. در غیر این صورت، محاسبه سود ناخالص آسان است، زیرا هزینه داده های فروش برای طیف گسترده ای از مردم شناخته شده است. وقتی صحبت از حقوق دسترسی به میان می آید، باید بسیار مراقب باشید. و اگر انگیزه مدیران فروش سود ناخالص باشد، این الزامات نیز با یکدیگر در تضاد هستند، زیرا. مدیران هرگز نمی توانند آن را تأیید کنند. اگر قبلاً چنین الزامی را گنجانده باشیم، لازم است گزارش‌ها و اشیاء سیستم خاصی را مشخص کنیم که در آن مشخص شود کدام بخشی از داده‌ها باید در دسترس دسته‌های خاصی از افراد باشد. و هر یک از این موارد را جداگانه در نظر بگیرید بهره وری گزارش فروش باید در 1 دقیقه تهیه شود بله متوجه هستم. و حتی یک محدودیت زمانی خاص وجود دارد: 1 دقیقه. اما معلوم نیست در این مورد چه نوع جزئیاتی در نظر گرفته شده است: برای هر محصول، گروه های محصول، مشتریان یا چیز دیگری؟ بیش از 1 دقیقه، مشروط بر اینکه تعداد موارد در انتخاب بیش از 5000 خط نباشد.

امیدوارم ایده روشن باشد. اگر سوال خاصی دارید بنویسید، من سعی می کنم کمک کنم.

به داخل شرایط مرجعجزئیات بیشتری وجود دارد، توصیه های زیادی وجود دارد. حتی فهرستی از کلماتی وجود دارد که برای استفاده در شرایط مرجع توصیه نمی شود. K. Vigers در کتاب خود با عنوان "توسعه نیازمندی های نرم افزار" در این مورد به طرز جالبی می نویسد. در اینجا جالب ترین و ساده ترین توصیه ها، به نظر من، وجود دارد:

• از کلماتی که مترادف زیادی دارند استفاده نکنید. در صورت لزوم، بهتر است در قسمت اصطلاحات و تعاریف شرایط مرجع، تعریف واضحی از این واژه ارائه شود.
• شما باید سعی کنید از جملات طولانی استفاده نکنید.
• اگر یک الزام برای شما خیلی کلی به نظر می رسد، باید به جزئیات کوچکتر، اما الزامات خاص ارائه شود.
• استفاده کنید طرح های بیشتر، نمودارها، جداول، نقاشی ها - بنابراین اطلاعات بسیار آسان تر درک می شود.
• از کلمات زیر باید اجتناب شود: «موثر»، «کافی»، «ساده»، «قابل درک»، «سریع»، «انعطاف پذیر»، «بهبود»، «بهینه»، «شفاف»، «پایدار»، «کافی» ، "دوستانه"، "آسان" و غیره. لیست را می توان ادامه داد، اما فکر می کنم ایده واضح است (سعی کنید خودتان آن را ادامه دهید).

تمام آنچه در بالا نوشته شده است اطلاعات مهم است، اما مهم ترین آنها نیست. همانطور که به یاد دارید، در ابتدای مقاله آن را اصطلاح "استتار" نامیدم، زیرا. مهمترین چیزی که حداقل 90 درصد از زمان و پیچیدگی کار بر روی یک سند را به خود اختصاص می دهد، شناسایی و تدوین الزامات است. و اطلاعات مربوط به الزامات باید همچنان قابل جمع‌آوری، ساختار و فرمول‌بندی باشد. این، به هر حال، مشترکات زیادی بین بررسی شرکت ها و توصیف بعدی فرآیندهای تجاری دارد. اما تفاوت های مهمی نیز وجود دارد. یکی از این تفاوت‌های کلیدی، وجود مرحله ساختن نمونه اولیه از سیستم آینده یا به‌عنوان «مدل‌های سیستم اطلاعات» نامیده می‌شود.

در مقاله بعدی فقط در مورد روش های شناسایی نیازمندی ها صحبت خواهیم کرد و همچنین آنچه را که بین کار جمع آوری نیازمندی های یک سیستم اطلاعاتی و جمع آوری اطلاعات برای توصیف فرآیندهای تجاری مشترک است بررسی خواهیم کرد.

انواع کار هنگام جمع آوری الزامات سیستم حسابداری و اطلاعات برای توصیف فرآیندهای تجاری. قسمت 2

در این بخش، ما در مورد نحوه سازماندهی مرحله کار در جمع آوری نیازمندی ها، از چه چیزی باید تشکیل شده باشد و از چه ابزارهایی می توان استفاده کرد صحبت خواهیم کرد. تکرار می کنم که این آثار از نظر مراحل بسیار شبیه به نظرسنجی سازمانی برای توصیف فرآیندهای تجاری هستند.

طبق معمول زندگی:

چرا چنین عملی وجود دارد که در بالا توضیح داده شد؟ اعتراف میکنم نمیدانم هیچ کس نمی پرسد، هیچ کس نمی داند. در عین حال، وضعیت خیلی سریع تغییر نمی کند، اگرچه این موضوع دائماً مورد بحث قرار می گیرد، تجربیات رد و بدل می شود، کتاب نوشته می شود ... به نظر من یکی از دلایل این است. کیفیت پایینآموزش مربوطه همچنین ممکن است تحت تأثیر این واقعیت باشد که بسیاری از متخصصان به طور کلی از مشاغل دیگر آمده اند و همه چیز را در عمل درک می کنند. تجربه آنها توسط محیطی که در آن قرار می گیرند شکل می گیرد. نگرش دانشگاه ها و عدم تمایل آنها به نزدیک شدن به واقعیت نیز یک واقعیت شناخته شده است، اما گاهی اوقات موقعیت آنها من را شگفت زده می کند. به عنوان مثال، من موردی داشتم که یک دانشجوی فارغ التحصیل، یک متخصص با استعداد، می خواست پایان نامه ای بر روی پلت فرم 1C بنویسد (یک توسعه صنعتی خوب)، اما در بخش به او گفته شد که صرف نظر از موضوع، غیرممکن است. روی نمره "عالی" حساب کنید، زیرا 1C یک سیستم جدی نیست. نکته در اینجا جدی بودن و عینی بودن چنین نظری نیست، بلکه این واقعیت است که یک کار ابتدایی در یک زبان برنامه نویسی کلاسیک بلافاصله شایسته رتبه "عالی" در نظر گرفته شد.

بیایید سعی کنیم روند فوق را بیشتر کنیم رویکرد سیستم ها. در آن صورت ممکن است او چگونه به نظر برسد؟

همانطور که می بینید، روند با یک سوال به پایان می رسد، زیرا در این مورد، کار به پایان نرسیده است، و پس از آن دشوارترین و عملی ترین شروع خواهد شد - دقیقاً چه چیزی کاربردی بودن نتیجه به دست آمده را تعیین می کند. زندگی واقعی. این دقیقاً همان چیزی است که سرنوشت کار قبلی را تعیین می کند: یا به گنجه می رود (در یک قفسه یا جای دیگری)، یا منبع اطلاعات ارزشمندی خواهد بود. و حتی بهتر است اگر الگویی برای پروژه های آینده شود.

من می خواهم به ویژه توجه داشته باشم که تا آخرین مرحله در نمودار (جایی که سوال است) اصل کلیجمع آوری اطلاعات در مورد فعالیت های شرکت به نظر یکسان است، صرف نظر از آنچه که در آینده برنامه ریزی شده است، فرآیندهای تجاری را توصیف کند یا یک سیستم خودکار را پیاده سازی کند. بله، توالی مراحل به خودی خود یکسان است، اما ابزار استفاده شده در برخی از آنها ممکن است متفاوت باشد. ما این لحظههنگام مطالعه روش ها و ابزار مراحل تکی حتماً در نظر بگیرید. ما این کار را با جزئیات در مقالات جداگانه انجام خواهیم داد، اما اکنون تنها مهمترین آنها را در نظر خواهیم گرفت. مراحل بعدی متفاوت خواهد بود و بر اساس آنچه از پروژه مورد نیاز است تعیین می شود: توصیف فرآیندهای تجاری یا پیاده سازی یک سیستم حسابداری.

بیایید ببینیم چگونه می توانید رویکرد جمع آوری اطلاعات در مورد فعالیت های شرکت را سازماندهی مجدد کنید.

بنابراین به این سوال رسیدیم که «بعدش چی؟». علاوه بر این، وظایف توصیف فرآیندهای تجاری و توسعه شرایط مرجع را به طور جداگانه در نظر خواهیم گرفت. تصادفی نیست که این وظایف را به موازات هم در نظر می گیرم. در واقع اشتراکات زیادی بین آنها وجود دارد که من می خواهم آنها را نشان دهم. ابتدا، توالی کار را در توصیف فرآیندهای تجاری در نظر بگیرید.

حال بیایید در نظر بگیریم که رویکرد مطالعه الزامات یک سیستم اطلاعاتی با بازتاب بیشتر آنها در شرایط مرجع چگونه خواهد بود.

بله، توسعه شرایط مرجع فرآیندی زمان‌بر و در نتیجه پرهزینه است. اما اگر به درستی انجام شود، مشتری را از انتظارات برآورده نشده نجات می دهد. پیمانکار باید آنچه را که مشتری می خواهد انجام دهد و همان کار را صد بار تکرار نکند. و به طور کلی به کل پروژه شفافیت می بخشد.