Compre na Amazon, Submarino ou UmLivro
Veja também os cursos de extensão a distância Engenharia de Software Moderna (48 horas) e Teste de Software (20 horas), oferecidos pelo DCC/ICEX/UFMG.
O objetivo deste artigo é responder perguntas sobre temas relacionados com requisitos de software, isto é, sobre o Capítulo 3 do livro.
Segue a lista atual de perguntas:
No contexto de Engenharia de Software, persona é uma técnica usada
para aproximar os desenvolvedores de um sistema de seus usuários finais.
Suponha o sistema de bibliotecas que usamos no Capítulo
3 do livro. Nele, assumimos três papéis de usuários: usuário típico,
professor e funcionário. A técnica de personas propõe representar esses
papéis de uma forma mais humana
por meio de nomes e de uma breve
descrição. Por exemplo, podemos criar a seguinte persona:
Mariana: Estudante do segundo ano de Sistemas de Informação, 20 anos, cursa normalmente cinco disciplinas em cada semestre. Usa a biblioteca para estudar e para acessar os principais livros dessas disciplinas. Durante as férias, gosta de realizar empréstimos de livros de literatura.
Uma persona é um usuário fictício e hipotético. Ou seja, no sistema de bibliotecas não existe necessariamente um usuário chamado Mariana. A descrição de uma persona é também acompanhada de uma foto. Normalmente, define-se um número pequeno de personas para um sistema. Por exemplo, menos de cinco ou seis personas. E então as histórias de usuários são pensadas e escritas para cada uma das personas definidas.
Como dissemos, o principal objetivo da técnica de personas é criar uma relação empática entre os desenvolvedores de um sistema e os seus usuários. Com isso, pretende-se evitar que os desenvolvedores projetem o sistema pensando neles mesmos, isto é, apenas com as características que eles julgam importantes, caso tivessem que usar o sistema.
Para definição das personas podem ser realizadas pesquisas com os potenciais usuários do sistema, por exemplo, por meio de questionários. Além de perguntas tradicionais (nome, sexo, idade, etc.) é importante que esses questionários revelem também os hábitos e comportamentos dos usuários, principalmente aqueles relacionados com o sistema que se pretende implementar. A partir das respostas dos questionários, deve-se agrupar usuários semelhantes e então criar uma persona para cada grupo.
Antes de concluir, é importante mencionar que personas são usadas também em outras áreas, como projeto de interface com o usuário, marketing, vendas, etc.
Dogfooding é uma outra técnica usada para aproximar desenvolvedores
dos produtos de software que eles desenvolvem. No entanto, no caso de
dogfooding, a aproximação é total: ou seja, além de desenvolver um
sistema, desenvolvedores devem também usá-lo com frequência. O nome tem
origem em uma frase comum em inglês: comer a mesma comida do seu
cachorro
(eat you own dog food).
O objetivo é simples: fazer com os que os desenvolvedores experimentem os benefícios e, principalmente, os problemas e dificuldades relacionados com o uso de um sistema.
Dogfooding é adotado pela maioria das grandes empresas de tecnologia.
Por exemplo, no Facebook, os engenheiros também são usuários da rede
social, portanto, eles têm conhecimento em primeira mão do que o sistema
faz e de quais serviços ele oferece.
(link).
Como um segundo exemplo, veja o seguinte tweet do CEO do Google:
Have been dogfooding the new @Gmail for a while now - very excited for this new redesign! https://t.co/Z7xcHwZTjO
— Sundar Pichai (@sundarpichai) April 25, 2018
No entanto, dogfooding é mais complicado no caso de sistemas para domínios de negócio que requerem usuários especializados. Por exemplo, um sistema para cálculo e geração de apólices de seguros para navios. Mesmo que um desenvolvedor implemente uma parte desse sistema, ele pode não conseguir usá-lo tal como um analista de seguros navais.
Se ela for realizada após uma reclamação de usuários do sistema, trata-se de uma manutenção corretiva. Se ela for realizada para evitar reclamações futuras sobre uma possível lentidão do sistema, trata-se de uma manutenção preventiva. Porém, se ela for realizada para adaptar o sistema a uma demanda externa (por exemplo, alguma regulamentação), trata-se de uma manutenção adaptativa.
Por exemplo, suponha que em um sistema para controle de bibliotecas tanto professores como alunos possam doar livros. Logo, podemos escrever essa história assim:
Como professor ou aluno, eu gostaria de doar livros para a biblioteca
Porém, se tivermos várias histórias que valem tanto para professores como para alunos, podemos também criar um novo papel no sistema: usuário, o qual pode ser tanto um professor como um aluno. Feito isso, podemos reescrever a história acima:
Como usuário, eu gostaria de doar livros para a biblioteca
Assim, os papeis professor e aluno ficarão reservados para histórias que são específicas e restritas aos mesmos.
Voltar para a página principal.