Mostrando postagens com marcador Engenharia de Software. Mostrar todas as postagens
Mostrando postagens com marcador Engenharia de Software. Mostrar todas as postagens

21 setembro, 2012

Levantamento de Requisitos - 5W2H

via imagens.tiespecialistas.com.br
Existem várias maneiras de se obter informações sobre um determinado requisito, principalmente para garantir que ele fique cada vez mais completo.



Uma dessas técnicas, conhecida como 5W2H, ajuda a construir de maneira simples as principais informações que um requisito de negócio/software precisa.


A sigla 5W2H vem do inglês, e significa:

What?
O que está atrapalhando seu negócio? O que acontece hoje? O que você gostaria que o sistema fizesse? O que deve ser obtido como produto final do sistema? O que restringe este requisito?

Who?
Quem irá usar o sistema? Quem irá aprovar os requisitos? Quem irá responder às dúvidas? Quem é afetado por este requisito?

When?
Quando os usuários precisarão ter acesso? Quando vocês poderá aprovar os requisitos? Quando poderemos testar? Quando poderemos realizar a entrega?

Why?
Por quê fazer desta maneira? Por quê é preciso fazer isso? Por quê priorizar agora? Por quê não agregar com este outro requisito?

Where?
Onde deverá ser exibido? Onde será desenvolvido? Onde será testado? Onde será acessado pelos usuários?

How?
Como o sistema irá responder? Como deve funcionar? Como deve ser exibido? Como deverá ser documentado? Como você usa? Como você gostaria de usar?

How much?
Quanto tempo temos para desenvolver? Quanto tempo o time do projeto estimou? Quantas pessoas serão necessárias no projeto? Quantas pessoas irão de fato utilizar o sistema?

Gostou? Agora é só tentar aplicar na próxima análise. =)

Até a próxima!

28 março, 2012

Gestão do Conhecimento

"Vejamos, Protágoras! Mostre-me seu pensamento, e diga-me qual é sua atitude com respeito ao conhecimento: sua opinião é semelhante àquela da maioria, ou difere-se ela da maioria?" [Platão. Protágoras (1950, 131bc;132d)]



Ontem fui à uma palestra do GUGC promovida pela SUCESU, onde o assunto "A gestão do Conhecimento nas Organizações" foi muito bem apresentado por Beatriz Benezra.

Gestão do Conhecimento é um assunto que vem se destacando em diversos setores, mas principalmente no setor de Tecnologia da Informação, onde a necessidade de se disseminar e manter o conhecimento dentro das empresas está cada vez mais em evidência.

Nessa palestra, Beatriz destacou que a gestão do Conhecimento precisa fazer parte da estratégia da empresa, e que deve contar com o apoio da alta diretoria para ter sucesso. 

via 3.bp.blogspot.com
Contudo, uma organização sozinha não existe. Os indivíduos que fazem parte dessa organização são peças fundamentais para que se consiga extrair e divulgar o conhecimento. As pessoas motivadas à compartilhar seu conhecimento e à aprender com seus colegas são os responsáveis em colocar toda teoria em prática.

E também existe uma vasta gama de ferramentas wiki que facilitam toda a parte de armazenamento e acessibilidade às informações.

E então? Quais são as práticas de Gestão do Conhecimento que já existem na sua empresa? Essas práticas são gerenciadas ou controladas de alguma maneira?

Até a próxima!

Women on tech

Como todos sabem, a área de TI está em plena ascensão e sendo muito valorizada. Com isso a procura por interessados em tecnologia e amantes de desenvolvimento vem crescendo a cada dia. 

Mas mesmo com toda a procura existente, a quantidade de mulheres interessadas ainda é muito pequena. E embora tenhamos que enfrentar muitas barreiras na vida profissional, existem exemplos muito fortes de mulheres que atingiram o sucesso atuando nessa área. 

A ideia deste texto não é ser um texto feminista, mas apenas constatar uma realidade que é percebida em todas as empresas de TI. ;)

Encontrei este infográfico na Women on Business que mostra como as mulheres estão distribuídas no setor de Tecnologia da Informação.

Enjoy it!

Women in Technology
Like this infographic? Get more business technology news from IT Manager Daily.

13 dezembro, 2011

Classificação de Requisitos

