Kérdés:
Mi a professzionális módszer a tervezési előzmények nyomon követésére az üzemmérnöki munkában?
mart
2015-03-27 11:25:39 UTC
view on stackexchange narkive permalink

Ha megnézi projektjeink tervdokumentációját (biogáz és hulladék-energia erőművek), megtudja, mit tervezünk építeni, de nem azt, hogy milyen egyéb lehetőségeket vettünk figyelembe, és miért vetették el azokat. Ez az információ csak a mérnöki fejben nyugszik. Előfordul, hogy egy üzem évekig fogalmi szakaszban lesz, néha vált a mérnökök között. Szóval azon kapom magam, hogy újból megvizsgálok egy lehetőséget, amelyet egy munkatársa fontolóra vett és az ultimataly tavaly elvetett.

Hogyan lehet nyomon követni a tervezési döntéseket, a miérteket és miért nem? Nagyon szeretném, ha az iparban máshol kipróbált, kipróbált és alkalmazott megközelítés lenne.

További információk: Vállalkozásom ISO 9001 tanúsítást fog megszerezni, előnyben részesítenék ezt a minőségbiztosítási rendszert.

Négy válaszokat:
Trevor Archibald
2015-03-27 22:01:23 UTC
view on stackexchange narkive permalink

Úgy gondolom, hogy ez attól függ, hogy mennyi információt szeretne, és formálisan hogyan szeretné nyomon követni. Úgy hangzik, hogy jelenleg ezeket az információkat nem írják le sehova, ami nyilvánvalóan az első probléma. De az információk elhelyezése egy olyan megoldáshoz, amelyet nem szándékozik követni, az legjobb esetben az optimálisnál kevesebb időfelhasználás. Meg kell határoznia, hogy mely ötletek vannak eléggé konkretizálva a rögzítéshez. Ha megbeszélést tart és tucatnyi ötlet kerül az asztalra, de a felét szinte azonnal elvetik, fel szeretné jegyezni, hogy mik voltak ezek az ötletek, és miért vetették el őket? Ez nagy erőfeszítés a valószínűleg nagyon alacsony szintű elemzésért, de ezek mégis tervezési döntések.

Intuitívabbnak tűnik számomra, ha ezt csak olyan ötleteknél csinálom, amelyek elérik azt a stádiumot, hogy van néhány. a velük kapcsolatos tényleges munka. Így már van valami kézzelfogható dolga, és ezt csak be kell iktatni egy projektfájlba, ami remélem, hogy már van valami. Mivel ez a rendszer valóban csak referencia anyagokat fog létrehozni a jövőbeni projektekhez, nem hiszem, hogy jó ötlet lenne egy teljesen új rendszert létrehozni ezen anyagok archiválására vagy egy meglévő rendszer átalakítására. Találja meg a módját a jelenlegi tervkezelő rendszerbe történő integrálásához.

Az egyetlen kulcs, amellyel megbizonyosodhatnék arról, hogy osztályozhatja a különböző terveket a legfontosabb paramétereik szerint. Nem sokat tudok a területéről, de feltételezem, hogy vannak bizonyos tervezési paraméterek, amelyeknek minden projektnek meg kell felelnie (fizikai méret, kapacitás, üzem típusa stb.). Győződjön meg arról, hogy ezek valahol jól láthatók, hogy új projekt indításakor azonosíthassa azokat a régi projekteket, amelyek különböző szempontból hasonlóak. Ha ezeket az eldobott ötleteket tárolja ezekben a mappákban, elemezheti azok hasznosságát az aktuális projekthez.

Szeretnék azonban általában figyelmeztetni arra is, hogy túl mélyen elmélyülök ebben. Ismét egy másik iparágban dolgozom, ahol a projektek sokkal rövidebbek, és mint ilyenek, sokkal több van belőlük, de néhány termék évtizedek óta létezik valamilyen formában, és ezek 15-20 változata van. Nagyon fontos fenntartani a tényleges tervmódosítások felülvizsgálati előzményeit. Annak ismerete, hogy az ügyfél mit kapott a múltban, mikor változtattak, és miért hajtották végre őket, kulcsfontosságú annak érdekében, hogy ne ismételje meg a korábbi hibákat és ne szervizelje helyesen a régi terveket. De amikor olyan terveket katalogizál, amelyek soha nem valósultak meg teljesen, akkor a nélkülözhetetlen adatok mellé nem lényeges adatokat is hozzáad, és csak annyit lehet rendezni, mielőtt a dolgok elvesznek. Úgy hangzik, mintha a szilárd kommunikáció és a jó tapasztalat helyettese lenne. Amikor ezek a projektek gazdát cserélnek, az érintett mérnököknek át kell adniuk az összes lényeges információt. Megértem, hogy meg akarok győződni arról, hogy tudják, mi került figyelembe vételre, de azt tanácsolom, hogy mérsékelje ezt a vágyat, hogy ne öntse el a feljegyzéseit felesleges adatokkal.

