SEMAT

FACULDADE SUMARÉ
CAIO HENRIQUE DO NASIMENTO DE FRANÇA 1417103
FABIO ROBERTO RIBEIRO DE ALVARENGA 1515833
RODRIGO SILVA DA ROSA 1413096
LINYKER JEAN SIQUEIRA SILVEIRA 1415780
SEMAT
São Paulo
2016

FACULDADE SUMARÉ
CAIO HENRIQUE DO NASIMENTO DE FRANÇA 1417103
FABIO ROBERTO RIBEIRO DE ALVARENGA 1515833
RODRIGO SILVA DA ROSA 1413096
LINYKER JEAN SIQUEIRA SILVEIRA 1415780
SEMAT
Relatório final, apresentado a Faculdade
Sumaré, referente ao Projeto
Profissionalizante Interdisciplinar sob
orientação do Professor Ernesto de
Carvalho Bedrikow.
São Paulo, 26 de maio de 2016.
São Paulo
2016

Dedicamos este trabalho a
todos que contribuíram direta
ou indiretamente em nossa
formação acadêmica.

AGRADECIMENTOS
Agradecemos a todos que contribuíram na
resolução deste projeto. Primeiramente a
Deus, a quem deveremos nossa vida. As
nossas famílias que sempre nos apoiaram nos
estudos e nas escolhas tomadas. Saudamos
também o pesquisador e professor do SEMAT
Marcel Simonette que nos possibilitou maior
compreensão do tema, assim como o nosso
orientador Prof. Ernesto de Carvalho Bedrikow
que teve papel fundamental na elaboração
deste trabalho e aos nossos colegas por nos
ajudar direta ou indiretamente na conclusão
deste trabalho.

RESUMO
O mundo hoje sofre revoluções tecnologias em escala tão ampla e de forma tão
acelerada que se compararmos a evolução dos dez últimos anos em relação ao
resto da história, podemos concluir de maneira simples que nesta época a evolução
foi maior. Isto ocorre pelo fato das revoluções tecnológicas e industriais acelerarem
os processos que permitem a evolução global em segmentos como saúde,
infraestrutura, mobilidade, segurança e etc., porém, encontrar uma maneira eficiente
e eficaz de gerenciar todas essas criações e modificações, com segurança, melhor
uso de matéria prima, otimização do tempo e do custo, é até hoje um grande
desafio. O SEMAT – Software Engineering Method and Theory – tem o objetivo de
mudar este cenário auxiliando o gerenciamento através de melhores práticas para
garantir prazo e custo.
Palavras-Chave: Stakeholders, SEMAT, Alphas, Gerenciamento, Kernel e Atividade.

ABSTRACT
The world today suffers scale technology revolutions so broad and so accelerated so
that if we compare the evolution of the last ten years compared to the rest of the
story, we can conclude simply that at this time the development was higher. This
occurs because of the technological and industrial revolutions accelerate the
processes that enable the overall development in segments like health,
infrastructure, mobility, security, etc., however, find an efficient and effective way to
manage all these creations and modifications safely better use of raw materials,
optimization of time and cost, is today a major challenge. The SEMAT - Software
Engineering Method and Theory - aims to change this scenario assisting
management through best practices to ensure time and cost.
Keywords: Stakeholders, SEMAT, Alphas, Management, Kernel and Activity.

LISTA DE FIGURAS
Figura I - Cliente.......................................................................................................................... 11
Figura II ...................................................................................................................................... 12
Figura III - Alphas do Kernel................................................................ Error! Bookmark not defined.
Figura IV - Atividades................................................................................................................... 14
Figura VI - Reconhecer Solução .................................................................................................... 16
Figura VII - Viabilidade................................................................................................................. 17
Figura VIII - Endereço/Apontado .................................................................................................. 18
Figura XIVIII – Satisfação em Uso.................................................................................................. 22
Figura IXV – Uso prático da área de interesse do cliente ................................................................ 23
Figura XVI - Oportunidades .......................................................................................................... 24
Figura XIX - Pronto....................................................................................................................... 32
Figura XXIV – Sistema de Software......................................................................................... 42
Figura XXV - Sistema de Software........................................................................................... 43
Figura XXVI – A Crise do Software.......................................................................................... 44
Figura XXVII – A Crise do Software......................................................................................... 45
Figura XXVIII – A Crise do Software............................................................................................... 45
Figura XXX – A Crise do Software........................................................................................... 46
Figura XXXI –A Crise do Software........................................................................................... 48
Figura XXXIII- Esforço (Endeavor).................................................................................................. 52
Figura XXXIV - Esforço.................................................................................................................. 54
Figura XXXV - Esofrço................................................................................................................... 55
Figura XXXVI – 5W2H................................................................................................................... 56
Figura XXXVII – 5W2H.................................................................................................................. 57
Figura XXXVIII – 5W2H ................................................................................................................. 58
Figura XXXIX – 5W2H ................................................................................................................... 59

SUMÁRIO
1 INTRODUÇÃO..............................................................................................................9
2 SEMAT – ALPHA CLIENTES...................................................................................11
2.1 Alphas: .........................................................................................................................11
2.2 Os Alphas do Kernel:.................................................................................................12
2.3 Alphas do Kernel (Cliente)........................................................................................12
2.3.1 Oportunidades: ...........................................................................................................13
2.3.2 Stakeholders:..............................................................................................................13
2.4 Espaço de atividades.................................................................................................13
2.5 Explorar as possibilidades ........................................................................................14
2.6 Entender as necessidades do Stakeholders .........................................................14
2.7 Assegurar a satisfação do Stakeholders ................................................................14
2.8 Usar o sistema............................................................................................................14
2.9 Guia de Referência – Clientes .................................................................................15
2.10 Uso prático da área de interesse do cliente...........................................................22
2.10.1 Identificada..................................................................................................................24
2.10.2 Solução necessária....................................................................................................24
2.10.3 Valor estabelecido......................................................................................................24
2.10.4 Viável............................................................................................................................25
2.10.5 Endereçada.................................................................................................................25
2.10.6 Benefício acumulado.................................................................................................25
2.10.7 Reconhecido...............................................................................................................25
2.10.8 Representante ............................................................................................................25
2.10.9 Envolvido.....................................................................................................................26
2.10.10 De acordo..............................................................................................................26
2.10.11 Satisfeito com a implantação.............................................................................26
2.10.12 Satisfeito pelo uso ...............................................................................................26
3 REQUISITOS E SISTEMA DE SOFTWARE .........................................................27
3.1 Descrição de Exigências (Requisitos) ....................................................................27
3.2 Justificação: O porquê das exigências? .................................................................28
3.3 Progredindo as exigências do sistema de software e requisitos........................29
3.4 Verificar o progresso das exigências ......................................................................31
3.5 Sistema de software ..................................................................................................38
3.5.1 Estados da Arquitetura ..............................................................................................39
3.6 Espaços das atividades.............................................................................................42
3.7 Resumo da Palestra: Explanando o SEMAT.........................................................43
3.8 A crise do Software....................................................................................................44
3.9 Respostas para crise do software ...........................................................................46
4 RESPONSABILIDADE ..............................................................................................49
4.1 Cliente: .........................................................................................................................49
4.2 Solução: .......................................................................................................................50
4.3 Esforço:........................................................................................................................50
4.4 ESFORÇO (Endeavor)..............................................................................................52
4.4.1 •preparar-se para fazer o trabalho: .........................................................................52
4.4.2 •coordenar atividade:.................................................................................................52