O BABOK® Guide classifica de uma maneira muito interessante os tipos de requisitos à que se refere ao longo do livro. Vale a pena dar uma conferida nesta prévia:


  • Requisitos do Negócio são metas de mais alto nível, objetivos ou necessidades da organização. Descrevem as razões pelas quais um projeto foi iniciado, os objetivos que o projeto vai atingir e as métricas que serão utilizadas para medir o seu sucesso.
  • Requisitos das partes interessadas (steakholders) são necessidades e interações de uma parte interessada em particular ou grupo de partes interessadas. 
  • Requisitos da solução descrevem as características de uma solução que atende aos requisitos do negócio e aos requisitos das partes interessadas. São frequentemente divididos em duas subcategorias:
    • Requisitos Funcionais descrevem o comportamento e a informação que a solução irá gerenciar, bem como as capacidades que o sistema será capaz de executar em termos de comportamentos e operações – ações ou respostas especificas de aplicativos de tecnologia da informação.
    • Requisitos Não-Funcionais capturam condições que não se relacionam diretamente ao comportamento ou funcionalidade da solução, mas descrevem condições ambientais sob as quais a solução deve permanecer efetiva, ou qualidades que os sistemas precisam possuir.
  • Requisitos de transição descrevem capacidades que a solução deve possuir com o objetivo de facilitar a transição do estado atual da organização para um estado futuro desejado, mas que não serão mais necessárias uma vez concluída a transição.
Bacana né? Estou aprendendo muito com este livro.

Até a próxima!

19 outubro, 2011

Princípios do Manifesto Ágil



Seguindo no tema da agilidade, vamos conversar sobre os princípios do Manifesto Ágil.

1. A maior prioridade é satisfazer o cliente, através de entregas antecipadas e contínuas de software que tenha valor. 
Aqui, o valor significa valor estratégico, valor de negócio, valor emocional, valor que de fato faça a diferença na vida do cliente. 

2. Aceitar as mudanças de requisitos, mesmo tardiamente no desenvolvimento. Processos ágeis aproveitam as mudanças para agregar vantagem competitiva ao cliente. 
Aceitar as mudanças, não quer dizer atropelar tudo que foi acordado para a entrega e criar um monstro. Quer dizer aceitar que o pacote não está fechado, e que o produto final pode ir mudando e sendo construído ao longo do caminho. 

3. Entregar frequentemente software que funcione, a cada duas semanas ou no máximo a cada dois meses, preferindo a menor escala de tempo. 
Claro que existem entregas mais demoradas que outras, mas a ideia é que sejam entregas constantes, onde o software vá evoluindo sob os olhos do cliente, e ele possa, já em um curto espaço de tempo, poder trabalhar com produto. 

4. Área de Negócio e Desenvolvimento precisam trabalhar juntos diariamente ao longo do projeto. 
Aqui fica clara a necessidade de colaboração que já foi comentada no post anterior. Quando o time está interagindo, discutindo soluções e ideias para o projeto, o envolvimento de todos aumenta, bem como o comprometimento. 

5. Construir projetos ao redor de pessoas motivadas, oferecendo o ambiente e o suporte que elas precisam, e confiar que essas pessoas farão seu trabalho. 
Confiança. Se as pessoas confiam no que estão fazendo, se confiam na organização em que trabalham, e também se a organização confia nas pessoas com que trabalha, a motivação vem ao natural, e pessoas motivadas sentem prazer em realizar suas tarefas. 

6. O mais eficiente e eficaz método de transmissão de informação para e dentro de um time de desenvolvimento é a conversa cara-a-cara. 
As vezes não é possível que o time esteja no mesmo local físico, e hoje em dia isso é muito normal, mas a conversa franca e direta sempre foi e sempre será o melhor caminho para se atingir qualquer objetivo. 

7. Software funcionando é a principal medida de sucesso. 
Essa é bem clara e não tem como ser diferente. 

8. Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. 
É não deixar a peteca cair. E não é só o ritmo de entregas de projetos, é também o ritmo da motivação, o ritmo do humor, o ritmo de horário, enfim, é manter a equipe alinhada com a própria equipe. 

9. Atenção contínua para com a excelência técnica e bom design aumenta a agilidade. 
Claro, melhorando a capacidade técnica da equipe, o produto também melhora, e quanto mais alinhados estiverem equipe técnica e a tecnologia do produto, agilidade e sucesso estarão garantidos. 

10. Simplicidade _ a arte de aumentar a lista de trabalho a não ser realizado _ é essencial. 
Eliminar o que não agrega valor ao negócio, eliminar complexidades desnecessárias, e por aí vai. É um trabalho que exige maturidade do time e do cliente, para conseguir ter o discernimento do que é e do que não é importante para o produto. 