Nagyon tetszik ez a válasz és figyelmeztetés az utolsó bekezdésben és a második bekezdésben. Meglátom, mit javasolnak mások.
hazzey
2015-03-28 02:29:30 UTC
view on stackexchange narkive permalink

Ez a Trevor válasza nagyon jó minden filozófiához, de szeretnék többet megtudni a részletekről.

Először , derítse ki, miért nem vezetik az alternatív nyilvántartásokat. Ez valószínűleg előrelátásként vagy tárolási (papír vagy számítógép) problémaként kezdődött.

A múltban egy időben valaki úgy gondolta, hogy a póttagok nem lesznek hasznosak, ezért kidobták vagy törölték őket. Ez valószínűleg vállalati kultúrával kapcsolatos probléma. Most, hogy ezt problémaként azonosították, vállalati szinten fel lehet vetni. A már létrehozott nyilvántartások vezetése egyszerű.

Még akkor is, ha az eredeti mérnökök úgy gondolták, hogy az alternatívák hasznosak lehetnek, előfordulhat, hogy a tárolás költségei (fizikai vagy számítógépes) miatt nem tartották meg a dokumentumokat. Ha ez még mindig így van, akkor ezt a problémát most meg kell oldani. Ha ez már nem így van, el kell terjeszteni a cég egész területén azt a szót, hogy a nyilvántartás vezetése nem költséges ajánlat.

Másodszor, nézze meg az alternatív összehasonlítási módszert. Ott az alternatív megfontolás két kategóriája: gondolkodás és számítás.

A gondolat-összehasonlítások olyan ötletek, amelyeket elég gyorsan elvetettek, hogy soha ne jussanak papírra, csak a koncepció formájában. Ha ezeket az ötleteket első alkalommal elvetették ilyen gyorsan, akkor valószínűleg nem kell rögzíteni őket. A hitelminősítésükre irányuló törekvés annyira csekély, hogy csak ismét hiteltelenné válnak.

Valamilyen formában meg kell őrizni azokat az alternatívákat, amelyek valóban a számítási szakaszba jutottak. Ha a számításokat vagy a terveket először hajtották végre, akkor már van mit spórolni. Még akkor is, ha az ötlet zsákutcának bizonyul, a munka már megtörtént, ezért tegye be az aktába! Amíg dátummal rendelkezik, hivatkozni lehet rá.

Írjon emlékeztetőt (a fájlba, ha nem valakinek), amikor döntést hoz. Ez időt takarít meg a jövőben, de egy lépést ad a folyamathoz. Ezen a területen dolgozni kell a továbbfejlesztett dokumentálás mellett.

Utolsó, dátumozzon mindent! Próbáljon meg együtt dolgozni a már meglévő rendszerekkel a végső nyilvántartás vezetése érdekében, csak adj hozzá dátumot mindenhez. Még akkor is, ha más szervezési módszerek kudarcot vallanak, az alternatívák sorrendje újjáépíthető a tételek dátumainak felhasználásával.

Mahendra Gunawardena
2015-03-29 19:36:46 UTC
view on stackexchange narkive permalink

A következőkben három általános módszert társítottam a fehéráru, a fogyasztási cikkek és az OEM gyártására a dokumentumötletekhez.

Front End (Conceptualization) ötletdokumentáció
Hozzon létre projektszámokat olyan ötletekhez, amelyeket nagynak, teljes hatásúnak és úttörőnek tekintenek, de jelenleg nem vesznek figyelembe a megvalósításban. Dokumentálja ezeket az ötleteket a legtöbb esetben egy vagy kétoldalas dokumentumban, és a projekt polcainak elkészítése előtt. A keresőmotorok és szoftverek növekedésével ezek az ötletek kereshető adatbázisban tárolhatók. A jelenlegi munkaerő átmeneti jellegével ezt az ötletet jól dokumentáltam. A technológia és a megvalósítási módszer növekedésével a technológia részletes dokumentációja kevésbé releváns, mivel $ t + 1 $ dollárban nagy a valószínűsége annak, hogy jobb és továbbfejlesztett technológia áll majd rendelkezésre.

Tervezési áttekintések ( NPD - Új termékfejlesztés)
A Design áttekint egy másik jó folyamatot, amely elősegítheti a mérnöki tervezési döntések dokumentálását. Ez inkább technikai dokumentáció, az elutasított ötletek általában nincsenek jól dokumentálva. A legtöbb szervezetben a tervellenőrzések a fáziskapu modell része.

Háttér (gyártás közben vagy bezáráskor) ötletdokumentáció
Olyan szervezeteket találtam, amelyek egy meglévő változáskezelő rendszert használnak az új ötletek dokumentálásához. Ebben a rendszerben a mérnök egy egyszerű vagy egy oldalas dokumentumban javasolja az ötletet. Az ötletet felülvizsgálták és elfogadták, vagy elraktározták a jövőre nézve. Ez a bizonyos szervezet az SAP-ot használta a változáskezeléshez, ezáltal a rendszer kevésbé alkalmas a technológiai bázis keresésére, de jól megszakította őket.