4.4.3 •apoiar a equipe:.........................................................................................................52
4.4.4 •acompanhar o progresso:........................................................................................53
4.4.5 •parar o trabalho:........................................................................................................53
4.5 Alfas (Alphas)..............................................................................................................55
4.6 5W2H............................................................................................................................55
5 BIBLIOGRAFIA...........................................................................................................61

9
1 INTRODUÇÃO
Com o adjunto da evolução desenfreada que o mundo vem sofrendo
atualmente, cada vez mais se fazem necessárias novas ferramentas e produtos que
possam facilitar atividades e processos. No entanto, o desenvolvimento de projetos
que efetivem tais criações sofre até hoje com a conclusão fora dos prazos
acordados, bem como com a utilização errônea dos recursos previstos. O SEMAT,
classificado por seus criadores como maneira de facilitar o gerenciamento de
projetos, não é nem um método, modelo tampouco uma metodologia. Seu objetivo é
o de ser uma ferramenta que aliada as melhores práticas tem o objetivo de corrigir
as falhas que os antigos métodos possuíam, assim como o famoso UML, também
obra de criação de Ivar Jacobson.
Este conteúdo foi desenvolvido após anos de estudo e análise dos maiores
gestores de projeto e promete ser a solução mais viável para um gerenciamento de
projeto mais efetivo, eficiente e eficaz.
Pretendemos apresentar com esse material todo o conteúdo já disponibilizado
pela comunidade com o objetivo de reunir todas as informações à cerca do SEMAT
e sua utilização. Tivemos a oportunidade de estudar o material com um dos
integrantes e pesquisadores do projeto, o que tornou a pesquisa ainda mais efetiva.

10
2 TABELA DE RESPONSABILIDADE
Este trabalho teve sua divisão gerenciada da seguinte forma:
Caio Fabio Linyker Rodrigo
Junção das partes
As três áreas:
Solução
As três áreas:
Cliente
As três áreas:
Esforço
Formatação ABNT
Cartão:
Requisitos
Cartão:
Oportunidades
Cartão:
Trabalho
Introdução
Cartão:
Sistema de Software
Cartão:
Stakeholders
Cartão:
Equipe
Conclusão
Descrever as fases
da:
Solução
Descrever as fases
do:
Cliente
Cartão:
Modo de Trabalho
Revisão de todas as
partes
Descrever as fases
do:
Esforço
Resumo
Apresentação PPT

11
3 SEMAT – ALPHA CLIENTES
Área que se preocupa em saber se o time entende os Stakeholders e a
oportunidade que está sendo endereçada.
Contém tudo para entender a utilização real e a exploração do sistema de
software a ser produzido, esse é um dos Alphas mais importantes, pois é aí que
definimos como vai funcionar o software e também os quais serão suas
funcionalidades.
3.1 Alphas:
Representações das coisas que são essenciais a serem usadas no trabalho,
eles fornecem descrições do tipo de coisas que uma equipe gerenciará, produzir e
usar no processo de gerenciamento, manutenção e suporte de um bom software, os
Alphas são divididos em três partes, a primeira é o cliente, a segunda é a solução e
a terceira é o esforço.
ClienteFigura I - Cliente

12
Cada um dos Alphas tem um determinado objetivo, primeiramente na área do
cliente surgem as oportunidades, depois tem as partes interessadas, com isso é
definido o sistema de software que faz parte da solução onde os requisitos serão
definidos, depois disso vem a área do esforço, onde será definida a equipe e o
trabalho de cada integrante, assim como o modo de trabalho e suas
responsabilidades.
3.2 Os Alphas do Kernel:
Os Alphas de uma forma geral, tem suas finalidades, dentre elas os princípios
são:
- Capturam os conceitos chave envolvidos na engenharia de software.
- Permitem avaliar e monitorar o progresso e a saúde de qualquer esforço.
- Fornecem a base para a definição de métodos e práticas.
3.3 Alphas do Kernel (Cliente)
Figura II

13
3.3.1 Oportunidades:
O conjunto de circunstancias que toma apropriado desenvolver ou alterar um
sistema de software.
3.3.2 Stakeholders:
As pessoas, grupos ou organizações que afetam ou são afetadas por um
3.4 Espaço de atividades
Dentro do alpha cliente, tem algumas atividades específicas que são definidos
por suas responsabilidades, elas são separadas em uma sequência lógica, que tem
como características, sua principal tarefa é demonstrar cada etapa de recepção das
informações e dados, assim como também demonstrar em suas tarefas um uma
linha do tempo como é separado o seu ciclo. Abaixo estão as definições de cada
Figura III – Oportunidade, Stakeholders

14
uma das atividades.
3.5 Explorar as possibilidades
Devem-se explora as possibilidades apresentadas pela criação de um sistema
de software novo ou melhorado. (Para isso é importante analisar a oportunidade e
identificar os Stakeholders).
3.6 Entender as necessidades do Stakeholders
É preciso envolver as partes interessadas para entender suas necessidades e
garantir que os resultados corretos sejam produzidos. Isto inclui identificar e
trabalhar lado a lado com os representantes dos Stakeholders para entender a
oportunidade.
3.7 Assegurar a satisfação do Stakeholders
Compartilhar os resultados do trabalho de desenvolvimento com os
Stakeholders para ganhar aceitação do sistema produzido e verificar se a
oportunidade foi alterada com sucesso.
3.8 Usar o sistema
Usar o sistema em um ambiente vivo para beneficiar os Stakeholders.
Figura III - Atividades

15
Figura V
3.9 Guia de Referência – Clientes
Área Cliente: (verde)
A equipe precisa conhecer os clientes e reconhecer as oportunidades.
Oportunidade:
O conjunto de circunstâncias que o torna adequado para desenvolver ou alterar um
A oportunidade articula a razão para a criação do novo sistema, ou alterado, sistema
de software. Ele representa que a equipe tem o entendimento compartilhado com os
interessados. Precisam ajudar a moldar os requisitos para o novo sistema de
software, fornecendo uma justificativa para seu desenvolvimento.
A união dos envolvidos é que fornece a motivação para a produção de um novo
sistema ou atualizações de software. É através da compreensão das oportunidades
que identifica o valor e o resultado desejado dos interessados realizar a utilização do

16
sistema de software, seja sozinho ou como parte de um negócio mais amplo ou
solução técnica.
Check list - OPORTUNIDADES
Figura V - identificadas
Figura IVI - Reconhecer Solução

