Engenharia de Software

Não há como tratarmos de Qualidade de Software sem abordarmos uma das principais áreas cujos resultados das aplicações de seus conceitos influenciam diretamente na qualidade do software que está sendo desenvolvido.

Em razão disso, gostaria de lhes apresentar os conceitos básicos da Engenharia de Softwares que nos levam a vislumbrar as etapas de um processo de desenvolvimento onde ela influencia.

A engenharia de software é uma área da Engenharia que trata das características de produção de software, desde as etapas iniciais, onde o sistema é especificado, até a sua manutenção, após já estar sendo operado (SOMMERVILLE, 2003).

Além disso, a engenharia de software caracteriza-se por aplicar uma abordagem sistemática, disciplinada e mensurável para o desenvolvimento, operação e manutenção de softwares (IEEE, 1993).

A engenharia de software é necessária para evitarmos o caos no processo de desenvolvimento de software, através da aplicação de princípios científicos, métodos, modelos, padrões e teorias que possibilitam gerenciar, planejar, modelar, projetar, implementar, medir, analisar, manter e aprimorar um sistema de software (PETERS, 2001).

Em razão disso, compreende-se que a engenharia de software é dividida em camadas, focando na qualidade do software, conforme mostra a FIGURA 1 (PRESSMAN, 2001).

FIGURA 1 – Engenharia de Software em Camadas (PRESSMAN, 2001)

Considerando a FIGURA 2.1, cada etapa é preenchida por um conjunto de ações relacionadas que produz um produto importante de engenharia de software. Estas ações fornecem as técnicas necessárias para a construção de softwares, pois contemplam um conjunto de tarefas que incluem comunicação, análise de requisitos, modelagem de projeto, construção de programas, teste e manutenção. A base da engenharia de software é a camada de processo, pois mantém unidas as camadas de tecnologia, permitindo o desenvolvimento racional de software de computador (PRESSMAN, 2001).

Considerando estes conceitos, nos próximos posts pretendo apresentar assuntos das áreas mais específicas da Engenharia de Software e que são mais visíveis no nosso dia-a-dia.

Em razão disso, gostaria de lhes apresentar os conceitos básicos da Engenharia de Softwares que nos levam a vislumbrar as etapas de um processo de desenvolvimento onde ela influencia.

Referências Bibliográficas

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

IEEE, Institute of Electrical and Electronics Engineers: Software Engineering, IEEE Standard 610.12 – 1990, IEEE, 1993.

PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5^th ed. New York: McGraw-Hill, 2001.

O que são Requisitos de Software?

Conforme visto no post anterior, requisitos de software nada mais são do que um conjunto de atividades que o software deve desempenhar, com suas limitações e restrições, além de características não ligadas diretamente às funções desempenhadas pelo software (SOMMERVILLE, 2003).

Quanto mais compreensível, precisa e rigorosa for a descrição de um requisito de sistema, maior será a proporção quanto ao grau de qualidade do produto resultante (PETERS, 2001).

Os requisitos de sistema são normalmente categorizados como funcionais, não funcionais ou requisitos de domínio. A seguir, abordaremos cada uma destas categorias.

Requisitos Funcionais:

Os requisitos funcionais tratam de funções que o sistema deve fornecer, como o sistema deve se comportar a estradas e a determinadas situações (PRESSMAN, 2001).

Em outras palavras, descrevem a funcionalidade ou serviço que se espera que o sistema forneça. Dependendo do tipo de software do requisito a ser descrito é possíveis criar subgrupos de requisitos funcionais, normalmente subdivididos como (SOMERVILLE, 2001):

· Requisitos Funcionais de Usuário: Normalmente descritos de um modo geral;

· Requisitos Funcionais de Sistema: Descrevem a função de sistema detalhadamente, suas entradas, saídas e exceções.

A especificação de requisitos funcionais deve ser completa e consistente. Isto consiste em deixar evidentes e definidas todas as funções requeridas pelo usuário. Além disso, não devem ter definições contraditórias.

Requisitos Não Funcionais:

Os requisitos não funcionais dizem respeito às restrições sobre os serviços ou funções do sistema. Por exemplo, restrição de tempo, restrição do processo de desenvolvimento, padrões, etc. (PRESSMAN, 2001).

Isto é, são aqueles requisitos que não dizem respeito às funções específicas fornecidas pelo sistema. Logo, estão diretamente relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espaço em disco. Podem definir restrições para o sistema, como a capacidade de dispositivos de entrada e saída relacionados e as representações de dados utilizados em um padrão de interface.

Contudo, requisitos não funcionais também dizem respeito ao sistema como um todo e não a características individuais do sistema. Em razão disso, podemos considerá-los mais importantes que requisitos funcionais individuais. Além disso, se houver falhas ao cumprir um requisito não funcional poderá tornar todo o sistema inútil.

Os requisitos funcionais normalmente surgem conforme a necessidade de usuários, de restrições de orçamentos, de políticas organizacionais, pela necessidade de interoperabilidade com outros sistemas ou devido a fatores externos, como regulamentações ou legislação, por exemplo. Assim, podemos classificar os requisitos não funcionais de diversas formas para poder organizá-los (SOMMERVILLE, 2003):

· Requisitos de Produto

o Requisitos de Facilidade de Uso

o Requisitos de Eficiência

- Requisitos de Desempenho

- Requisitos de Espaço

o Requisitos de Confiabilidade

o Requisitos de Portabilidade

· Requisitos Organizacionais

o Requisitos de Entrega

o Requisitos de Implementação

o Requisitos de Padrões

· Requisitos Externos

o Requisitos de Interoperabilidade

o Requisitos Éticos

o Requisitos Legais

- Requisitos de Privacidade

- Requisitos de Segurança

Requisitos Não Funcionais:

Os Requisitos de Domínio originam-se do domínio da aplicação do sistema, refletindo as características deste domínio (SOMMERVILLE, 2003). Podem ser funcionais ou não (PRESSMAN, 2001).

Se estes requisitos não forem atendidos satisfatoriamente, poderá ser impossível fazer a aplicação operar adequadamente.

Referências Bibliográficas

PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5^th ed. New York: McGraw-Hill, 2001.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.