|
Escrito por Rodrigo Guiotti
|
|
A ES é toda uma área do conhecimento da computação. A intenção é conseguir especificar, desenvolver e manter software com a melhor relação de custo e qualidade possível com todas as técnicas que temos disponíveis, se focando em aspectos práticos. Por isso ela engloba todas estas partes do software:
- Requisitos;
- Design;
- Implementação;
- Testes;
- Manutenção;
- Gerência de configuração;
- Gerência de engenharia;
- Processos de engenharia;
- Ferramentas e métodos de engenharia;
- Qualidade;
Para nos ajudar a entender tudo isso, vamos começar com a definição de ciclo de vida do produto (software). A idéia destes modelos é detalhar como deve ser o passo a passo do desenvolvimento do software até que se tenha o produto final.
No processo em Cascata temos um processo linear, na base de muitos processos de ciclo de vida ainda hoje. Completa-se a engenharia de requisitos para só depois fazer o design do software. E só depois deste é que se inicia a implementação e os testes. Depois se testa o sistema e finalmente se entra na etapa de manutenção do software. Costuma funcionar melhor para equipes tecnicamente mais fracas e minimiza o tempo de planejamento. Porém é mais inflexível e só produz um software realmente no final do processo.
O modelo em espiral tenta dar maior importância a duas partes deste ciclo: a análise de risco e a prototipagem. Procura-se definir e especificar partes menores, produzindo protótipos e cada iteração pode voltar a qualquer etapa (mais comum de se voltar ao desenvolvimento ou especificação) e gerar outro protótipo até que se chegue ao final do produto. E este acaba sendo um modelo complexo de se planejar e utilizar, mas pode-se diminuir muito o risco dos projetos. Uma variação parecida é a Prototipagem Evolucionária, que também faz ciclos de protótipos, mas não chega a fazer um planejamento geral porque se planeja apenas versões curtas, o que é muito útil quando os requisitos ainda não estão bem definidos, mas tem a desvantagem de que é impossível de prever quanto tempo ou quantas iterações serão necessárias até o final do projeto.
Entre outros modelos utilizados estão: Codificação e Correção, Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools e Off-the-Shelf.
Quanto as metodologias de desenvolvimento, também temos diversas delas para escolher. O RUP (Rational Unified Process) foi criado por uma empresa adquirida pela IBM e virou IRUP (IBM RUP). Eles fornecem técnicas de desenvolvimento de software visando o aumento de produtividade. Ele faz uso da Orientação a Objetos e da linguagem UML para definir e ilustrar os seus processos. Ele divide o processo em quatro fases essenciais:
Concepção: ênfase no escopo do sistema;
Elaboração: ênfase na arquitetura;
Construção: ênfase no desenvolvimento;
Transição: ênfase na implantação.
É um modelo considerado pesado, mas que é muito útil com um grande número de pessoas na equipe, no caso de projetos muito grandes. Mas é suficientemente simples para que possamos trabalhar com ele em processos menores.
De qualquer forma, muitas metodologias surgiram exatamente por esta razão, com o nome de métodos ágeis. Eles procuravam uma forma de se conseguir um resultado semelhante sem gerar tantos documentos durante o processo e procuram minimizar o risco com curtos períodos de desenvolvimento. No início a "programação extrema" causou muito reboliço com suas idéias de programação em pares e projeto contínuo e hoje em dia sofre críticas mesmo daqueles que acreditam nas metodologias ágeis, como depender de desenvolvedores muito bem preparados, falta de estrutura e documentação, requerer uma mudança cultural muito grande, etc. Mais recentemente a metodologia ágil que mais ouço falar é a Scrum que procura percorrer todo o processo de desenvolvimento de software em "sprints" curtos, geralmente de 15-30 dias, gerando versões funcionais de software regularmente.
Basicamente, no Scrum se faz um planejamento geral que gera a lista completa de requisitos de software (o que é chamado de "product backlog"). Então se faz reuniões periódicas chamadas de "Sprint Planning Meetings" onde se acorda o escopo do próximo "sprint", montando o "sprint backlog". Diariamente durante o sprint, se faz uma reunião rápida para verificar se o andamento do sprint está comprometido (Daily Scrum). No final do sprint, se faz uma apresentação as "clientes" da versão, mostrando as funcionalidades implementadas e as anomalias que foram encontradas, para atualizarem o "product backlog" e se prepararem para o novo "sprint". Também deve ser realizada uma reunião de "Sprint Restrospective" para darem feedback sobre o processo e melhorarem o que for possível para o próximo "sprint". Devem, então, acontecer tantos "sprints" quanto forem necessários para que o produto seja dado como concluído.
Ultimamente tenho começado a acreditar que esta metodologia funciona muito bem com o tipo de estrutura que temos aqui na empresa que trabalho e estou estudando mais a respeito para utilizarmos o que for possível/benéfico. |
|
Escrito por Rodrigo Guiotti
|
|
Já houve um tempo em que os usuários não entendiam a magia que acontecia por trás dos sistemas de software. Eles podiam não entender como se dava o desenvolvimento do software, não conseguem especificar muito bem o que desejam do software e era muito dificil desenvolver algo sem saber exatamente o que deveria ser feito.
Então muitas técnicas surgiram e atualmente as principais técnicas de análise de requisitos consistem em fazer entrevistas com os stakeholders para se melhorar todos os requisitos, procurando remover contradições, priorizar os requisitos, permitir que eles façam a escolha também do que pode ser feito com relação aos custos.
Em alguns casos, se for julgado necessário, é possível se fazer uma reunião com todos os interessados para se definir o escopo/custo geral, principalmente quando cada uma das partes deseja algo diferente e precisam entrar em um acordo.
A forma comum de se documentar isso é por meio de contrato. E mais do que a lista de funcionalidades que pode ser muito longa, se propõe uma lista de objetivos mensuráveis que deve ser alcançada com protótipos o quanto antes, para que estes objetivos maiores possam ser atingidos.
Outras duas técnicas muito conhecidas para ajudar a exemplificar e facilitar a visualisação deste software final são a prototipação e os casos de uso para ajudar na especificação dos requisitos.
O problema é que a prototipação acabava gerando uma certa ansiedade e sensação de que o software seria mais fácil de implementar do que seria de verdade e acabava gerando bastante desgaste. Também acabavasse recorrendo ao uso do protótipo como produto final, o que poderia implicar em diversos outros riscos e também poderiam passar muito tempo apenas desenvolvendo um protótipo que poderia ser descartado.
Quanto aos casos de uso, é uma técnica que acaba simplificando muito o software para mostrar um cenário de como seria as interações do usuário com o sistema. Mas como também não diz nada sobre a lógica que deve andar por trás do software, pode ser mal interpretado nas estimativas de prazos e esforço.
Agora que o sistema está melhor especificado, acabou-se, certo? Não, claro que não. É importante também se poder acompanhar com os stakeholders se o projeto está indo na direção correta, mais um ponto para metodologias ágeis de desenvolvimento, que acabam gerando mais versões que podem voltar a ser discutidas e revisadas... |
|
|
Processos de Desenvolvimento de Software |
 |
 |
 |