17
Figura V – Estabelecer valores
Figura VII - Viabilidade

18
Figura VIII - Endereço/Apontado
Figura IX – Medir Benefícios
O ALPHA Stakeholders

19
Stakeholders: As pessoas, grupos ou afetar ou organismos que são afetados por um
Proporcionar a oportunidade, são a fonte dos "requisitos para o sistema de software. Eles
estão envolvidos em todo o esforço de engenharia de software para apoiar a equipe
assegurando que o sistema software produzido é aceitável no período.
As partes interessadas são fundamentais para o sucesso do sistema de software e o
trabalho realizado para produzi-lo. A sua forma de entrada e feedback ajuda o esforço de
engenharia de software e do sistema resultante.
A visão geral do ALPHA são mostrados nos cartões abaixo.
Check List Alpha para os stakeholders.
Figura X – Reconhecido
Stakeholders
Reconhecido
Representado
Envolvido
Em acordo
Satisfeito pela Implantação
Satisfeito pelo Uso
Atendido
As pessoas, grupos ou organizações
que são ou foram afetadas sistema de
software
* O envolvido está representado
* Concordam em realizar suas
responsabilidades.
* Cooperação para chegar ao acordo

20
Figura XI – Reconhecer Solução
Figura XII - Envolvido

21
Figura XIII – Em Acordo
Figura XIII – Satisfeito pela Implantação

22
Figura XIVIII – Satisfação em Uso
3.10 Uso prático da área de interesse do cliente
Para que se possa intender melhor a área de interesse do cliente, será
explicada passo a passo como realizar a prática desse alpha.
Será utilizado essa prática em um desenvolvimento de software para a
administração de uma imobiliária.
Será dividido em passos para que se possa ter um entendimento melhor.
Passo 1 (Identifique a oportunidade).
Nesse caso, já foi determinado que será desenvolvido um software que auxilie
na administração de uma imobiliária.
Esse software precisa conter um controle de todas os imóveis que tem para
alugar, vender ou administrar, assim também como alguns usuários com permissões
que condizem que os cargos e com as tarefas a serem executadas.
Passo 2(Entenda melhor o que será feito).
Para que se possa realizar a análise a assim definir o que será feito,
precisamos saber quem utilizara o sistema, a seguir será apresentada um diagrama

23
de hierarquia. Com base nesse diagrama, podemos saber quem é que terá mais
privilégio no sistema desenvolvido, no caso dessa empresa, os corretores e os
pedreiros só poderão consultar as informações e a faxineira não terá nenhum
privilégio.
Também foi elaborado um diagrama caso de uso para que assim possamos
identifica como será o funcionamento do software.
Figura IXV – Uso prático da área de interesse do cliente
Por esse diagrama, pode-se verificar que a secretaria pode cadastrar e
gerenciar os imóveis nesse software e o gerente tem essas permissões e também
consegue gerenciar os usuários.
Com essas ilustrações podemos identificar como será realizado o software a
assim poder definir melhor a etapa de oportunidades referente ao cliente.

24
Passo 3 (Aplicando as cartas do SEMAT sobre as oportunidades)
3.10.1 Identificada
Será necessário identificar as oportunidades no mercado e assim poder se
preparar para os requisitos exigidos.
3.10.2 Solução necessária
Identificado a oportunidade para o negócio, é hora de achar uma solução para
os problemas, para que se possa ter sucesso nessa etapa, é necessário
entendermos melhor o negócio e saber como
ele funciona no dia a dia, as soluções devem
solucionar os problemas diários da empresa ou organização e deve facilitar o serviço
dos funcionários da empresa.
3.10.3 Valor estabelecido
Deve-se fazer uma análise e também definir uma equipe assim como tudo o
que se faz necessário para que se possa estabelecer o valor, um projeto de sucesso
não ultrapassa o valor estabelecido, então essa é uma etapa muito importante e
necessária para que o projeto não seja interrompido.
Figura XVI - Oportunidades

25
3.10.4 Viável
Essa etapa determina de o produto é viável para a empresa e também se
será útil no dia a dia, facilitando o serviço e trazendo lucros para a empresa, é feito
uma análise de custo benefício do projeto.
3.10.5 Endereçada
Faz uma análise direta de como funciona o negócio em específico e de todas
as tarefas manuais da organização.
3.10.6 Benefício acumulado
Depois de pronto o projeto, é feito uma análise de todos os benefícios
acumulados sobre a empresa e assim determina se valeu a pena o esforço.
Passo 4 (Identificar os Stakeholders)
Nessa etapa, temos que identificar quem são os Stakeholders, ou seja todas
as partes interessadas ou afetadas por esse projeto. Pelo que já verificamos nos
diagramas anteriores, serão afetados por esse projeto, todos os funcionários da
empresa, bem como os integrantes da equipe de desenvolvimento do software.
Passo 5 (Aplicando as cartas do SEMAT sobre os Stakeholders)
3.10.7 Reconhecido
Pelo que se pode ver, a carta referente ao Stakeholders, tem a requisito
reconhecido, que seria a parte que será contemplado pelo projeto.
3.10.8 Representante

26
Também tem o requisito referente ao representado, que é quem vai responder
pela empresa e assim representá-la, ele é que vai participar das reuniões de
definição e requisitos desse projeto em questão.
3.10.9 Envolvido
Tem os envolvidos, que são todos que participarão do projeto e também
auxiliar no planejamento e execução do mesmo, eles podem ser desde os
estagiários até o gerente desse projeto.
3.10.10 De acordo
Tem a etapa de acordo, que é as pessoas que autorizam a execução e
também quem pode opinar sobre as etapas do projeto, até quando o mesmo for
entregue.
3.10.11 Satisfeito com a implantação
Tem também a parte de satisfeito com a implantação, onde será feito um
estudo referente a opinião de todos os funcionários da imobiliária e certificar assim
se a implantação ocorreu da forma esperada.
3.10.12 Satisfeito pelo uso
Por último, tem a parte de satisfeito com o uso do projeto, essa etapa avalia o
software em si, e analisa se o mesmo trouxe benefícios ativos para a empresa
prestadora desse serviço.Com todos esses passos, podemos entender melhor como
é realizado a parte prática de avaliação e do uso dos cartões referente a área do
cliente. As próximas etapas terão outro tipo de análise pois vão se tratar de solução
e esforço.

