Obter sucesso no processo de um software não é fácil. Existem vários fatores que dificultam atingir os objetivos de qualidade. Para conseguir cumprir esses objetivos é necessário satisfazer as necessidades do cliente. Em muitas vezes ocorre à frustração por parte do cliente, por falta de acompanhamento no desenvolvimento dos softwares.
Introdução
Ao falar de software estaremos falando do produto e do processo. De nada adianta centrarmos nossa atenção apenas no produto ou apenas no processo. É necessário que o produto e o processo caminhem juntos e tenham qualidade.
Durante muito tempo a engenharia de software teve mais atenção com o produto. Três aspectos dominaram a pesquisa e a prática da construção de software, que são eles:
•Uma ênfase na qualidade das representações, isto é nas linguagens artificiais.
• A crença de que a qualidade do produto é função principalmente de teste do produto
final.
• Que o processo de produção era centrado em fases caracterizadas por produtos bem
definidos
A qualidade das representações é um importante aspecto da engenharia de software , assim como programações robustas , de maior confiabilidade e de maior abstração, só que ainda são tema de discussões. Sob o ponto de vista de representações mais abstratas, e a princípio, não executáveis, o ponto central são linguagens de especificação. Por um lado temos a necessidade de linguagens formais e abstratas e por outro temos a necessidade de linguagens de fácil comunicação e também abstratas.
O papel do teste, o teste é fundamental na produção de um software. E hoje tem ferramentas embutidas nas linguagens de programação para ajudar nesses testes, que fazem que o produto final não tenha erros. No entanto, sabe-se que esse processo é extremamente dispendioso e muitas vezes envolve uma grande número de recursos humanos para garantir um nível mínimo de qualidade.
A visão inicial do processo de produção de um software era centrada em produtos bem definidos e em regras de verificação entre produtos. Esses produtos fundamentavam-se na visão de seqüencialidade. Mesmo em propostas não seqüenciais, como a prototipação, a atenção principal é dirigida às representações dos produtos. Hoje tem-se uma visão mais abrangente.
O papel da gerência passa a ser visto como um aspecto técnico e não como um aspecto exterior ao conhecimento da engenharia de software e a atenção está centralizada na aquisição de dados sobre o processo e a transformação desses dados em conhecimento sobre o processo de produção.
Qualidade
O produto software passa cada vez mais a ser um produto comum, como carro, elevadores, e como esses produtos precisam ter qualidade e um bom preço. Essa é a função da engenharia de software, ter um sistemas de boa qualidade e um bom preço , o fundamental também é que o software seja confiável , ou seja siga os padrões exigidos pelo contexto onde irá atuar. Freeman faz uma distinção entre qualidade básica e qualidade extra. Em qualidade básica ele lista: funcionalidade, confiabilidade, facilidade de uso, economia e segurança de uso. Em qualidade extra ele lista: flexibilidade, facilidade de reparo, adaptabilidade, facilidade de entendimento, boa documentação e facilidade de adicionar melhorias.
A qualidade deve estar presente não só nos produtos produzidos, como também nos processos utilizados para gerar esses produtos. Neste caso os processos de qualidade, ou de auditoria, são processos que se aplicam tanto aos produtos, como aos próprios processos (uma meta aplicação dos processos de qualidade). Assegurar a qualidade dos produtos e dos processos é responsabilidade do subsistema GERÊNCIA, que necessita dispor de MÉTODOS e FERRAMENTAS compatíveis com a qualidade desejada.
Evolução
Os processos de construção de softwares hoje em dia serão cada vez mais baseado no conceito de evolução, ou seja, sempre estamos modificando um software já existente.
No contexto evolutivo é importante saber da impossibilidade da completeza de um conjunto de requisitos.
Para lidar com evolução de um software, é fundamental utilizar o conceito de baseline oriundo da área de configuração de sistemas.
Baseline é uma espécie de referencial que utilizamos num processo de mudança (evolução). Para que se possa gerar as maneira organizada o processo de construção/evolução deve estar ancorado num baseline.
No entanto, os requisitos evoluem também, portanto passamos a ter uma baseline que também evolui. A definição da baseline de requisitos explica que essa evolução se dá em dois eixos:
1- Pontos de referência do modelo de processo de software e outro eixo no que
2- Progressão do processo de software no que se refere à mudança de nível de abstração.
Ou seja, o baseline de requisitos muda tanto no mesmo nível de abstração como entre níveis de abstração.
A característica fundamental da baseline de requisitos diz respeito a sua formação e a sua representação. A baseline se forma procurando moldar-se ao Universo de Informações e sua representação utiliza linguagem natural através de um léxico e de um conjunto de cenários.
É claro que a complexidade de controlar essa baseline é não trivial, no entanto é uma maneira integrada de tentarmos garantir que a alocação dos requisitos, tanto funcionais como não funcionais seja registrada e rastreável. Assim, é possível efetivamente gerenciar os requisitos principalmente num contexto volátil.
Resumo do Artigo “Qualidade de Software: Teoria e Prática, Orgs. Rocha, Maldonado, Weber, Prentice-Hall, São Paulo, 2001 Capítulo 17.”