|
Escrito por Rodrigo Guiotti
|
|
Graças a uma norma da comunidade européia de desenvolvimento de software para equipamentos médicos (ANSI/AAMI/IEC 62304:2006) estamos revendo o processo de desenvolvimento de software na empresa que eu trabalho atualmente (Dixtal Biomédica).
Esta norma define um processo de desenvolvimento de software muito bem, inclusive teremos que levantar algumas evidências a mais do que fazemos atualmente pelo que estudei da norma. Com as etapas passando por planejamento, depois análise de requisitos, design de arquitetura, design detalhado, implementação, integração e verificações, validação do sistema e liberação. Todas estas etapas, necessariamente nesta ordem.
Mas a minha intenção ao escrever era de comparar este processo com outros padrões bem estabelecidos de desenvolvimento de software que existem por ai, como o CMMI e o MPS-BR. O CMMI tem níveis de maturidade que variam do nível 1 (menos maduro) até o 5 (mais maduro). Estes estágios ficam bem diferenciados assim:
- Realização – Estágio inicial;
- Gerenciado – Gerenciamento de requisitos, planejamento de projeto, monitoramento e controle de projeto, gerenciamento de fornecedores, medição e análise, garantia da qualidade do processo e do produto, gerenciamento de configuração;
- Definido – Desenvolvimento de requisitos, solução técnica, integração do produto, verificação e validação, foco no processo organizacional, definição do processo organizacional, treinamento organizacional, gerenciamento de riscos, gerenciamento integrado do projeto, análise da decisão e resolução;
- Quantitativamente – Gerenciamento quantitativo do projeto, performance do processo organizacional;
- Otimização – Análise causal e resolução, inovação organizacional e implantação.
Comparando estes níveis de maturidade com o nível mínimo de processo que a norma IEC 62304 exige, acredito que sairemos no fim deste ano com uma equivalência de processos muito próxima ao que é exigido no nível 3, porque não fazemos uso de métricas detalhadas e a parte quantitativa é um pouco pior que o exigido neste nível de maturidade realmente. Também acredito que o nível 5 de otimização não é algo tão distante do que o que procuramos fazer aqui. Mas como não fazemos isso com a quantidade de evidências e mensurações necessárias para o CMMI, mesmo que pudesse atingir o nível 5 pulando o nível 4 (não pode fazer isso, você só pode alcançar um nível de maturidade maior se tiver os anteriores) não atingiríamos este estado de processos em melhoria contínua.
Mas não estou dizendo que se pagarmos o preço, qualquer auditoria já nos promoveria automaticamente. Provavelmente há algum rigor extra em alguns dos quesitos que acredito que cumprimos, como o fato de a empresa que trabalho não ter uma equipe dedicada a testes. Mesmo assim, acabamos fazendo validação com equipes trocadas que acaba ajudando a cumprir esta parte da norma também, de que quem desenvolve o produto não pode atestar que está funcionando.
Para não ficarmos só com o utópico, porque não vejo muitas necessidades de a Dixtal pagar para ter uma certificação destas atualmente, resolvi também comparar com o MPS-BR. Que foi criado exatamente por isso. Algumas empresas brasileiras precisavam exigir um nível mínimo de qualidade (é pra isso que serve ser atestado como um nível de maturidade de desenvolvimento maior no CMMI) e para empresas menores este custo de implantar o CMMI era bastante proibitivo. A última vez que conferi os valores, ele circulava na faixa de R$ 300 mil a R$ 400 mil por ter que importar auditores. Então o modelo brasileiro, com certificação emitida por auditorias nacionais acaba tendo um preço mais acessível e foi definido de forma muito parecida que o primo rico. Mas ele conta com 7 níveis de maturidade e os níveis são decrescentes no lugar de crescentes. Vai do nível G (pior) para o nível A (melhor). Então se precisarmos criar um outro nível depois do estado de otimização contínua, acho que vamos ter que deslocar os rankings de todas as empresas... De qualquer forma, eles significam:
A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.
Neste processo eu confesso que tive um pouco de dificuldades de fazer a conversão do nível de maturidade que imagino para a Dixtal. Se no CMMI eu a considerei com processos definidos, tenho praticamente 3 níves (de E até C) que são mais ou menos a mesma correspondência. Precisei recorrer a um nível de detalhamento maior dos níveis de maturidade.
Nível G - Parcialmente Gerenciado
Processo: Gerência do Projeto - GPR
Processo: Gerência de Requisitos - GRE Nível
F – Gerenciado
Processo: Aquisição - AQU
Processo: Gerência de Configuração - GCO
Processo: Garantia da Qualidade - GQA
Processo: Medição - MED
Nivel E - Parcialmente Definido
Processo: Adaptação do Processo para Gerência do Projeto - APG
Processo: Avaliação e Melhoria do Processo Organizacional - AMP
Processo: Definição do Processo Organizacional - DFP
Processo: Treinamento - TRE
Nível D - Largamente Definido
Processo: Desenvolvimento de Requisitos - DRE
Processo: Integração do Produto - ITP
Processo: Solução Técnica - STE
Processo: Validação - VAL
Processo: Verificação - VER
Nível C – Definido
Processo: Análise de Decisão e Resolução - ADR
Processo: Gerência de Riscos - GRI
Nível B - Gerenciado Quantitativamente
Processo: Desempenho do Processo Organizacional - DEP
Processo: Gerência Quantitativa do Projeto - GQP
Nível A - Em Otimização
Processo: Implantação de Inovações na Organização - IIO
Processo: Análise de Causas e Resolução- ARC
Neste caso, acho que fico com o nível G! Brincadeira. É que a gerência de Requisitos é uma das coisas que estamos melhorando muito agora e é um pré-requisito para se começar a brincar nos níveis de maturidade do MPS-BR. Mas voltando a diferenciação dos três níveis de maturidade que eu queria separar, acredito que já chegaremos ao "nível C - Definido" até o fim do ano, realmente. É muito complicado um setor de equipamentos hospitalares não cuidar da Gestão de Risco... |
|
Qual a habilidade mais importante para um gerente de projetos? |
|
|
|
|
Escrito por Rodrigo Guiotti
|
|
Se você estiver respondendo um exame para a certificação PMP, diga que a habilidade mais importante é comunicação. E certamente você não está muito longe da resposta, realmente é algo extremamente importante, principalmente para resolver conflitos e para evitar que eles existam, inclusive. Comunique periodicamente, em especial, se o projeto estiver passando por problemas, já que ninguém gosta de achar que está tudo bem e de repente saber que perdeu todo o investimento realizado, sem chance de intervenção...
Mas pensando um pouco sobre o assunto, acabo chegando a conclusão que projetos podem chegar a bons resultados mesmo sem uma comunicação ideal. Então vai a pergunta, tem alguma habilidade que por si só, na sua opinião, poderia representar a falha de todo e qualquer projeto?
Acho a respeito das qualidades que um gerente de projetos deve ter, é difícil evitar de dizer que uma das mais importantes seja "bom senso". Muito do que é necessário para se formar um bom gerente de projetos poderia ser ensinado na escola, ao lado de português e matemática. Mas acredito que essa qualidade é importante e isso varia um pouco de pessoa para pessoa, ou de projeto para projeto.
Será que vale um custo adicional no projeto para entregá-lo antes? Será que valeria se fosse para cumprir um prazo combinado? Enfim, são muitas decisões e uma qualidade realmente importante é que as decisões do Gerente do Projeto combine com o que a empresa espera dele, claro, mas que ele também tenha bom senso para separar boas e más decisões além do priorizar o custo, depois o prazo e por fim a qualidade, por exemplo.
Talvez uma outra forma de dizer isso, seja dizer que ele precisa de empatia. Sentir o que os stakeholders realmente esperam dele e executar exatamente isso. Não entender o que se espera de um projeto é realmente um caminho garantido para o fracasso.
E você, o que acha? |
|