27
4 REQUISITOS E SISTEMA DE SOFTWARE
4.1 Descrição de Exigências (Requisitos)
O que o sistema de software deve fazer para dirigir a oportunidade e
satisfazer os depositários de dinheiro de apostas. É importante descobrir o que é
necessário do sistema de software, compartilhe esta compreensão entre os
depositários de dinheiro de apostas e os membros de equipe, e use-a para dirigir o
desenvolvimento e a prova do novo sistema.
Requisitos: O que o sistema de software deve fazer para resolver uma oportunidade
e satisfazer as partes interessadas.
É de suma importância descobrir o que é necessário que o sistema de software,
compartilhar esse entendimento entre as partes interessadas e os membros da
equipe, e usá-lo para direcionar o desenvolvimento e teste do novo sistema.
Os requisitos são vistos como um conjunto de itens. Os requisitos devem ser
comunicados e documentados em várias formas e vários níveis de detalhe. É
importante que os requisitos sejam compreendidos, bem como os itens individuais.
Entre outras coisas isto vai ajudá-lo a dizer que o sistema está concluído e se a
decisão individual dos requisitos está dentro do escopo.
Figura XVII – Requisitos e Sistema de Software

28
4.2 Justificação: O porquê das exigências?
As exigências capturam o que os depositários de dinheiro de apostas querem
do sistema. Definem o que o sistema deve fazer, mas não necessariamente como
deve fazê-lo. Descrevem o valor que o sistema fornecerá dirigindo a oportunidade e
como a oportunidade se perseguirá pela produção de um novo sistema de software.
Também alcance e reprimem o trabalho definindo que necessidades se realizar.
As exigências capturam-se como grupo de itens de exigência. Os itens de
exigência podem comunicar-se e registrar-se em várias formas e a vários níveis do
detalhe. Podem comunicar-se explicitamente como grupo de documentos de
exigências extensos ou mais tacitamente na forma de sessões de tempestade de
ideias e conversações. Os próprios itens de exigência sempre se documentam e
seguem-se a pista. A documentação pode tomar muitas formas e ser tão breve
como uma história de usuário de uma linha ou tão abrangente como um caso de
uso.
Enquanto o desenvolvimento do sistema prossegue, as exigências
desenvolvem-se e priorizam -se constantemente e ajustam-se para refletir as
necessidades se modificam dos depositários de dinheiro de apostas. Muito é
implícito no início faz-se explícito depois acrescentando itens de exigência mais
detalhados como características de qualidade bem definidas e casos de experiência.
Isto permite às exigências de atuar como uma especificação verificável do sistema
de software. Apesar de como os itens de exigência se capturam é essencial que
pode mostrar-se que o sistema de software produzido cumpre com sucesso as
exigências. É por isso que as exigências desempenham um papel tão essencial na
prova do sistema. Bem como fornecendo uma definição de que necessidades se
realizar, também permitem seguir a pista do que se realizou. Como a prova de cada
item de exigência conclui-se pode marcar-se individualmente como feito, e as
exigências no conjunto podem olhar-se para ver se o sistema produzido
suficientemente cumpre as exigências e se o trabalho no sistema se termina.
É importante que o estado total dos requisitos as exigências então não se
entendem será impossível contar. Primeiro quando o sistema se termina, e segundo

29
julgue se um item de exigência individual é uma exigência deste sistema ou outro
sistema.
4.3 Progredindo as exigências do sistema de software e requisitos
Durante o desenvolvimento de um sistema de software as exigências
progridem por várias modificações estatais. Concebem-se, limitaram, coerentes,
aceitáveis, dirigidos e cumpriram.
Estes estados concentram-se na evolução da compreensão da equipe do que
o sistema proposto deve fazer, do conceito de um novo jogo de exigências como
uma ideia inicial de um novo sistema de software por meio do seu desenvolvimento
ao seu cumprimento pela provisão de um sistema de software usável.
As exigências começam no estado concebido quando a necessidade de um
novo sistema de software se aceitou. Os depositários de dinheiro de apostas podem
manter visões se diferenciam da significação total das exigências. Contudo, todos
eles aceitam que há uma necessidade de um novo sistema de software e uma
oportunidade clara a perseguir-se.
Antes que demasiado tempo se passe reunindo-se e detalhando os itens de
exigência individuais as exigências no conjunto devem limitar-se. Ao amarrado as
exigências, o alcance total do novo sistema, os aspectos da oportunidade a dirigir-
se, e os mecanismos para arranjar-se e aceitar que itens de exigência novos ou
modificados toda a necessidade a se estabelecem. No estado limitado ainda podem
haver inconsistências ou as ambiguidades entre os itens de exigência individuais.
Contudo, os depositários de dinheiro de apostas agora têm uma compreensão
compartilhada do objetivo do novo sistema e podem contar se um pedido se prepara
como um item de exigência.
Também entendem os mecanismos a usar-se para desenvolver os itens de
exigência e retirar as inconsistências. Uma vez que as exigências se limitam há uma
compreensão compartilhada do alcance do novo sistema e está seguro começar a
implementar os itens de exigência mais importantes.

30
Além disso o refinamento, a análise, a negociação, a manifestação e a revista
dos itens de exigência individuais levam a um jogo coerente de exigências, aquela
que claramente define as características essenciais do novo sistema. Os itens de
exigência continuam desenvolvendo-se como mais se aprende sobre o novo sistema
e o seu impacto nos seus depositários de dinheiro de apostas e ambiente. Não
importa quanto os itens de exigência modificam, é essencial que ficam dentro dos
limites do conceito original e que permanecem coerentes sempre.
A evolução contínua das exigências leva à captura de um jogo aceitável de
exigências, aquela que define um sistema que será aceitável para os depositários de
dinheiro de apostas como, pelo menos, uma solução inicial. As exigências só podem
descrever uma solução parcial; contudo a solução descrita é do valor suficiente que
os depositários de dinheiro de apostas o aceitariam para o uso operacional. O
número de itens de exigência que têm de aceitar-se para as exigências de ser
aceitáveis para os depositários de dinheiro de apostas pode variar de um a muitos.
Modificando um sistema maduro pode ser aceitável dirigir somente um item de
exigência importante, construindo um sistema de substituição um grande número de
itens de exigência precisará de dirigir-se.
Como os itens de exigência individuais implementam-se e um sistema usável
desenvolve-se, lá virá um tempo quando bastantes exigências se implementaram
para o novo sistema para valer a pena lançar e usar. No estado dirigido o montante
de exigências que se dirigiram é suficiente para o sistema resultante para fornecer o
valor claro aos depositários de dinheiro de apostas. Se o sistema resultante fornecer
uma solução completa então as exigências podem avançar imediatamente ao
estado cumprido.
Normalmente, quando o estado dirigido se realiza o sistema resultante
fornece uma solução valiosa, mas incompleta. Para dirigir totalmente a
oportunidade, os itens de exigência adicionais deveriam implementar-se. O
complemento pode consistir em porque uma aproximação incremental da entrega do
sistema se selecionou, ou porque as exigências ausentes foram difíceis de identificar
antes que o sistema se pusesse à disposição para o uso.

