Qualidade de softwarre (caixa de pandora?)

(Postado originalmente em 10 de março de 2009)

 

Creio que a questão da qualidade [no desenvolvimento de um software] está intimamente ligada àos acordos estabelecidos no momento da venda de um determinado projeto (especialmente de softwae).
O que tenho visto na prática (atuando como pré-venda de serviços de software) é que, embora as normas apontem boas práticas, o que há de efetivo na contratação é a questão do prazo.
Softwares são construidos ou personalizado visando alguma aplicabilidade de negócios que, normalmente, precisam de agilidade.
Existem modelos de gerenciamento (como o MSF for Agile, Scrum, Extreme Programming) que tentam endereçar um meio termo entre o ideal de qualidade (entenda-se por qualidade aqui a questão do software funcionando no prazo com a documentação essencial, testes e atendimento) e a qualidade que se pode pagar.
Notem que não estou me limitando aos custos efetivos da sua produção, e sim também o prejuízo virtual de não se ter a solução em tempo hábil para que o negócio (business) seja atendido de forma a tornar-se competitivo.
Se buscarmos cegamente o ideal de qualidade, provavelmente perderemos muitos bons negócios e, sem negócios, os salários não chegam. :). Não haverá fôlego neste caso para encontrar a tal caixa de pandora descrita pelas normas e guias de "best practices"
Há também a questão de que há falta de hábito dos envolvidos num projeto de software em tornar os artefatos produzidos independentes da "pessoa" que os produziu.
Seguindo nesta linha, creio que as principais características necessárias aos envolvidos num projeto de software sejam:

  • Comunicação : verbal, escrita. Todos devem saber entender e promover um bom entendimento de suas expressões;
  • Visão "holistica": entender não somente a sua parte no projeto mas o fim ao qual ele se destina. Qual a necessidade de negócios vai ser atendida? Como age o responsável (usuário final) por fazer acontecer o processo automatizado ou otimizado pelo software?
  • Flexibilidade: Nem sempre a melhor solução técnica é a melhor solução de negócios. De nada adianta um software feito nas mais "novas" tecnologias e técnicas se, por exemplo, para vender uma camisa, o usuário (vendedor da loja) leva mais tempo para realizar o negócio do que se anotasse a venda num caderninho.

Enfim… acho que não são todos os projetos que precisam das primasias da norma. Deve haver o bom-senso para estimar e fazer acontecer a melhor solução de negócios.

Há uma história que talvez retrate bem o que quero dizer (cf http://www.natalino.com.br/sinaleiro/archives/000200.html )

Diferença entre "foco no problema" e foco na solução

Quando a Nasa iniciou o lançamento de astronautas, descobriu que as canetas não funcionariam com gravidade zero. Para resolver este enorme problema, contrataram a Andersen Consulting, hoje Accenture. Empregaram 12 milhões de dólares para sanar o problema. Conseguiram desenvolver uma caneta que escrevesse com gravidade zero, de ponta cabeça, debaixo d’água, em praticamente qualquer superfície incluindo cristal e em variações de temperatura desde abaixo de zero até +300ºC.

Os russos usaram um lápis…

my 2 cents.

[]s

——————————Termina aqui o conteúdo original ————————————-

Em termos de ALM…

Qualidade é pode ser traduzida em uma fórmula bem simples:

 

Q = Int + Ger + Prod + Test

onde:

Int = Integração da equipe

Ger = Gerência (de projetos/requisitos)

Prod = Produtividade

Test = Testes integrados (desde o teste unitário até o teste de carga)

Q = resultado final, isto é, Qualidade

 

Slide2

 Slide3

 Slide4

fui claro?

Ciclo de vida de um software

(postado originalmente em 06/03/2009)

O ciclo de vida de um software, segundo a NBR ISO/IEC 12207 compreende um conjunto de processos, que por sua vez, são compostos por atividades determinadas por um conjunto de tarefas pertinentes.

Como o software pode ser classificado como um produto, o seu desenvolvimento deve envolver um conjunto de processos bem definidos para que este produto seja elaborado com a qualidade adequada para seu fim. Entenda-se por qualidade o equilíbrio entre a eficiência do produto em si, seu custo de produção e o atendimento das necessidades de negócio do problema computacional que se deseja resolver bem como o atendimento dos seus usuários.

O ciclo de vida inicia-se no ‘entendimento’ efetivo do fim ao qual se destina, prolonga-se na fase efetiva de sua construção que é realizada por meio de processos de análise, especificação, codificação, testes, implantação e estabilização.

Normalmente o ciclo de vida é uma coletânea de processos que viabilizam a produção de um software num determinado contexto de necessidades de negócios em um determinado tempo a partir de parâmetros de custo e qualidade previamente definidos (no ato da contratação do serviço de desenvolvimento).

A escolha do conjunto de processos componentes do ciclo de vida é feita por um engenheiro de software, gerente de projetos e/ou de produtos num molde que seja adequado aos parâmetros de custo e prazo (normalmente balizados pela necessidade/urgência do cliente). Os moldes de processos mais comuns no mercado atual são os determinados pelo CMMI (Capability Maturity Model Integration), Scrum e MSF/MSF for Agile Development.

O início de um projeto de software é, normalmente, feito com base em um estudo preliminar dos requisitos de negócio que norteiam o molde/conjunto de processos a serem seguidos/implementados para o desenvolvimento do “produto”. Com base na implantação do processo, as especificações são detalhadas (CMMI) ou reunidas em uma lista de Backlog (Scrum/MSF for Agile) e, enfim desenhadas/planejadas em termos de arquitetura do sistema. A arquitetura definida gera, então, a especificação (formal – CMMI /informal SCRUM) que determina como esse sistema será codificado ou implementado a partir das tecnologias e processos definidos no estudo preliminar dos requisitos de negócio. Ao final (do desenvolvimento do produto – CMMI | de cada SPRINT – SCRUM) o software (ou parte funcional dele) é testado e entregue ao cliente.

Conforme o acordo firmado na contratação, o suporte ao produto é iniciado tendo influência direta sobre as correções de “não-conformidades” ou erros (Bugs) ou ainda na implementação de melhorias coletadas a partir dos retornos dados pelos usuários do software.

(por Mauro Zamaro para a disciplina de Analise e Projeto de Sistemas – CEUCLAR – Rio Claro)

Referências

Microsoft – MSDN. (2009). Modelos e Ferramentas do processo. Retrieved 03 05, 2009, from MSDN: http://msdn.microsoft.com/pt-br/vsts2008/aa718795.aspx

Vários. (n.d.). CMMI . Retrieved 03 05, 2009, from WikiPedia: http://pt.wikipedia.org/wiki/CMMI

Vários. (n.d.). Scrum. Retrieved 03 05, 2009, from WikiPedia: http://pt.wikipedia.org/wiki/Scrum