Práticas Profissionais em Engenharia de Software

Prévia do material em texto

Prática Profissional de Engenharia de Software 
Resumo baseado no SWEBOK v3
2018
Índice
Introdução............................................................................................................................. 4 
Discriminação dos temas....................................................................................................... 5
1. Profissionalismo................................................................................................................. 6
1.1. Credenciamento, Certificação e Licenciamento.............................................................. 6
1.1.1. Credenciamento........................................................................................................... 6
1.1.2. Certificação.................................................................................................................. 6
1.1.3. Licenciamento.............................................................................................................. 6
1.2. Códigos de Ética e Conduta Profissional......................................................................... 6 
1.3. Natureza e papel das sociedades profissionais............................................................... 6
1.4. Natureza e papel dos padrões de engenharia de software............................................. 7
1.5. Impacto Econômico do Software..................................................................................... 7
1.6. Contratos de trabalho...................................................................................................... 7
1.7. Questões legais................................................................................................................ 8
1.7.1. Padrões......................................................................................................................... 8
1.7.2. Marcas registradas........................................................................................................ 8
1.7.3. Patentes........................................................................................................................ 8
1.7.4. Direitos autorais........................................................................................................... 8
1.7.5. Segredos comerciais..................................................................................................... 8
1.7.6. Responsabilidade profissional...................................................................................... 9 
1.7.7. Requerimentos legais................................................................................................... 9
1.7.8. Conformidade comercial............................................................................................... 9
1.7.9. Crime Cibernético........................................................................................................ 9 
1.8. Documentação................................................................................................................ 10
1.9. Análise de Troca.............................................................................................................. 10
2. Dinâmica de Grupo e Psicologia......................................................................................... 11
2.1. Dinâmica do trabalho em equipes / grupos.................................................................... 11
2.2. Cognição Individual......................................................................................................... 11
2.3. Lidando com a Complexidade do Problema.................................................................... 12
2.4. Interagindo com os Stakeholders...................................................................................... 12
2.5. Lidando com Incerteza e Ambiguidade.............................................................................. 12
2.6. Lidando com Ambientes Multiculturais............................................................................. 12
3. Habilidades de Comunicação................................................................................................ 13
3.1. Leitura, compreensão e resumo........................................................................................ 13
3.2. Escrevendo......................................................................................................................... 13
3.3. Comunicação de equipe e grupo....................................................................................... 14
3.4. Habilidades de apresentação............................................................................................. 14
Introdução
Práticas Profissionais em Engenharia de Software
A prática profissional de engenharia de software, área de conhecimento (KA) está preocupada com o conhecimento, habilidades e atitudes que os engenheiros de software devem possuir para praticar de forma ética, profissional e responsável. Por causa das aplicações difundidas
de produtos de software em social e pessoal, a qualidade dos produtos de software pode ter
impacto profundo em nosso bem-estar pessoal e harmonia social. Engenheiros de software devem lidar com problemas únicos de engenharia, produzindo software com características e confiabilidade conhecidas.
O termo "prática profissional" refere-se a forma de conduzir os serviços de modo a atingir certos padrões ou critérios, tanto no processo de executar um serviço até o produto final
do serviço. Esses padrões e critérios pode incluir técnicas e não técnicas.
Discriminação dos Temas 
1.Profissionalismo
Um engenheiro de software exibe profissionalismo nomeadamente através da adesão aos códigos de ética e conduta profissional e aos padrões de práticas que são estabelecidas pela comunidade profissional de engenheiro.
A comunidade profissional é frequentemente representada por uma ou mais sociedades profissionais. Essas sociedades publicam códigos de ética e conduta profissional, bem como critérios de admissão para a comunidade. Esses critérios formam a base para atividades de credenciamento e licenciamento a ser usado como medida para determinar engenharia
competência ou negligência.
Credenciamento, Certificação e Licenciamento
Credenciamento 
O credenciamento é um processo para certificar a competência, autoridade ou credibilidade de uma organização. Escolas credenciadas ou programas têm a garantia de aderir a determinados padrões e manter certas qualidades.
Certificação
Certificação refere-se à confirmação das características particulares de uma pessoa. Um tipo comum de certificação é a certificação profissional, em que uma pessoa é certificada como capaz de concluir uma atividade em uma determinada disciplina em um determinado nível de competência. A certificação profissional também pode verificar a capacidade do detentor de atender aos padrões profissionais e aplicar julgamento profissional na resolução ou resolução de problemas.
Licenciamento
“Licenciamento” é a ação de dar a uma pessoa a autorização para realizar certos tipos de atividades e assumir a responsabilidade pelos produtos de engenharia resultantes. O substantivo “licença” refere-se a essa autorização e ao documento que registra essa autorização.
Códigos de Ética e Conduta Profissional
Os códigos de ética e conduta profissional incluem os valores e o comportamento que um engenheiro profissional pratica e as decisões que devem incorporar. A comunidade profissional estabelece códigos de ética e conduta profissional. Uma vez estabelecidos, os códigos de ética e conduta são impostas pela profissão. 
Violações podem ser atos de comissão, tais ocultando trabalho inadequado, revelando informações confidenciais, informações, falsificação de informações. Eles também podem ocorrer por omissão, incluindo falha em divulgar riscos.
Essas violações de códigos de éticae conduta profissional pode resultar em penalidades e possível expulsão do status profissional.
Natureza e papel das sociedades profissionais
As sociedades profissionais são compostas por um mix de praticantes e acadêmicos. Essas sociedades servem para definir, avançar e regular suas correspondentes profissões. Sociedades profissionais ajudam a estabelecer padrões profissionais, bem como códigos de ética e conduta profissional. Por essa razão, eles também se envolvem em atividades relacionadas, que incluem:
Estabelecer e promulgar um corpo de conhecimento aceito;
Credenciamento, certificação e licenciamento;
Dispensar ações disciplinares;
Avançar a profissão através de conferências, treinamento e publicações.
Padrões da Natureza e papel da engenharia de software
Os padrões de engenharia de software cobrem uma notável variedade de tópicos. Eles fornecem diretrizes para a prática de engenharia e processos de software para serem usados durante o desenvolvimento, manutenção e suporte de software. Ao estabelecer um consensual corpo de conhecimento e experiência, engenharia de software, as normas estabelecem uma base sobre qual diretriz podem ser desenvolvidas. 
Os benefícios dos padrões de engenharia de software são muitos e incluem melhorar a qualidade do software, ajudando a evitar erros, protegendo tanto os produtores do software quanto os usuários, aumenta a disciplina profissional, ajuda na transição de tecnológica, entre outros.
Impacto Econômico do Software
Software tem efeitos econômicos no indivíduo, negócios e níveis sociais. Um Software de "sucesso" pode ser determinado pela adequação de um produto para um problema reconhecido, bem como pela sua eficácia quando aplicado a esse problema.
No nível individual, para um engenheiro continuar empregado, pode depender da sua capacidade e vontade de interpretar e executar tarefas para atender às necessidades dos clientes ou dos empregadores e também suas expectativas. O cliente ou o empregador financeiro a situação pode, por sua vez, ser positiva ou negativamente afetados pela compra de software.
No nível comercial, um software aplicado corretamente para resolução de um problema, pode eliminar meses de trabalho e trazer lucros elevados nas organizações. Além disso, organizações que adquirem ou fornecem softwares de sucesso pode ser um aumento considerável para a sociedade em que operam, fornecendo emprego e melhores serviços.
1.6 Contratos de trabalho
Serviços de engenharia de software podem ser fornecidos sob uma variedade de relacionamentos entre engenheiros e clientes.
O trabalho de engenharia de software pode ser solicitado como fornecedor empresa-cliente, cliente-cliente, consultoria, contratação direta ou mesmo voluntariado. 
Em todas essas situações, o cliente e o fornecedor concordam que um produto ou serviço
será fornecido em troca de algum tipo de consideração. 
Aqui, estamos mais preocupados com o arranjo entre engenheiro e cliente e seus
acordos ou contratos de atendimento, sejam eles da variedade de contratação direta ou consultor, e os problemas que eles geralmente abordam.
Uma preocupação comum nos contratos de engenharia de software é a confidencialidade.
Portanto, engenheiros de software são frequentemente obrigados a assinar a não divulgação (NDA - non-disclosure) como condição prévia para trabalhar. 
1.7 Questões legais
Questões legais em torno da prática profissional de engenharia de software incluem importâncias relacionados a padrões, marcas comerciais, patentes, direitos autorais,
segredos comerciais, responsabilidade profissional, requisitos, conformidade comercial e crimes cibernéticos.
Portanto, é benéfico ter conhecimento dessas questões e sua aplicabilidade.
 