31
No cumprido o bastante estado dos itens de exigência implementou-se para
os depositários de dinheiro de apostas para aceitar que o sistema resultante
totalmente satisfaz a necessidade de um novo sistema, e que não há itens de
exigência salientes que impedem o sistema de considerar-se completo.
Entender o estado atual e desejado das exigências pode ajudar todo o mundo
a entender o que o sistema tem de fazer e como perto concluí-lo é
4.4 Verificar o progresso das exigências
Para ajudar a avaliar o estado das exigências e o progresso que se faz em
direção à sua conclusão bem-sucedida, as seguintes listas de conferência das
atividades (Check list):
Figura XVIII – Sistema de Software

32
Figura XIX - Pronto
Figura XX - Concebido

33
Figura XXI – Delimitado
Figura XXII - Coerente

34
Figura XXIII – Demonstrável
Figura XXIV - Operacional

35
Figura XXV – Retirado
Figura XXVI – Usável

36
Figura XVIII - REQUERIMENTOS
Figura XXVII – Aceitável

37
Figura XX – Arquitetura Selecionada
Figura XIX - Endereçado

38
Figura XXII – Tarefas
4.5 Sistema de software
Sistema de software: Um sistema compôs de software, hardware e dados que
fornecem o seu valor primário pela execução do software. Um sistema de software
pode ser parte de um software maior, hardware, solução de negócios ou sócia
Figura XXI – Progresso das Exigências

39
4.5.1 Estados da Arquitetura
A arquitetura selecionou que dirige os riscos técnica-chave e qualquer
constrangimento organizacional aplicável. Demonstrável. Uma versão executável do
sistema está disponível que se manifesta o a arquitetura é própria com o objetivo e
apoia funcional e não-funcional prova.
O sistema está no uso em um ambiente vivo. A essência usa o sistema de
software de termo em vez de software porque a engenharia de software resulta em
mais do que somente uma parte do software. Enquanto o valor pode vir bem do
software, um sistema de software de trabalho depende da combinação de software,
hardware e dados para cumprir as exigências. Progredindo o sistema de software
O ciclo de vida de um sistema de software é difícil definir como podem haver
muitos lançamentos de um sistema de software. Estes lançamentos podem
trabalhar-se em e usar-se na paralela. Por exemplo uma equipe pode estar
trabalhando no desenvolvimento do lançamento 3, enquanto outra equipe faz
pequenas modificações do lançamento, e uma terceira equipe fornece o suporte
daquelas pessoas que ainda usam o lançamento. Se tratarmos este sistema de
software como uma entidade em que o estado é ele?
Figura XXIII – Sistema de Software

40
Para guardar coisas simples, a Essência trata cada lançamento principal
como um sistema de software separado; aquele que se constrói, lançou, atualizado,
e consequentemente retirou-se. Um lançamento principal abrange mudanças
significativas ao objetivo, uso ou arquitetura de um sistema de software. Pode
abranger muitos lançamentos menores inclusive lançamentos internos produzidos
para testar objetivos e lançamentos externos produzidos para apoiar entrega
incremental ou embaraços de defeito. No exemplo acima da segunda equipe estaria
produzindo uma série de lançamentos menores do seu sistema de software para
permitir a entrega das suas pequenas modificações.
Durante o seu desenvolvimento um sistema de software progride por várias
modificações estatais. São arquitetura selecionada, demonstrável, usável, pronta,
operacional e retirada. Estes estados fornecem pontos da estabilidade em uma
viagem de sistema de software do seu conceito à sua retirada eventual que indica
quando a arquitetura se seleciona, quando um sistema demonstrável se produz para
comprovar a arquitetura e permitir testar para começar, quando o sistema se
estende e se melhora para que fique usável, quando o sistema usável se realça até
que se aceite como pronto para o desdobramento, quando o sistema se põe à
disposição dos depositários de dinheiro de apostas que o usam e feito operacional, e
finalmente, quando o próprio sistema se retira e o seu suporte retira-se. Estes
estados podem aplicar-se ao lançamento inicias segurar-se que há uma arquitetura
apropriada disponível; aquele que cumpre com qualquer constrangimento
organizacional aplicável e dirige os riscos técnica-chave que ficam em frente do
novo sistema. A realização disto podem necessitar a criação de uma marca nova
arquitetura, a modificação de uma arquitetura existente, a seleção de uma
arquitetura existente ou a reutilização simples do que já está no lugar. Apesar da
aproximação tomada, o resultado consiste em que o sistema progride à arquitetura o
estado selecionado.
Uma vez que a arquitetura se tinha selecionado, deve mostrar-se que é
própria para o objetivo construindo e testando uma versão demonstrável do sistema.
Não é suficiente apresentar somente o grupo de capturas de tela rolantes ou uma
versão autônoma de um sistema multiusuário. O sistema tem de ser exercício
realmente demonstrável de todas das características significantes da arquitetura

41
selecionada. Também deve ser capaz do apoio tanto a prova funcional como não-
funcional.
O sistema demonstrável então desenvolve-se para ficar usável acrescentando
mais funcionalidade e fixando defeitos. Uma vez que o sistema realizou o estado
usável, tem todas as qualidades desejadas de um sistema operacional. Se
implementar um montante suficiente das exigências, se fornecer o valor de negócios
suficiente, e se houver um momento propício apropriado do seu desdobramento,
então pode considerar-se que está pronto para o uso operacional.
Embora, um sistema usável tenha o potencial para ser um sistema
operacional, ainda há alguns passos essenciais a executar-se antes que esteja
pronto. O sistema tem de aceitar-se para o uso pelos depositários de dinheiro de
apostas, e tem de preparar-se para o desdobramento no ambiente vivo. Neste
estado, o sistema complementa-se tipicamente com orientação de instalação,
materiais de treino e treinamento real da operação de sistema.
O sistema faz-se operacional quando se instala para o verdadeiro uso dentro
do ambiente vivo. Está usando-se agora para gerar o valor e fornece o benefício aos
seus depositários de dinheiro de apostas.
Mesmo depois que o sistema de software se fez operacional, o trabalho de
desenvolvimento ainda pode continuar. Isto pode ser como parte dos planos da
entrega incremental do sistema ou, como é mais comum, uma resposta a defeitos e
problemas que ocorrem durante o desdobramento e a operação do sistema. O
suporte e a manutenção continuam até que o sistema de software se retire e o seu
suporte retira-se. Isto pode por uma geração posterior, o sistema de software já não
tem mais longo tem qualquer usuário ou, não forma sentido negociar para continuar
apoiando-o.
Durante o desenvolvimento de um lançamento principal muitos lançamentos
menores muitas vezes produzem-se. Por exemplo, muitas equipes que usam uma
aproximação iterativa produzem um novo lançamento durante cada iteração
enquanto guardam o seu sistema de software continuamente em um usável, e por

