Now Reading
Por que Engenharia de Software não é como outras disciplinas de engenharia e como ela muda o Jogo
0

Por que Engenharia de Software não é como outras disciplinas de engenharia e como ela muda o Jogo

by adminjulho 14, 2015

Estima-se que existem mais de 11 milhões de desenvolvedores de software profissionais a nível mundial a partir de 2014. Quando eu comecei como programador em 1973 um dos Greybeards na primeira empresa que eu trabalhava me deu alguns conselhos. Ele disse: “Saiba as coisas que nunca mudam.”

Quando eu comecei a faculdade, seis anos antes, em 1967, a escola onde estudei não teve um grande chamado Ciência da Computação e então eu fiz o meu trabalho de graduação e pós-graduação em Matemática, tendo alguns cursos de programação de computadores ao longo do caminho. Esta foi a forma como muitos de nós começou como desenvolvedores de software para trás na década de 70.

O termo Engenharia de Software era novo na época, sendo cunhado na Conferência de Engenharia de Software da NATO 1968. O pensamento na época era que precisávamos para aplicar métodos de engenharia existente para o desenvolvimento de software para resolver problemas de orçamento comum, cronograma e qualidade que estavam sendo referidos na época como a “crise de software.” Como resultado, o que a maioria das pessoas têm vindo a pensar em como Engenharia de Software envolve atividades que lembram muito outras disciplinas de engenharia, incluindo engenharia civil, mecânica e elétrica.

Na superfície esta idéia parece fazer sentido. Quando você construir algo usando as outras disciplinas de engenharia (por exemplo, uma ponte, um edifício, uma peça de hardware especializado, uma placa de circuito elétrico) que você precisa para descobrir os requisitos, projetar uma solução, implementá-la e testá-lo. Todas essas etapas fazem sentido para software também. Então, certamente se poderia argumentar a partir dessa perspectiva que a engenharia de software deve se parecer com essas outras disciplinas de engenharia. No entanto, quando você olhar mais de perto o que aprendemos sobre desenvolvimento de software ao longo dos últimos 40 anos, bem como a forma como ensiná-la aos desenvolvedores de software de hoje, esta analogia entra em colapso.

Até o momento a década de 1990 chegou, porque a programação de computadores tornou-se uma parte tão grande do que foi chamado Ciência da Computação, muitas universidades tinha acrescentado um curso com um título de “Engenharia de Software” para seu currículo Ciência da Computação. Livros populares que foram usados ​​na época para ensinar esses cursos incluídos livro de Ian Sommerville intitulada: “Engenharia de Software”. De 1992 a 1994 eu usei a quarta edição do presente livro para ensinar Engenharia de Software da Universidade de Binghamton. Hoje, livro de Ian Sommerville ainda está em uso em muitas universidades ao redor do mundo, agora em sua nona edição. Isso leva a uma pergunta:?

Por que precisamos de rever um livro aproximadamente a cada 3-4 anos, que supostamente está ensinando nossos alunos os fundamentos da Engenharia de Software

Se você olhar para livros usados ​​em Engenharia Civil, Engenharia Mecânica e Engenharia Elétrica a grande maioria destes livros não requerem revisões quase tantas vezes. Para entender por que este é o caso, precisamos olhar mais de perto o que está sendo ensinado na maioria das universidades em todo o mundo sob o nome de “Engenharia de Software”.

Quando você olhar mais de perto você vai achar que nós estão ensinando nossa próxima geração de profissionais de software o que quer que é popular atualmente em termos de práticas de software e métodos. Práticas de software mais populares e métodos de hoje são conhecidos por chavões como Agile, Casos de Uso, User Stories, RUP, XP, Scrum Lean, PSP, TSP ea lista vai em e em …

O problema com esta abordagem à Engenharia de Software ensino é que as práticas de software e métodos freqüentemente vêm e vão e vão continuar a ir e vir é por isso que Sommerville deve atualizar continuamente seu livro. Isto leva a outra pergunta:

E aquele greybeard na primeira empresa que eu trabalhava, em 1973, que me disse para aprender as coisas que nunca mudam? Será que ele me dar maus conselhos? Se não, o que estamos ensinando a nossa próxima geração de profissionais de software com relação às coisas que nunca mudam sobre Engenharia de Software

Antes de responder a essas perguntas, vamos primeiro passo para trás e fazer algumas perguntas diferentes?:

Será que um conjunto de coisas que nunca mudam em Engenharia de Software realmente existem?

Se eles existem, não sabemos o que são?

Se nós sabemos o que são, estamos ensinando-lhes de uma forma consistente para a nossa próxima geração de profissionais de software por isso, quando eles saem da universidade eles estão preparados para conduzir-se como profissionais de software?

Tal conjunto de fundamentos de engenharia de software que de fato existe. Essa crença motivou um grupo internacional de voluntários para assumir a tarefa de codificar esses fundamentos. A intenção é que estes fundamentos que ser ensinados a nossa próxima geração de desenvolvedores de software, ajudando a prepará-los como verdadeiros profissionais de software

Os voluntários envolvidos nesta iniciativa. (Conhecido como SEMAT – Software Método Engenharia e Teoria) ter sido trabalhando nesta tarefa desde 2010. Este ano SEMAT passado alcançou um marco importante com o anúncio feito pelo Object Management Group, um consórcio internacional de normalização, que eles adotaram “Essence” como um padrão OMG oficial.

Portanto, esta leva a mais algumas perguntas:

Quão diferente é o padrão Essência do que está sendo ensinado aos nossos desenvolvedores de software hoje em dia, e foi ensinado durante os últimos 40 anos sob o nome de engenharia de software?

E:

Será que as diferenças realmente ajudar com os problemas que muitos ainda acreditam flagelar a indústria de software em relação ao orçamento comum e programação over-runs e software pobres qualidade?

De uma perspectiva que capta Essência não é nova. O padrão Essence inclui palavras comuns, tais como, as partes interessadas, Oportunidade, Requisitos, Sistema de Software, equipe, trabalho, e forma de trabalhar. Mas a partir de uma outra perspectiva que capta Essence é dramaticamente novo. Na verdade, alguns estão chamando de uma “mudança de paradigma” que muitos da “velha guarda” terá grande dificuldade até mesmo compreender.

Para se ter uma idéia das mudanças envolvidas ao usar Essence eu novamente acho que volta para meus primeiros dias como um programador no final dos anos 1970. Naqueles dias, eu trabalhava nos sistemas de software de desenvolvimento de domínio de simulação de voo para treinar pilotos para voar aeronaves de alto desempenho. Uma das minhas áreas de especialização estava escrevendo software para fornecer recursos de gravação / reprodução para ajudar instrutores treinar jovens pilotos de aeronaves em habilidades de vôo.

Lembro-me de um projeto específico em que trabalhei e um instrutor piloto cliente que eu trabalhei com. Depois de explicar a ele como ele poderia usar o meu software de gravação / reprodução para ajudá-lo a demonstrar aos seus alunos pilotos onde tinham cometido erros, ele animadamente escreveu-se um número de defeitos solicitando alterações no meu software.

Eu argumentou veementemente com o meu gerente de programa que nenhuma dessas questões eram realmente defeitos. Porque eu tinha tomado o tempo para explicar o que era possível com o meu software de gravação / reprodução do instrutor piloto começou a vislumbrar recursos adicionais que poderiam fazer seu trabalho mais fácil. Ele escreveu suas idéias num formulário defeito, embora eles foram todos capacidades que nunca planejadas para entregar e não faziam parte dos requisitos reforçada.

Mas meu gerente de projeto não queria discutir com o cliente ou esses pedidos não foram dentro do escopo, ou fora-de-alcance. Sua visão foi– como muitos software viram então e ainda vê-lo today– que é mais fácil de alterar o software de envolver o cliente em uma discussão.

Como o software é suave, tendemos a vê-lo tão fácil mudar. Não é como hardware. Metal não é facilmente dobrado. Esta perspectiva muda todo o jogo quando se trata de software.

Esta capacidade de alterar o código de software de forma rápida e em infinitas maneiras muda completamente a dinâmica que existe entre os desenvolvedores de software e suas partes interessadas, incluindo os gestores de programas e clientes. Uma maneira exemplifica esta diferença em si é como os usuários se familiarizar com o software que muitas vezes ver novas formas que muda para o software poderia fazer seu trabalho mais fácil como o meu cliente instrutor piloto fez voltar no final de 1970.

Sabemos agora a partir de experiências que existem outras dimensões para a Engenharia de Software que são fundamentais para práticas de engenharia de software profissional eficazes. Essas outras dimensões nos levar além de apenas a facilidade com que o código pode ser alterado. Até à data, essas dimensões adicionais não ter recebido qualquer lugar próximo a atenção que merecem.

