نکته : تمامی این نوشته ها حاصل تجربه ها و برداشت های شخصی است. ممکن است مثل همیشه پر از ایراد و اشکال باشد و در آینده این حق را نیز دارم که این نوشته ها را به طور تمام و کمال رد کنم.
یک سوال همیشه پیش می آید اینست که چرا اکثر نرم افزارها شکست می خورند و تعداد نرم افزارهایی که از ابتدا بدون شکست به بقای خود ادامه می دهند، بسیار کم است ؟
به نظر من پاسخ اینست کمتر به نرم افزار به عنوان یک سیستم پیچیده دینامیکی نگاه می شود.
اکثر افرادی که در شرکت های نرم افزاری کار می کنند، قبلا فریلنسری را تجربه کرده اند و کمتر پیش آمده که در محیطی باشند که یک سیستم آن را می چرخاند و قواعد و مقررات و نظم خاص خود را داراست.
بیشتر این افرادی که در شرکت های نرم افزاری کار می کنند ، اکثراً از سواد کُد نویسی خوبی برخوردارند. اما از سیستم درک کمی دارند یا اصلا درکی ندارند.
منظورم از درک کم هم اینست که فقط تعداد ورودی ها را در نظر میگیرند و به سیستم از منظر خطی یا Liny Perspective نگاه می کنند.
این در صورتی است که نرم افزار یک سیستم دینامیکی پیچیده است که نه تنها با محتوا(Content) سر و کار دارد ، بلکه با بستر (Context) ارتباطی ریشه ای دارد.
یعنی اگر شما محتوای مناسب که همان نرم افزاری است که باید تولید شود ، را طراحی کنید و در سطح محتوا (نرم افزار ) عالی باشد و ارتباطی با context نداشته باشد، سیستم نیست بلکه یک UI است که فقط ظاهر زیبایی دارد.
مشکل اصلی در طراحی و ساخت نرم افزارهایی که با شکست مواجه می شوند، اینست که هیچ وقت در ابتدا به بررسی بستر یا همان سیستم موجود نمی پردازند. بلکه فقط کارهایی را که باید انجام بگیرد ، در نظر میگیرند و آن را به دلخواه خودشان کُد می زنند.
( داخل پرانتز از واژه کُد زدن به شدت بیزار هستم. دقیقا مثل اینست که ما مکانیکی بلد نیستم و دست به آچار میشویم و می خواهیم ماشین را نقاشی و رنگ آمیزی کنیم)
در مورد اسلاید بالا که مربوط به درس مهندسی سیستم هاست ، نگاهی بیاندازید متوجه خواهید شد که نه تنها content با context ارتباط دارد، بلکه باید خودش را با context وفق دهد تا بتوان یک سیستم خوب را طراحی کرد و ساخت.
تمامی مراحل طراحی نرم افزار به غیر از UI در بعضی مواقع،در درون SE Lifecycle قرار می گیرد.
حال این SE Lifecycle در درون خودش به یک LifeCycle دیگری تبدیل می شود که مختص به مراحل طراحی و ساخت و تولید نرم افزار است و آن را SDLC می نامند.
در تمامی مراحل دیدی حلقه ای یا چرخشی وجود دارد. یعنی در مرحله Disposal اگر مجبور شویم بعد از طی کلیه مراحل یک Feature را حذف کنیم ، باید تاثیر آن را حتی بر روی مراحل تحلیل و Planning در نظر بگیریم.
یعنی به زبان ساده می توان عکس زیر را بکار برد.
یعنی همیشه یک مرحله کنترل وجود دارد. کنترلی که باعث می شود این حذف یا اضافه کردن را با سیستم یا همان Context ، وفق دهیم و آن را بسنجیم.
اگر اینکار ها را در همان ابتدا انجام ندهیم ، با یک شکست گرانی مواجه خواهیم شد که نمی توان نتایج آن را از منظر مالی و صرف انرژی و تحلیل و طراحی و ساخت و ... پیش بینی کرد.
حال چرا باید این کنترل ها را انجام داد ؟
آیا اینقدر می صرفه که همه اینکارها رو انجام بدم ؟
آیا باید همه این مراحل رو تک تک انجام بدهم؟
جواب این دسته سوالات همگی بستگی به نوع سیستم و هزینه ای که برای نرم افزار می کنید ، بستگی دارد.
اگر شرکتی که حاضر نیست برای 5 سال آینده خود از نرم افزار استفاده نکند، این کارها لازم نیست.
اما اگر قرار است شرکت یا سازمانی یا کسب و کاری با این نرم افزار سالیان سال کار کند و نیازهای خود را در آینده از این طریق تامین کند، لازم است که به همه مراحل نگاهی گذرا داشته باشیم و با یک استراتژی مناسب و در نظر گرفتن نیازمندی ها ، انتخاب کنیم که به کدامین مراحل نیازی ضروری و اساسی داریم و به کدامین مراحل ، باید در طول چرخه حیات سیستم ، توجه کمتری داشته باشیم.
این مطلب را به عنوان مقدمه ای بر این موضوع در نظر بگیرید. چون من خودم چرخه نرم افزار را فقط برای حیات آن در نظر نمی گیرم.
چرخه حیاتی که من برای نرم افزار در نظر گرفته ام ، با استقرار سیستم پایان نمی یابد. بلکه در این مرحله تازه متولد می شود و چرخه حیات شامل مراحل زیست نرم افزار ، رشد نرم افزار ، حیات نرم افزار ، مرگ نرم افزار و پسا مرگ نرم افزار می باشد.
چون باید بعد از مرگ نرم افزار ، از آن درس گرفت و این درس گرفتن ها منوط به این است که از همان زمانی که نرم افزار متولد می شود، یعنی نوزادی تا زمانی که به پیری و مرگ می رسد ، توجهی اساسی داشت و حتی بعد از مرگ آن ، باید متوجه اشتباهات خود در طول حیات و تربیت و توسعه آن شویم.
ادامه دارد ...