42
isso potencialmente afirmar. Então são os representantes de depositário de dinheiro
de apostas que decidem se está pronto para fazer-se operacional. Obviamente, esta
aproximação não sempre é possível, em particular se as modificações arquitetônicas
principais se necessitarem como estes muitas vezes dão o sistema inútil para um
período de tempo significante.
A compreensão dos estados atuais e desejados de um sistema de software
ajuda todo o mundo a entender quando um sistema está pronto, o que as espécies
de modificações podem fazer-se realisticamente ao sistema, e que espécies do
trabalho devem deixar-se a uma geração posterior do sistema de software verificar o
progresso do sistema de software para ajudar a avaliar o estado de um sistema de
software e o progresso que se faz em direção à sua operação bem-sucedida, os
seguintes itens de lista de conferência.
Figura XII – Sistema de Software
4.6 Espaços das atividades
A área problemática de solução contém seis espaços de atividade que
cobrem a captura das exigências e o desenvolvimento do sistema de software.
Estabeleça uma compreensão compartilhada do que o sistema se produzir o
que se deve fazer nos processos. Primeiramente criando um ciclo de vida para as
atividades

43
Figura XIII - Sistema de Software
 Padrões para alcanças um sistema completo. Entenda como o sistema gerará
o valor. Combine o que o sistema fará.
 Identifique modos específicos de usar e testar o sistema. Dirija o
desenvolvimento do sistema.
 Forme o sistema para que seja fácil desenvolver, modificar e manter, e possa
enfrentar atual e esperasse futuras exigências. Isto inclui o desenho total e
arquitetar do sistema a produzir sua construção.
4.7 Resumo da Palestra: Explanando o SEMAT
Dentro do contesto Ivar Jacobson destaca que o SEMAT veio para centralizar
a engenharia de software como o contexto de uma melhoria continua tanto na
indústria como em um gerenciamento dos processos de um projeto.
A engenharia do software passou por imensas mudanças para e ainda hoje
se descobre pretendendo alcançar todos as áreas de atuação utilizando as melhores
práticas. Porém, vamos explanar os fatos que aconteceram para criação do SEMAT

44
4.8 A crise do Software
Na década de 70 o desenvolvimento de software apresentava muitas
dificuldades frente ao rápido crescimento da demanda por software, da
complexidade dos problemas a serem resolvidos e da inexistência de técnicas
estabelecidas para desenvolvimento de sistemas que funcionassem adequadamente
ou pudessem ser validados. Este período ficou conhecido como crise do software.
A crise se manifestava de várias formas, entre elas: projetos estourando o
orçamento, projetos estourando o prazo, software de baixa qualidade, softwares que
muitas vezes não atingiam os requisitos.
Figura XIV – A Crise do Software
Segundo Friedrich Ludwig Bauer, "Engenharia de Software é a criação e a
utilização de sólidos princípios de engenharia a fim de obter software de maneira
econômica, que seja confiável e que trabalhe eficientemente em máquinas reais". O
próprio significado de engenharia já traz os conceitos de criação, construção,
análise, desenvolvimento e manutenção.
O termo Engenharia de Software foi criado na década de 1960 e utilizado
oficialmente em 1968 na NATO Conferencie on Software Engineering (Conferência
sobre Engenharia de Software da OTAN). Sua criação surgiu numa tentativa de
contornar a crise do software e dar um tratamento de engenharia (mais sistemático e
controlado) ao desenvolvimento de sistemas de software complexos, visando
melhorar a qualidade dos produtos de software e aumentar a produtividade no

45
processo de desenvolvimento. Um sistema de software complexo se caracteriza por
um conjunto de componentes abstratos de software (estruturas de dados e
algoritmos) encapsulados na forma de procedimentos, funções, módulos, objetos ou
agentes e interconectados entre si, compondo a arquitetura do software, que
deverão ser executados em sistemas computacionais.
Figura XV – A Crise do Software
Os fundamentos científicos envolvem o uso de modelos abstratos e precisos
que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de
software, avaliando e garantindo suas qualidades. Além disto, deve oferecer
mecanismos para se planejar e gerenciar o processo de desenvolvimento. Empresas
desenvolvedoras de software passaram a empregar esses conceitos sobretudo para
orientar suas áreas de desenvolvimento, muitas delas organizadas sob a forma de
Fábrica de Software.
Figura XVI – A Crise do Software

46
Além de crescer a necessidade da utilização dos softwares existiam
problemas com a falta de profissionais para executar as tarefas. Como parte de
mais problemas custos acima do requerido nos projetos.
O desempenho baixo tanto da equipe como também do patrocinador do
projeto eram mais motivos para agravar o problema. Os programadores viram
como uma alternativa tentar equiparar o processo de gerenciamento de produção
para fabricação dos softwares. São problemas que até mesmo nos dias de hoje se
encontram em grandes companhias para resolver a questão da produção.
4.9 Respostas para crise do software
Figura XVIIX – A Crise do Software
Para melhoria da crise foi feito uma conferência prezando trazer inovações
para engenharia de software. Em primeira instância foi colocado as modificações
que poderiam ser executadas para organização ou mesmo aplicação de um
Figura XXIX – A Crise do Software

47
sistema conseguisse uma resposta rápida. Foi elaborado um manifesto para
melhoria dos métodos ágeis puderem gerar uma resposta ao problema. Existe
ainda nos dias de hoje a famosa busca por uma bala de prata para solução da
engenharia de software.
Contudo acabou gerando uma guerra entra os métodos onde precisava ser
implantado um padrão. Na década de 60, a indústria do software já era consolidada.
Tanto que já estava em crise.
Em 1968, foi reconhecido oficialmente a existência da chamada Crise do
Software. Foi observado que cerca de 80% de projetos de software não eram
entregues. Dos 90% que foram concluídos, terminaram 150 a 400% acima do
orçamento e do prazo estipulado. Além de que eram entregues repletos de falhas e
funcionalidades desnecessárias.
O objetivo era discutir e mostrar possíveis soluções para a Crise. A
conferência foi um marco na indústria, pois é conhecida como o nascimento da
disciplina de Engenharia de Software.
A Engenharia de Software surgiu com o objetivo de atender as necessidades
dos projetos da OTAN, que eram projetos de grandes sistemas de defesa. Bem
diferentes de sistemas comerciais. No entanto, a indústria adotou a Engenharia de
Software com o objetivo de atender o mesmo nível de previsibilidade de outros
ramos da engenharia.
A Engenharia de software deu início a uma gama de processos de
desenvolvimento. Dentre eles estava o famoso Modelo Cascata. E que, por sua
vez, deu origem ao falido modelo de fábricas de software. O processo cascata
organiza os projetos em etapas realizadas sequencialmente.
Esse modelo faz com que o processo de desenvolvimento se assemelhe a
uma linha de produção do Modelo T. Como resultado é gerado uma série de
artefatos, representados através de pilhas de documentações. Gerando desperdício
através de formalismos e burocracia, além de gerar conflitos de interesses entre
equipe de desenvolvimento e clientes e potencializar conflitos dentro do próprio time.

