|
«Cahier des charges Good améliorera la productivité des programmeurs beaucoup mieux que tout autre outil de programmation ou de technique." - Loi de Bryce INTRODUCTION En termes de développement de systèmes, dans les années 1960 et au début des années 1970, vous étiez soit un Analyste de systèmes ou un programmeur. Période. À l'époque, il y avait beaucoup plus que les analystes programmeurs (au moins un ratio de 2:1). Ceci était dû en partie au fait que l'informatique était à peine rentré dans son propre dans le monde de l'entreprise et il y avait encore des gens autour de qui pourrait examiner les systèmes dans son intégralité. Cependant, il y avait un besoin criant pour les gens de programmer des ordinateurs et, comme tel, cela est devenu le boom des années de programmation. Si vous saviez COBOL, Fortran, ou PL / 1 vous pouvez à peu près normal de votre billet. Les salaires étaient bons, et on pouvait intimider votre employeur tout simplement par ce que vous saviez (vous avez dû commettre quelque chose comme assassiner se faire virer). L'accent mis sur la programmation est devenue si grande que les auteurs se précipita hors d'énormes livres d'augmenter la productivité des programmeurs, d'où la naissance du mouvement de programmation structuré à la fin de 1970, qui a été suivie peu après par le mouvement CASE (Computer Aided Software Engineering). Alors que la programmation est de plus en plus la stature, l'analyse des systèmes est en net déclin. Des groupes de commerce telles que l'Association pour Systems Management (EAM) ont vu diminuer leur appartenance à rien et ont été contraints de fermer leurs portes. Le dernier des vieux systèmes d'analystes à la retraite ou ont été mis à l'herbe par les sociétés dans les années 1980. Nouveaux titres d'emploi apparus, tels que Software Engineer et Analyste / Programmeur. Ce dernier titre est un peu plus d'une appellation fausse puisque l'accent était mis sur la programmation et non l'analyse systémique. Bien que la programmation a excellé, un vide notable a commencé à apparaître en termes de personnes qui pourraient voir les systèmes dans sa totalité. Rédaction d'un bon programme est une chose, obtenir de faire l'interface avec d'autres programmes pour former un ensemble du système est quelque chose d'entièrement différent. Au tournant du siècle, l'industrie a commencé à parler de choses telles que "l'Architecture d'Entreprise", "Business Processes", "Business Rules», «Business Analysis», etc En outre, de nouvelles conférences, groupes de commerce, et les titres d'emplois ont commencé à émerger. Aujourd'hui, les programmeurs sont considérés à la pelle et le stock d'un analyste vrai est à la hausse. Tout cela est révélateur de l'industrie de tenter de réinventer la théorie des systèmes. En réalité, il n'y a rien de nouveau ici en tant que systèmes d'analyse est l'analyse des systèmes. Mais en tant qu'entreprises en œuvre ces concepts et les titres d'emploi de plus, ils sont un peu l'incertitude quant à la place qu'ils occupent dans leur relation et à d'autres fonctions de la technologie de l'information. CARACTÉRISTIQUES Un analyste de systèmes a bien des noms de ces journées, par exemple, Business Analyst, Enterprise Architect, Systems Engineer (ma préférence personnelle), etc Néanmoins, nous parlons d'une personne dont la mission est d'étudier les besoins d'information d'une entreprise et la conception d'un solution de système total pour les satisfaire. En outre, l'analyste est chargée de préciser les besoins en logiciels et en tant que telle, est considéré comme l'intermédiaire avec l'équipe de programmation. Les caractéristiques personnelles de l'analyste est considérablement différente de celle du programmeur. Considérant que le programmeur a tendance à être plus introverti et axée sur la technologie, l'analyste tend à être plus orientée business et extravertie. Les analystes possèdent de bonnes compétences en communication (orale et écrite) pour travailler efficacement avec les utilisateurs finals et l'équipe de programmation. Ils savent comment mener une interview et faire une présentation (art de la vente). En outre, ils ont tendance à regarder le tableau d'ensemble plutôt que seulement une partie d'elle et de posséder un esprit d'entreprise. L'analyste comprend les problèmes des entreprises de l'utilisateur final et qui est lié avec le fonctionnement du ministère de l'utilisateur. En d'autres termes, l'analyste peut marcher confortablement dans la peau de l'utilisateur final. S'ils font bien leur travail, les analystes font d'excellents candidats à assumer des responsabilités dans la hiérarchie de gestion. Mais parce que les analystes étaient en baisse depuis tant d'années, cela ne s'est pas produit depuis un certain temps. La dernière fois que j'ai entendu parler d'un analyste fonctionnel de passer à un poste de gestion important a été Dan Boone qui a été nommé président et COO de Armco Steel à la fin des années 1970. Si les systèmes d'analyse est effectué correctement, la productivité du programmeur devrait s'améliorer à mesure que les analystes devraient fournir de bonnes caractéristiques pour des missions d'application. En l'absence d'analystes de systèmes, un temps considérable est perdu par le programmeur qui a de deviner ce que l'utilisateur final veut. Inévitablement, cela conduit à la réécriture du logiciel, encore et encore. De bonnes données et spécifications de traitement, tel que prévu par l'analyste de systèmes, permettra d'améliorer la productivité des programmeurs beaucoup mieux que tout autre outil de programmation ou de technique. Cela signifie que les programmeurs sont les bénéficiaires de l'analyse des systèmes bien. Cela soulève un point intéressant, ce que devrait être le rapport des analystes de systèmes pour les programmeurs dans un organisme de développement? Franchement, je crois qu'il devrait y être deux fois plus nombreux analystes que les programmeurs. En se concentrant sur les travaux initiaux, la programmation est simplifiée. Permettez-moi d'illustrer ce point en utilisant les triangles suivants, représentant le montant total de l'effort dans un projet (en passant, j'ai fait monter cette hausse par rapport à mes clients au Japon, qui partagent mon avis), voir: http://www.phmainstreet.com/mba/blog/ss060724.jpg Le triangle de gauche représente l'approche traditionnelle, selon laquelle il ya deux fois le nombre de programmeurs analystes de systèmes. Selon cette approche, beaucoup plus de temps est consacré à la production de logiciels pour satisfaire aux exigences mal définies. Le point de japonais sur le bas du triangle est effectivement sans fond, car cela signifie plus de temps est nécessaire pour achever un projet. Comparez-le à le triangle sur la droite où il ya deux fois plus nombreux analystes programmeurs. Selon ce scénario, plus de temps est consacré à l'analyse du problème, la conception du système, et de produire de meilleures spécifications de programmation. En conséquence, les programmeurs n'ont pas de deviner ce qui doit être effectuée et peut aller sur leur travail plus productive. Le problème avec le diagramme sur la droite tient de ce que l'analyse des systèmes est considéré être un peu un concept nébuleux de la gestion. La programmation, en revanche, est plus concrète et plus facile pour les gens à saisir, soit vous écrivez du code et de produire un programme ou vous n'êtes pas. Par conséquent, la mentalité dans la gestion, c'est que vous ne sont pas productifs à moins que vous codez, d'où l'inclination à l'analyse de raccourcis systèmes. C'est une des raisons principales pour lesquelles l'analyse des systèmes s'est effondré dans les années 1980. Et c'est pourquoi il est nécessaire d'offrir une formation de gestion comprend la nécessité pour l'analyse des systèmes. Franchement, j'ai trouvé la direction peut être très favorable si elle leur est présentée correctement. CONCLUSION Si vous les appelez des analystes de systèmes, analystes d'affaires, ingénieurs système, ou Enterprise Architects, il est très encourageant de voir cette fonction vitale d'être réintroduite pour les entreprises. En ce qui me concerne, il était inévitable. Je suppose que les entreprises finalement compris vous ne pouvez pas répondre à vos problèmes du système simplement en utilisant de meilleurs outils de programmation et des techniques. Nous commençons aussi à voir la résurgence de groupes liés au commerce pour remplacer les groupes comme l'Association pour Systems Management (ASM), par exemple: L'Institut international d'analyse des activités commerciales L'ERAI semble se reprendre là où ASM quitté, y compris la certification. Considérant que l'ASM élaboré et offert le titre de Certified Professional Systems (DSP), il ya des années de certification, ERAI veut créer quelque chose de similaire. Tout cela est révélateur de la façon dont l'industrie tente de réinventer la théorie des systèmes. Considérant que ces systèmes de travail était bien connu jusqu'à la 1980, il a été oubliée au cours des vingt dernières années en raison de l'accent mis sur la programmation. Heureusement, les entreprises ont enfin compris l'importance des systèmes de travail et tentent d'obtenir leur maison en ordre. I guess what goes around, comes around. |