11. As melhores arquiteturas, requisitos e designs vem de times auto-organizáveis. 
Com certeza! Times que já conseguem se organizar sem a necessidade de um líder que delegue tarefas, precisam (além de maturidade) um conhecimento de negócio muito grande. Todos precisam estar à par do projeto como um todo, para que possam tomar decisões e sugerir alternativas. 

12. Entre intervalos regulares o time deve refletir sobre como se tornar mais efetivo, e então sintonizar e ajustar seu comportamento de acordo. 
A questão de revisar as atividades praticadas, o que deu certo, o que não deu, o que pode ser melhorado, o que deve ser eliminado, tudo isso faz parte dessa reflexão. Novamente, a questão da maturidade do time se torna essencial para o processo. 

Bom, estes foram os meus comentários sobre cada um dos doze princípios, mas são coisas que eu acredito. Fique à vontade para dar sua opinião também. =)

O Manifesto Ágil

Muito se fala sobre Metodologias Ágeis, agilidade nos processos, agilidade no desenvolvimento de software... mas mesmo dentro de equipes "ágeis" pouco se conversa sobre o Manifesto Ágil.

Acabou que as pessoas estão esquecendo da essência da agilidade, e focando em entregas rápidas (e cada vez mais rápidas), e que não valorizam de fato a ideia que move o Manifesto.

Traduzindo as palavras do Agile Manifesto:

"Estamos descobrindo melhores formas de desenvolver software fazendo e ajudando outros a fazer isso. Ao longo deste trabalho passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas;
Software funcionando mais que documentação abrangente;
Colaboração com o cliente mais que negociação contratual;
Responder à mudança mais que seguir um plano. "

O que significa, que mesmo que haja valor nos itens da direita, valorizamos ainda mais os itens da esquerda."


E acredito que é aqui, logo no começo da coisa que ela é desvirtuada. Quando o manifesto diz que preza isso "mais que" aquilo, não quer dizer que o "mais que" signifique "ao invés de".

Em diversas palestras e seminários que já fui, e também em muito material que o nobre Google me ajuda a encontrar, esse ponto de discussão sempre aparece.

Agilidade não significa deixar de documentar, abandonar os processos de desenvolvimento e pensar em prazos cada vez menores. Pelo contrário! É ter que rever o que está gerando desperdício, eliminar suas causas, e pensar em melhorar as capacidades técnicas para que se consiga entregar um produto que de fato satisfaça as necessidades do cliente, e somente então realizar entregas que tenham valor de negócio. Basicamente a ideia é colaboração, entre a equipe, entre a organização, e também com o cliente.

São somente 12 os princípios que movem o Manifesto Ágil. Simples, diretos e deveriam ser o foco até de quem não concorda em "ser ágil". No próximo post vou comentar sobre eles.

29 junho, 2011

Trabalhando com Engenharia de Software

Bom, estava faltando um post para falar sobre Engenharia de Software. =) 

Segundo a Wikipédia, "Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade."



Resumidamente, é atuar em qualquer especialidade dentro de um projeto de desenvolvimento de software (corrijam-me se discordarem). Então, uma vez que você esteja interessado em atuar como Engenheiro de Software, você deve ter em mente "o que você quer ser quando crescer", e trabalhar para melhorar suas qualificações. Eis alguns exemplos de profissões ligadas à esta área:

Desenvolvedor de Software (Programador), Analista de Sistemas, Analista de Negócios, Analista de Testes, Testador, Arquiteto de Software, DBA (Database Administrator), Gerente de Projetos, Suporte, e por ai vai. 

E ainda, dentro de cada uma destas profissões, existem diversos seguimentos a se tomar, e que cada vez mais exigem especialização, por exemplo:

Um desenvolvedor pode ser especialista em uma ou mais linguagens de programação (Java, .Net, PHP, etc), um Analista de Sistemas também pode se especializar em uma determinada linguagem, um Testador deve conhecer diversas técnicas de Testes de software, desde a manual até a automatizada, tendo domínio sobre diversas ferramentas que o auxiliem. Enfim, os caminhos são diversos, e ainda trataremos de cada um deles com mais calma no blog.

O bacana, é que se você resolver trocar de área, você não perde seu conhecimento, pelo contrário!! Tudo o que se aprende em uma determinada área de conhecimento é perfeitamente aplicável nas demais, seja teoricamente, seja auxiliando em uma resolução de problema, ou em uma identificação de bug.

Sem falar que a Engenharia de Software está em constante expansão, e ainda faltam profissionais qualificados no mercado. Ah! E não basta ser bom somente em tecnologia não... sem inglês hoje, muitas portas acabam se fechando. O mercado internacional está de olho nos profissionais do Brasil, então aproveite! #ficaadica