48
Tal processo é incapaz de levar o fator humano em consideração. Assim, a
Engenharia de software, contribuiu para o agravamento da Crise do Software.
Figura XVIII –A Crise do Software
Depois da guerra dos métodos acabou que todos os processos foram
orientados para melhoria e cada projeto foi utilizando inúmeros meios para melhorar
suas respostas para engenharia de software.
Após muito tempo pesquisando foi visto que ainda hoje a engenharia de
software se aplica a persuadir nos mesmos erros que antigamente. Pois ainda
precisa de soluções mais maduras para concretizaram de um padrão. Entre todos os
modelos de ciclo de vida ou mesmo metodologias ainda precisamos melhorar a
conhecimento entre os profissionais e se certificar como podemos melhorar esse
conceito.
Nos dias de hoje ainda está sendo procurado um novo meio ou mesmo
elaborar um integra para melhoria da engenharia de software talvez o SEMAT
consiga aplicar essa concretização para engenharia.

49
5 RESPONSABILIDADE
Redefinição da engenharia de software baseada em uma teoria sólida, princípios
comprovados e melhores práticas que:
•Inclua um Kernel de elementos amplamente definidos, extensível para usos
específicos;
•aborde tanto as questões de tecnologia quanto de pessoas;
•seja suportada pela indústria, academia, pesquisadores e usuários;
•tenha suporte e extensões em face da mudança dos requisitos e da tecnologia.
Na iniciativa SEMAT, a ideia central é a do Kernel. Esse Kernel deve possuir a
descrição dos elementos que são essenciais a todos os esforços de engenharia de
software.
•Alphas ou Alfas: São as representações das coisas essenciais a serem usadas no
trabalho;
•Espaços de atividade (Activity Spaces): representações das coisas essenciais a
fazer;
•Competências (Competencies): As capacidades essenciais necessárias,
habilidades especificas necessárias para seu esforço de software que devem ser
definidas ou identificadas por equipes individuais.
Segundo o SEMAT (2012), o Kernel é organizado em três áreas de interesse,
cada uma representando um expecto especifico da engenharia de software, como
pode ser visto na figura abaixo. São elas:
5.1 Cliente:
Contém tudo para entender a utilização real e a exploração do sistema de software a
ser produzido;

50
5.2 Solução:
Contém tudo para fazer a especificação e o desenvolvimento do sistema de
software;
5.3 Esforço:
Contém tudo para entender a equipe, e de qual maneira as pessoas executam seu
trabalho.
Figura XXXII – Cliente, Solução, Esforço
As três áreas de interesse (traduzido de SEMAT, 2012)
Na solução de área de preocupação a equipe tem que desenvolver uma solução
adequada para explorar a oportunidade e satisfazer as partes interessadas:
• compreender os requisitos: Estabelecer um entendimento comum de que o sistema
a ser produzido deve fazer.
•moldar o sistema: moldar o sistema de modo que é fácil de desenvolver, alternar e
manter, e pode lidar com demandas atuais e futuras esperadas. Isso inclui a
concepção global de que o sistema seja produzido;
•Implementação do Sistema: Construir um sistema através da implementação, teste
e integração de um ou mais elementos do sistema. Isso inclui correção de erros e
testes de unidade;

51
•Teste do Sistema: Verificar se o sistema produzido atende aos requisitos das partes
interessadas;
•Implantar o Sistema: Utilizar o sistema testado e torna-lo disponível para uso fora
da equipe de desenvolvimento;
•Operar o Sistema: Apoiar o uso do sistema de software no ambiente corporativo;
No esforço área de preocupação a equipe tem que ser definida para que possa dar
continuidade ao trabalho:
•preparar-se para executar o trabalho: configurar a equipe e seu ambiente de
trabalho. Compreender e comprometer-se a concluir o trabalho;
•coordenar a atividade: Coordenar e dirigir o trabalho da equipe. Isso inclui todo
trabalho em curso e os planejados, adicionando os recursos adicionais necessários
para completar a formação da equipe.
•apoiar a equipe: ajudar os membros da equipe a se ajudarem, colaborar e melhorar
sua forma de trabalhar;
•Acompanhamento do progresso: medir e avaliar o progresso feito pela equipe.
A área do esforço contém tudo o que está relacionado com a equipe, e da maneira
com que ela se relaciona com o seu trabalho. A engenharia de software é um
esforço significativo que normalmente leva várias semanas para ser concluído, afeta
muito os envolvidos (Stakeholders) e envolve uma equipe de desenvolvimento (ao
invés de um único desenvolvedor). Qualquer método prático deve descrever um
conjunto de práticas para planejar, conduzir e monitorar os esforços da equipe.
Engenharia de software é um esporte de equipe envolvendo a aplicação de
colaboração de muitas competências e habilidades diferentes. A eficácia de uma
equipe tem um efeito profundo sobre o sucesso de qualquer empreendimento de
engenharia de software. Para alcançar alta performance os membros da equipe
devem refletir sobre quão bem eles trabalham juntos, e relacionar com o seu
potencial e eficácia para realização da sua missão. Equipes evoluem durante seu
tempo juntos e progridem através de várias alterações de estado.

52
5.4 ESFORÇO (Endeavor)
Figura XIX- Esforço (Endeavor)
Estados dos Alphas do Kernel (traduzido de Jacobson et al., 2012)
Na área de interesse do esforço, a equipe deve ser formada e executar o
trabalho de acordo com o modo de trabalho:
5.4.1 •preparar-se para fazer o trabalho:
Montar a equipe e seu ambiente de trabalho. Compreender e comprometer-se com
a conclusão do trabalho;
5.4.2 •coordenar atividade:
Coordenar e dirigir o trabalho da equipe. Isso inclui todo o planejamento em curso e
replanejamento do trabalho, e adicionar os recursos necessários para completar a
formação da equipe;
5.4.3 •apoiar a equipe:
Ajudar os membros da equipe a se ajudarem mutualmente, colaborar e melhorar o
seu modo de trabalho;

53
5.4.4 •acompanhar o progresso:
Medir e avaliar os progressos realizados pela equipe;
5.4.5 •parar o trabalho:
Encerrar o esforço de engenharia de software e entregar as responsabilidades da
equipe.
Contém tudo para que se possa entender a equipe, e de qual maneira devem
executar seu trabalho.
Área que se preocupa como time, sua maneira de trabalhar e com o trabalho a ser
feito.
•Trabalho: As atividades envolvendo esforço (mental ou físico) com objetivo de
alcançar o objetivo ou atingir um resultado;
•Equipe (Time): O grupo de pessoas engajadas no desenvolvimento, suporte ou
manutenção, distribuição e suporte de um sistema de software específico e gerência
do projeto;
•Maneira de trabalhar (Modo de Trabalho): O conjunto de práticas e ferramentas
utilizadas por uma equipe para orientar e apoiar o seu trabalho.
Cada um desses Alphas possuem um estado que será determinado pela
equipe, e utiliza a técnica denominada Progress Poker. Esse método foi criado para
ser rápido de ser executado e prover valiosa informação sobre o projeto de uma
forma geral. O objetivo é que a equipe possa avaliar cada Alpha, o estado que os
mesmos possuem e possam entrar em um consenso da situação atual naquele
quesito.
É importante avaliar os itens que não foram atendidos porque são eles os pontos a
serem atacados para a melhoria do processo.
•justificativa – adoção da pratica:

54
As equipes precisam melhorar sua forma de trabalhar através da adoção e
adaptação das práticas individuais, mesmo equipes menores.
•progredindo adoção de práticas:
Adoção pratica passa por uma série de estados que são selecionados e integrados
para que se possa ter êxito no trabalho. Esses estados focam na progressão e
adoção da pratica. São integrados com outras ferramentas e colocados em prática.
Com objetivo principal de que as equipes possam concluir seus trabalhos em êxito.
A adoção das práticas recomendadas impulsiona o progresso da forma de trabalhar.
Essa adoção das práticas associadas faz com que as equipes estejam alinhadas e
organizadas de forma que o trabalho seja concluído com sucesso.
O Kernel ainda fornece um conjunto de espaços de atividade que complementam os
alfas ao prover uma visão baseada em atividades de engenharia de software, como
pode ser visto na figura abaixo:
Figura XX - Esforço
Espaços de atividade do Kernel (traduzido de SEMAT, 2012)

55
5.5 Alfas (Alphas)
De acordo com SEMAT (2012a), os alfas do Kernel (conforme figura abaixo):
•capturam os conceitos chave envolvidos na engenharia de software;
•permitem avaliar e monitorar o progresso e a saúde de qualquer esforço de
engenharia de software;
•fornecem a base comum para a definição de métodos e práticas de engenharia de
software.
Figura XXI - Esofrço
Alphas do Kernel (Traduzido de SEMAT, 2012)
5.6 5W2H
Trata-se de uma ferramenta de gestão, e basicamente é um Check list de
determinadas atividades que necessitam ser desenvolvidas da forma mais clara
possível pelos colaboradores da empresa. Funciona com o mapeamento das
atividades, onde ficará estabelecido o que vai ser feito, quem vai fazer o quê, qual o

56
período de tempo, em qual área da empresa e todos os motivos da qual essa
atividade deverá ser feita. Em um segundo momento deve-se figurar nessa tabela
como será feita essa atividade e quanto vai custar aos cofres da empresa tal
processo.
Essa ferramenta é extremamente útil para as empresas, pois elimina completamente
qualquer dúvida sobre determinados processos ou mesmo sua atividade. Em um
ambiente como os corporativos aonde necessitamos muita agilidade por
consequência da alta competitividade interna ou externa, é necessário que não haja
dúvidas nas diversas atividades desenvolvidas por seus colaboradores de áreas ou
setores diferentes, afinal, um erro na transmissão de informações pode acarretar
vários prejuízos a empresa, por isso é extremamente necessário a tais questões no
que diz respeito a “tomada de decisões”, e o 5W2H é totalmente eficaz.
Figura XXII – 5W2H
Essa ferramenta permite organizar ideias de maneira funcional e intuitiva por
meio da lista de verificações (Check list). É perfeito para elaboração de projetos,

57
controle de processos e gestão de qualidade, pois permite uma visão abrangente e
de fácil entendimento de todos os pontos e fases envolvidas.
Em um primeiro momento parece um pouco complexo, mais esse nome deve-
se as iniciais em inglês para cada uma das etapas que compõem, na verdade
tratam-se de perguntas válidas e extremamente importantes no que se diz respeito
ao processo empresarial ou plano de ação:
•What? (O que?)
•When? (Quando?)
•Who ? (Quem?)
•Where? (Onde?)
•Why? (Por que?)
•How? (Como?)
•How much? (Quanto custa?)
Figura XXIII – 5W2H

58
O 5H2H destaca-se de outras metodologias de gestão por ser uma
ferramenta de simples entendimento e execução, totalmente eficiente e completa, e
também muito dinâmica porque permite ajustes e alterações pontuais mesmo após o
plano de ação ter sido colocado em prática. Esse conceito do 5W2H pode ser
utilizado por qualquer pessoa com foco individual ou corporativo.
Como já citado a elaboração da planilha é muito simples. É necessário ter em
mente as causas do problema e fazer cada etapa de forma muito cuidadosa e
detalhada. E após o término da planilha vai ficar algo como na figura abaixo.
Lembrando que a ordem das colunas não irá afetar o andamento da planilha desde
que WHAT (O que?) Esteja em primeiro lugar.
Figura XXIV – 5W2H
Podemos sim dizer que o 5W2H trata-se de uma ferramenta administrativa
que pode ser utilizado em qualquer ambiente corporativo. Sua análise tem a
finalidade de auxiliar na elaboração de planos de ação, como um Check-list que
pode aumentar a clareza do colaborador sobre suas atividades. Basicamente
podemos entender que o 5W2H explora as principais questões que envolvem um
trabalho, garantindo uma visão de ampla, abrangente e examinada da mesma.
Existem várias formas de aplicação para esta ferramenta. Pode tanto ser
utilizada sozinha para colocar em pratica uma decisão simples na empresa, como
também em conjunto com outras ferramentas de gestão e/ou administrativas como
por exemplo o próprio SEMAT ou SWOT. É totalmente prática e de fácil

59
entendimento e essas características básicas são suas principais vantagens,
ajudando os administradores e gestores à terem um maior controle sobre as
atividades que desempenham.
Podemos definir o 5W2H como uma ferramenta que é utilizada quando uma
empresa deseja que suas tarefas sejam executadas com mais agilidade e eficiência,
aumentando assim sua produtividade como um todo. Para entendermos melhor veja
abaixo alguns exemplos de atividades aonde a ferramenta 5W2H pode ser utilizada:
•fazer o planejamento da redução de custos da empresa;
•Gerenciamento de projetos em TI;
•Planejamento e manutenção de infraestrutura;
•Aumento da lucratividade da empresa;
•Gerenciamento de equipes de TI.
Como já citamos anteriormente para colocar em pratica a ferramenta é
necessário elaborar uma planilha no Excel ou mesmo em outro programa da
preferência do usuário. Abaixo segue mais um exemplo de uma planilha aonde é
utilizada a ferramenta 5W2H:
Figura XXV – 5W2H

60
Podemos finalizar dizendo que a ferramenta 5W2H é muito simples e a
planilha funciona de forma bastante intuitiva. Pode ser iniciada a qualquer momento
na construção do plano de ação.

61
6 BIBLIOGRAFIA
Site: Sobre Administração-http://www.sobreadministracao.com/o-que-e-o-5w2h-e-
como-ele-e-utilizado/19/05/2016 as 18:10
Site: Portal Administração-http://www.portal-administracao.com/2014/12/5w2h-o-que-
e-e-como-utilizar.html23/05/2016 as 18:45
Referencias: https://www.ivarjacobson.com/software-engineering-method-and-theory
http://semat.org/

SEMAT

Mais conteúdo relacionado

Destaque (16)

Semelhante a SEMAT (20)

Último (12)

SEMAT