1.7.1 Padrões
Padrões de engenharia de software estabelecem diretrizes para práticas geralmente aceitas e requisitos mínimos para produtos e serviços fornecidos por um engenheiro de software. 
Padrões são fontes valiosas de requisitos e assistência durante a conduta cotidiana de
atividades de engenharia de software. Adesão aos padrões facilita a disciplina, enumerando
características mínimas dos produtos e práticas.
Essa disciplina ajuda a atenuar o subconsciente, suposições ou excesso de confiança em um design. Para estas razões, organizações que executam softwares e atividades de engenharia, muitas vezes incluem conformidade aos padrões como parte de suas políticas organizacionais.
Além disso, a adesão aos padrões é uma das principais componentes de defesa de ação legal ou de alegações de negligência.
1.7.2. Marcas registradas
Uma marca registrada refere-se a qualquer palavra, nome, símbolo, ou dispositivo usado em transações comerciais.
É usado para indicar a origem ou origem dos bens. A Organização Mundial da Propriedade Intelectual (WIPO) é a autoridade que enquadra as regras e regulamentos sobre marcas registradas. 
1.7.3 Patentes
As patentes protegem o direito de um inventor de fabricar e vender uma ideia. Uma patente consiste em um conjunto de direitos exclusivos concedidos por um governo soberano
para um indivíduo, grupo de indivíduos ou organização por um período limitado de tempo.
1.7.4. Direitos autorais
A maioria dos governos do mundo dá exclusividade a direitos de uma obra original ao seu criador, geralmente por um tempo limitado, promulgada como um direito autoral. Direitos autorais protegem a maneira como uma ideia é apresentada, não a ideia em si. Por exemplo, eles podem proteger a formulação particular de uma conta de um evento histórico, enquanto o evento em si não é protegido.
Os direitos autorais são de longo prazo e renováveis.
1.7.5. Segredos comerciais
Em muitos países, um ativo intelectual como uma fórmula, algoritmo, processo, design, método, padrão, instrumento ou compilação de informações pode ser considerado um “segredo comercial”, desde que esses ativos não sejam conhecidos, podem fornecer um negócio, alguma vantagem econômica.
A designação de “segredo comercial” fornece proteção se o ativo for roubado. Esta proteção
não está sujeita a um limite de tempo. No entanto, se outra parte deriva ou descobre o mesmo bem legalmente, então o ativo não está mais protegido e a outra parte também possuirá todos os direitos para usá-lo.
1.7.6. Responsabilidade profissional
É comum que os engenheiros de software se preocupem com questões de responsabilidade profissional. Como um indivíduo fornece serviços a um cliente ou empregador, é vital aderir aos padrões e práticas geralmente aceitas, protegendo assim contra alegações ou procedimentos relacionados a negligência ou incompetência.
Para engenheiros, incluindo engenheiros de software, responsabilidade profissional está relacionada à responsabilidade do produto. De acordo com as leis e regras que regem
jurisdição, os engenheiros podem ser responsabilizados por não seguir de forma completa e consciente a prática recomendada; isso é conhecido como "negligência".
1.7.7. Requerimentos legais
Engenheiros de software devem operar dentro dos limites de legislação local, nacional e internacional. Portanto, engenheiros de software devem estar cientes dos requisitos legais para:
registro e licenciamento - Incluindo exame, educação, experiência e treinamento dos
requisitos;
acordos contratuais;
legalidades não contratuais;
Informação básica sobre o direito internacional que pode ser acessado pela Organização Mundial do Comércio (WTO - World Trade Organization).
1.7.8. Conformidade comercial
Todos os profissionais de software devem estar cientes de restrições legais à importação, exportação ou reexportação de bens, serviços e tecnologia nas jurisdições em que eles trabalham. As considerações incluem controles de exportação e classificação, transferência
de bens, aquisição de recursos governamentais, licenças para uso estrangeiro de hardware e software, serviços e tecnologia por nação sancionada, entidades empresariais ou individuais, e importar restrições e deveres. Especialistas em comércio devem ser consultados para orientaçõesdetalhadas de conformidade.
1.7.9. Crime Cibernético
Crime Cibernético refere-se a qualquer crime que envolva um computador, software de computador, redes de computadores ou software incorporado que controla um sistema.
O computador ou software pode ter sido usado na prática de um crime ou pode ter
foi o alvo. Esta categoria de crime inclui fraude, acesso não autorizado, spam, obsceno ou
conteúdo ofensivo, ameaças, assédio, roubo de dados pessoais sensíveis ou segredos comerciais.
1.8 Documentação
Fornecendo documentação clara, completa e precisa é de responsabilidade de cada 
Engenheiro de software. A adequação da documentação é julgada por diferentes critérios baseados nas necessidades dos vários públicos de interesse.
Boa documentação está em conformidade com padrões e diretrizes. Em particular, engenheiros de software devem documentar:
fatos relevantes;
riscos e compensações significativas;
avisos de consequências indesejáveis ​​ou perigosas de uso ou uso indevido do software.
Engenheiros de software devem evitar:
certificar ou aprovar produtos inaceitáveis;
divulgar informações confidenciais;
falsificação de fatos ou dados.
Além disso, engenheiros de software e seus gerentes deve fornecer a seguinte documentação
para uso por outros elementos da organização de desenvolvimento do software:
especificações de requisitos de software, documentos de design, detalhes sobre o software,
ferramentas de engenharia usadas, teste de software, especificações e resultados, detalhes sobre o que adotou, métodos de engenharia de software;
problemas encontrados durante o desenvolvimento do processo.
Para partes interessadas externas (cliente, usuários, outros) a documentação do software deve
providenciar:
informações necessárias para determinar se o software vai atender às necessidades do cliente e necessidades dos usuários;
descrição do uso seguro e inseguro dos programas;
descrição da proteção de produtos sensíveis, informações criadas ou armazenadas usando o
Software;
identificação clara de advertências e crítica dos procedimentos.
O uso de software pode incluir instalação, operação, administração e desempenho de outras
funções por vários grupos de usuários e suporte pessoal. Se o cliente adquirir a propriedade
do código-fonte do software ou o direito de modificar o código, o engenheiro de software deve fornecer documentação das especificações funcionais, o design do software, o conjunto de testes e o ambiente operacional para o software.
1.9 Análise de troca
Dentro da prática da engenharia de software, engenheiro de software, muitas vezes tem que escolher entre soluções de problemas alternativos. O resultado dessas escolhas é determinado pelo engenheiro de software, a avaliação profissional dos riscos, custos,
e os benefícios das alternativas, em cooperação com as partes interessadas. A avaliação do engenheiro de software é chamada de "análise de troca". Ela permite, nomeadamente, identificar os concorrentes e requisitos complementares de software a fim de priorizar o conjunto final de requisitos definindo do software a ser construído.
2.Dinâmica de Grupo e Psicologia
O trabalho de engenharia é muitas vezes conduzido no contexto de trabalho em equipe, um engenheiro de software deve ser capaz de interagir de forma cooperativa e construtiva
com os outros para determinar primeiro e depois satisfazer as necessidades e expectativas. Conhecimento de dinâmica de grupo e psicologia é um trunfo quando interagindo com clientes, colegas de trabalho, fornecedores, e subordinados para resolver problemas de engenharia de software.
2.1 Dinâmica de trabalho em equipes / grupos
Engenheiros de software devem trabalhar com os outros. Por um lado, eles trabalham internamente em equipes. Por outro lado, eles trabalham com clientes, membros público, reguladores e outras partes interessadas. Executando equipes, aquelas que demonstram qualidade consistente de trabalho e progresso em direção aos objetivos, são coesos e possuem uma atmosfera cooperativa, honesta e focada.
Os objetivos individuais e de equipe são alinhados para que os membros naturalmente se comprometem e sentem a propriedade de resultados compartilhados.
Os membros da equipe facilitam essa atmosfera ser intelectualmente honesto, fazendo o grupo pensar, admitir ignorância e reconhecer erros. 
2.2 Cognição Individual
Engenheiros desejam resolver problemas. A habilidade de resolver problemas de forma eficaz e eficiente é o que cada engenheiro se esforça para. No entanto, os limites e processos de cognição individual afetam a resolução do problema. A cognição individual desempenha um papel muito importante na resolução de problemas. Em geral, um indivíduo (em particular, um engenheiro de software) para decompor um problema e criativamente desenvolver uma solução pode ser inibida por:
necessidade de mais conhecimento,
suposições subconscientes,
volume de dados,
medo de falha ou consequência de falha,
cultura, seja o domínio de aplicação ou
organizacional,
falta de capacidade de expressar o problema,
ambiente de trabalho percebido e
estado emocional do indivíduo.
O impacto desses fatores inibidores pode ser reduzido pelo cultivo de boa resolução de problemas e hábitos que minimizam o impacto dos enganos.
2.3 Lidando com a complexidade do problema
Problemas de engenharia de software são muito complexos e difíceis de abordar como um todo ou para ser abordado por engenheiro de software individual. Quando tais circunstâncias surgem, os meios habituais para adotar é trabalho em equipe e decomposição de problema 
As equipes trabalham juntas para lidar com grandes problemas, compartilhando encargos e desenho sobre o conhecimento e criatividade de cada um.
Quando engenheiros de software trabalham em equipes, diferentes pontos de vista e habilidades dos engenheiros individuais se complementam e ajudam a construir uma solução, isso é difícil de encontrar. 
2.4 Interagindo com o Stakeholder
Sucesso de um esforço de engenharia de software depende de interações positivas com as partes interessadas. Eles devem fornecer apoio, informação, e feedback em todos os estágios do software e no processo de ciclo de vida. Por exemplo, durante o início das fases, é fundamental identificar todas as partes interessadas e descobrir como o produto irá afetá-los, para que a definição suficiente dos requisitos das partes interessadas pode ser apropriadamente e completamente capturada.
Durante o desenvolvimento, as partes interessadas podem fornecer feedback sobre as especificações e / ou versões do software, mudança de prioridade, bem como o esclarecimento de software detalhado ou novos requisitos. Por último, durante a manutenção de software e até o final da vida útil do produto, as partes interessadas dão feedback sobre a evolução ou novos requisitos bem como relatórios de problemas para que o software possa
ser ampliado e melhorado.
Portanto, é vital manter-se aberto e ter uma comunicação com as partes interessadas para o
duração da vida útil do produto de software.
2.5 Lidando com Incerteza e ambiguidade
Tal como acontece com engenheiros de outros campos, engenheiros de software deve muitas vezes lidar com a incerteza da resolução e ambiguidades ao fornecer serviços e desenvolvimento de produtos. O engenheiro de software deve atacar e reduzir ou eliminar qualquer falta de clareza que é um obstáculo para a realização de trabalhos.
Muitas vezes, a incerteza é simplesmente um reflexo da falta de conhecimento. Neste caso, a investigação através de recorrer a fontes formais, como livros didáticos e revistas profissionais, entrevistas com as partes interessadas, ou consulta com colegas de equipe e colegas podem
superá-lo.
Quando incerteza ou ambiguidade não podem ser superadas facilmente, engenheiros ou organizações de software pode optar por considerá-lo como um risco de projeto. 
Nesse caso, estimativas de trabalho ou preços são ajustados para apurar o custo antecipado do seu tratamento.2.6 Lidando com Ambientes Multiculturais
Ambientes multiculturais podem ter impacto na dinâmica de um grupo. Isso é especialmente
verdade quando o grupo está separado geograficamente ou a comunicação é pouco frequente, uma vez que essa separação eleva a importância de cada contato.
A comunicação intercultural é ainda mais difícil se a diferença nos fusos horários faz
comunicação menos frequente.
Ambientes multiculturais são bastante prevalentes em engenharia de software, talvez mais do que em outros campos da engenharia, devido à forte tendência da terceirização internacional e do fácil embarque de componentes de software. Por exemplo, é bastante comum para um
projeto de software possa ser dividido em partes em toda fronteiras nacionais e culturais, e é também bastante comum para uma equipe de projeto de software consistir de pessoas de diversas origens culturais.
Para um projeto de software ser um sucesso, a equipe, os membros devem atingir um nível de tolerância, reconhecendo que algumas regras dependem das normas e que nem todas as sociedades derivam a mesmas soluções e expectativas.
3.Dinamica de Grupo
Engenheiros de software devem trabalhar com os outros. Por um lado, eles trabalham internamente em engenharia e equipes, por outro lado, eles trabalham com clientes,
membros do público, reguladores e outras partes interessadas.
Aquelas que demonstram qualidade consistente de trabalho e progresso em direção aos objetivos, são coesos e possuem uma atmosfera cooperativa, honesta e focada.
Os objetivos individuais e de equipe são alinhados para que os membros naturalmente se comprometem e sentem a propriedade de resultados compartilhados.
3.1 Leitura, compreensão e resumo
Engenheiros de software são capazes de ler e entender um material técnico. Material técnico
inclui livros de referência, manuais, pesquisas, documentos e código-fonte do programa.
A leitura não é apenas uma forma primária de melhorar habilidades, mas também uma maneira de coletar informações necessárias para a conclusão dos objetivos. Um engenheiro de software vasculha informações, filtrando as peças que será mais útil. Os clientes podem solicitar que um engenheiro de software resuma os resultados de tal coleta de informações para eles, simplificando ou explicá-los para que eles possam fazer uma escolha final entre soluções concorrentes.
Ler e compreender o código-fonte é também um componente de coleta de informações e
Solução de problemas. Ao modificar, estender, ou reescrever o software, é essencial entender
tanto a sua implementação derivada diretamente do código apresentado e seu design, que deve muitas vezes ser inferido.
3.2 Escrita
Engenheiros de software são capazes de produzir produtos conforme exigido pelas solicitações do cliente ou geralmente aceita. Estes produtos escritos podem incluir código-fonte, planos de projeto de software, documentos de requisitos de software, análises de risco, documentos de projeto de software, planos de teste de software, manuais do usuário, relatórios técnicos e avaliações, justificações, diagramas e gráficos, e assim por diante.
Escrever de forma clara e concisa é muito importante porque muitas vezes é o principal método de comunicação entre as partes relevantes. Em todos os casos, produtos de engenharia de software escritos devem ser escritos de modo que sejam acessíveis, compreensíveis e relevante para o (s) público (s) pretendido (s).
3.3 Comunicação de equipe e grupo
Comunicação eficaz entre equipe e grupo e membros é essencial para um software.
 As partes interessadas devem ser consultadas, decisões devem ser tomadas e os planos devem ser gerados. Quanto maior o número de equipe e membros do grupo, maior a necessidade de comunicação.
O número de caminhos de comunicação, no entanto, cresce com a adição de cada membro da equipe. Alguma comunicação pode ser realizada em escrita. A documentação do software é uma substituição da interação direta. E-mail é outro, mas, embora seja útil, nem sempre é suficiente. Também, se alguém envia muitas mensagens, torna-se difícil identificar as informações importantes.
Cada vez mais, as organizações estão usando ferramentas de colaboração para compartilhar informações. Algumas equipes de engenharia de software focam interação face-a-face e promovem essa interação por arranjo de espaço de escritório. 
3.4 Habilidades de apresentação
Engenheiros de software confiam em sua apresentação e habilidades durante os processos do ciclo de vida do software. Por exemplo, durante a fase de requisitos de software, os engenheiros de software podem orientar os clientes e colegas de equipe por meio de requisitos de software e realizar revisões formais do projeto. Durante e depois do design do software, construção de software e manutenção de software, engenheiros de software conduzem análises, orientações sobre produtos e treinamento. Tudo isso requer a
capacidade de apresentar informações técnicas a grupos e solicitar ideias ou feedback.