Összefoglalva, a legtöbb ötlet a következő okból áll polcra

  • Pénzügyi források hiánya az ötlet / javaslat megvalósításához
  • Emberi erőforrások hiánya az ötlet / javaslat megvalósításához
  • Nem illik bele a jelenlegi projekttervbe
  • A piac még nem áll készen az új technológiák átvételére

Ezért jó a pályaötletek, mert amikor a fenti korlátok feloldódnak, az ötletek reális megoldásokká válnak.

Hivatkozások:

Ben Trettel
2015-03-31 00:00:31 UTC
view on stackexchange narkive permalink

Mások sok jó megjegyzést tettek általában a dokumentációval kapcsolatban, de szeretnék javasolni egy speciális szoftvert, amely óriási segítséget nyújt.

Találok verziókezelő szoftvert hogy kiváló legyen az ilyen jellegű kérdésekben. Sajnos a szoftverfejlesztésen kívül nem túl gyakori, de csak idő kérdése, hogy más területeken felzárkózzon.

Íme egy példa: A kutatócsoportom Subversion a legtöbb ember által használt adattár (Népszerű alternatív szoftver a git). A verzióvezérlés használata segít biztosítani a kutatási projektek folyamatosságát, miután valaki távozik, mert a projekt szempontjából releváns fájlok többsége ott van, valamint részletes napló arról, hogy milyen munkát milyen időpontban végeztek, és (ha jól csinálják), indoklás. Részletesen kifejtem.

Tegyük fel, hogy van egy mappája a számítógépén, amely tartalmazza az összes fájlt.

Mindent automatikusan dátumozunk, amikor elkötelezzük magunkat (a verziókezelő kifejezés, amit mások hívás "feltöltés"). Az elkötelezett üzenet rövid emlékeztetőként működik (ahogy Mahendra Gunawardena javasolta, érdemes lehet hosszabb és hivatalos feljegyzéseket kérni a nagyobb döntésekhez). Leírja a projektfájlok változását, mondván: "Úgy döntöttünk, hogy az X megközelítés nem kivitelezhető. Helyette Y-t próbálunk ki. Töröltük az X megközelítéshez társított fájlokat, és létrehoztunk egy új CAD modellt az Y megközelítéshez."

Ezután később, ha úgy dönt, hogy az X megközelítés valójában a helyes, és ki akarja ásni a törölt fájlokat, akkor nem nehéz. Bármelyik részt könnyedén visszaválthatja a régebbi verzióra, és onnan folytathatja.

Néhány további előnye van ennek a megközelítésnek. Először is, ez megkönnyíti a fájlok megosztását másokkal. Csak megnézik az adattárat (egy verziókezelő kifejezés, amely akár az aktuális verziót, akár az összes verziót jelentheti), majd rendszeresen frissíti (erre vannak parancsok). Alapvetően mindenki szinkronban van. Másodszor, alapvetően ingyen kaphat biztonsági másolatot (régebbi verziók). Ennek ellenére ez nem jelenti azt, hogy nem kell normál biztonsági másolatot készítenie, csupán azt, hogy van egy másik lehetősége a véletlenül elveszett fájlok helyreállítására. Nagyon ajánlom a teljes adattár biztonsági mentését is.

Azt hittem, hogy a VCS-k nem kezelik jól a bináris foltokat. Lehet, hogy kezelik a fájlokat, de elveszítik azt a lehetőséget, hogy * pontosan * lássák, mi változott, vagyis a szöveg "diffs".
Ezt bizonyos mértékig elkerülheti, ha pontosan megírja, mi változott az elkötelezettség üzenetben. Ezen túlmenően további szoftverre van szüksége, hogy kiemelje a változásokat, nem csak a megtekintésen. Láttam már módot a képek elterjesztésére, és láttam olyan CFD megjelenítő szoftvert, amely lehetővé teszi, hogy lássa, mi különbözik két különböző adatfájl között. Homályosan emlékszem, hogy néhány CAD szoftver is rendelkezik ezzel a képességgel. Ez nem olyan egyszerű, mint egy szöveges fájl diffundálása, de elvileg nem lehetetlen. Azt is szeretném kiemelni, hogy ez önmagában nem egy verziókezelési probléma, inkább a különbségek megtekintésének képességével kapcsolatos probléma.
A tárolási hatékonyság szempontjából egyértelműen csak az eltérések elhelyezése az adatbázisban egyértelműen jobb. Azt hiszem, néhány verzióvezérlő rendszer ezt megteszi a bináris fájlok esetében, bár alaposabban meg kellene vizsgálnom.


Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...