Quando você alterar o código você também pode estar afetando os requisitos, e você também pode estar afetando outras capacidades do sistema de software previamente testado. Alterar código significa trabalho adicional, testes adicionais, possivelmente, mudanças para apoiar os manuais do usuário e assim por diante … Tudo isso afeta orçamento e cronograma, e introduz um risco adicional para a qualidade do software.

Enquanto, por um lado a capacidade de alterar o código do software rapidamente traz grande poder para a indústria de software, isso também significa que os profissionais de software devem ser cada vez mais sintonizar a sua forma acordada de trabalhar, o impacto eo tempo que leva para fazer o trabalho adicional, e quando o risco fazendo rápidas mudanças não planejadas. O movimento ágil ao longo dos últimos dez anos tem prestado um grande serviço para ajudar a comunidade de software entender esta importante diferença em relação à Engenharia de Software, incluindo a importância da interação precoce e contínuo com as partes interessadas ea importância de desenvolvedores de software estimar o custo de seu próprio trabalho.

Enquanto a comunidade de engenharia de software tem aprendido muito com as outras disciplinas de engenharia, eles também aprenderam a importância fundamental dessas outras dimensões que trazem diferenças de experiências de engenharia anteriores. Essas diferenças significam que os desenvolvedores de software precisam ser treinados em maneiras novas e diferentes de ser profissionais de software eficazes.

Pouco depois do pontapé inicial da iniciativa SEMAT em Março de 2010, um dos primeiros signatários da SEMAT me enviou uma cópia de rascunho de um livro que ele estava trabalhando para revisão. Watts Humphrey, que havia planejado para ser muito ativo no trabalho SEMAT cedo ficou doente, assim como o trabalho SEMAT estava se preparando e me pediram para ajudá-lo a obter o seu esforço planejado ir. No final de agosto desse mesmo ano Watts me enviou o seguinte e-mail apenas alguns meses antes de seu falecimento. Ele concordou que eu poderia compartilhar este e-mail com os outros:

Paul, De seus comentários, soa como se você fez o ponto do meu livro, pelo qual sou grato …. o correto responder e aquele que eu estava mais interessado em prosseguir com SEMAT, preocupações como podemos assegurar que os profissionais de software estão devidamente treinados e têm um conjunto adequado de atitudes e competências profissionais antes mesmo de chegar à indústria. A minha esperança é que o esforço SEMAT eventualmente será capaz de liderar a unidade para obter a comunidade acadêmica para reorientar os seus programas em ensinar profissionais de software para atuar como profissionais e para gerir a si mesmos.

quando o fazem, seus graduados será capaz de negociar com a sua gestão e para fazer um trabalho superior …. Isso é o que os profissionais devem fazer … Um bom começo nessa direção seria convencê-los da necessidade de ter pessoas de software medir o seu próprio trabalho. Desde que o trabalho de software é, como dissemos, o trabalho do conhecimento, devem ser tomadas pelos próprios profissionais de software quaisquer medidas verdadeiramente precisos. … Watts Humphrey

Watts Humphrey tem sido referido como o pai da qualidade de software. Depois de completar uma distinta carreira na IBM, ele passou a se tornar um membro do Instituto de Engenharia de Software fundador do Programa de Software Process. Em 2003 ele foi premiado com a Medalha Nacional de Tecnologia.

Hoje Watts teria sido encorajado pelo trabalho SEMAT que está acontecendo na comunidade acadêmica. O primeiro curso universitário completo baseado no novo padrão Essence foi desenvolvido e está sendo entregue aos estudantes este ano pelo Dr. Carlos Zapata na Universidad Nacional de Colômbia em Medellín, na Colômbia, e Essence está sendo usado no primeiro e segundo ano cursos de engenharia de software na KTH Royal Institute of Technology na Suécia, sob a orientação do Dr. Mira Kajko-Mattson. Houve também estudos de campo realizados com os alunos Essence pelo Dr. Cecile Peraire na Carnegie Mellon-Oeste dos Estados Unidos. O próximo passo para a comunidade SEMAT é demonstrar como Essence pode ajudar na indústria através da publicação de estudos de caso de uso real e resultados medidos em projetos industriais.



Source by Paul E McMahon

About The Author
admin