Princípios de software.txt

Além dos princípios gerais de projeto, Hooker (1996, apud PRESSMAN, 2006) enumera sete princípios gerais da engenharia de software que se aplicam também ao projeto de software. São eles:

Um sistema de software existe para fornecer valor aos clientes e usuários.
Todas as decisões, inclusive as de projeto, devem ser tomadas tendo isso em mente.
Todo projeto de software deve ser tão simples quanto possível sem, no entanto, descartar características de qualidade importantes em nome da simplicidade.
O comprometimento com a visão arquitetural do sistema é essencial para o sucesso do projeto de software.
Os modelos elaborados na fase de projeto serão usados posteriormente por desenvolvedores responsáveis pela implementação, testes e manutenção do sistema. Assim, esses modelos devem ser claros, não ambíguos e fáceis de entender.
Um sistema com um longo tempo de vida tem mais valor. Contudo, para ter vida longa, um sistema deve ser projetado para estar pronto para acomodar mudanças.
A reutilização pode ajudar a poupar tempo e esforço, bem como aumentar a qualidade do sistema em desenvolvimento. Para conseguir um bom nível de reutilização, é necessário planejar o reuso com antecedência. Na fase de projeto, padrões arquitetônicos e padrões de projeto detalhado (design patterns) são bastante maduros e documentados.
Podemos lembrar, ainda, que projetar proporcionará viabilidade econômica, melhoria da qualidade, redução de riscos, erros e retrabalhos, economia de recursos, aumento de produtividade, entre outros pontos importantes que você irá aprender durante as aulas deste curso.

Referência:

PRESSMAN, R.S.. Engenharia de Software. McGraw-Hill. 6 ed. 2006


Mitch Kapor, citado por Pressman (2006), explica que o projeto é “onde você se instala com um pé em dois mundos – o mundo da tecnologia e o mundo das pessoas e objetivos humanos – e você tenta juntar os dois”.

O projeto é a fase do processo de software na qual os requisitos, as necessidades do negócio e as considerações técnicas se juntam na formulação de um produto ou sistema de software (PRESSMAN, 2006).

Independentemente do paradigma adotado, o processo de projeto envolve as seguintes atividades (PRESSMAN, 2006):

Projeto da arquitetura do software - Visa definir os elementos estruturais do software e seus relacionamentos.
Projeto dos elementos da arquitetura - Visa projetar em um maior nível de detalhes cada um dos elementos estruturais definidos na arquitetura, o que envolve a decomposição de módulos em outros módulos menores.
Projeto detalhado - Tem por objetivo refinar e detalhar os elementos mais básicos da arquitetura do software: as interfaces, os procedimentos e as estruturas de dados. Deve-se descrever como se dará a comunicação entre os elementos da arquitetura (interfaces internas), a comunicação do sistema em desenvolvimento com outros sistemas (interfaces externas) e com as pessoas que vão utilizá-lo (interface com o usuário), bem como se devem projetar detalhes de algoritmos e estruturas de dados.
Perceba que as atividades elencadas pelo autor permitem obter mais detalhes e informações em relação às necessidades e à solução do problema. É um nível de detalhamento que permitirá entender o produto desde seus elementos estruturais até a modelagem final do sistema.

O projeto é o processo criativo de transformar a especificação de um problema na especificação de uma solução. No projeto de software, utilizam-se a especificação e os modelos de requisitos gerados na fase de análise e especificação de requisitos. A partir dos requisitos, muitas soluções são possíveis e, portanto, muitos projetos diferentes podem ser produzidos. Uma solução é considerada adequada ao problema, se ela satisfizer a todos os requisitos especificados (PFLEEGER, 2004).

Referências:
PFLEEGER, S.L. Engenharia de Software: Teoria e Prática. 2 ed. São Paulo: Prentice Hall, 2004.
PRESSMAN, R.S.. Engenharia de Software. McGraw-Hill. 6 ed. 2006


6.6 Qualidade do projeto de sistemas Web
O responsável pela construção do projeto de sistema Web deve estar atento às normas de qualidade, ou seja, deve ter a preocupação em incorporar requisitos tecnológicos essenciais ao projeto capazes de agregar diversos atributos de qualidade geralmente definidos pela ISO/IEC.

O projetista deve atentar-se às características de qualidade que geralmente não estão restritas às funcionalidades do sistema, mesmo que estejam de alguma forma ligada a essas. Assim, serão evitados o retrabalho ou mesmo as reconstruções do sistema.

A ISO/IEC (2001) utiliza como referência para a avaliação de produtos de software seis características de qualidade, que você deve conhecer e estudar para entender melhor sobre a qualidade do projeto de sistemas Web, que são:

Funcionalidade - Refere-se à existência de um conjunto de funções que satisfazem às necessidades explícitas e implícitas e suas propriedades específicas. Tem como subcaracterísticas: adequação, acurácia, interoperabilidade, segurança de acesso e conformidade.
Confiabilidade - Diz respeito à capacidade do software de manter seu nível de desempenho, sob condições estabelecidas, por um período de tempo. Tem como subcaracterísticas: maturidade, tolerância a falhas, recuperabilidade e conformidade.
Usabilidade - Refere-se ao esforço necessário para se utilizar um produto de software, bem como o julgamento individual de tal uso por um conjunto de usuários. Tem como subcaracterísticas: inteligibilidade, apreensibilidade, operacionalidade, atratividade e conformidade.
Eficiência - Diz respeito ao relacionamento entre o nível de desempenho do software e a quantidade de recursos utilizados sob condições estabelecidas. Tem como subcaracterísticas: comportamento em relação ao tempo, comportamento em relação aos recursos e conformidade.
Manutenibilidade - Concerne ao esforço necessário para se fazer modificações no software. Tem como subcaracterísticas: analisabilidade, modificabilidade, estabilidade, testabilidade e conformidade.
Portabilidade - Refere-se à capacidade do software de ser transferido de um ambiente para outro. Tem como subcaracterísticas: adaptabilidade, capacidade para ser instalado, coexistência, capacidade para substituir e conformidade.
Pressman (2011) relaciona diferentes diretrizes de qualidade, afirmando que, para avaliar a qualidade da representação de um projeto, você e os outros membros da equipe de software devem estabelecer critérios técnicos para um bom projeto, considerando as seguintes diretrizes:

Um projeto deve exibir uma arquitetura que foi criada usando estilos ou padrões arquiteturais reconhecíveis, seja composta por componentes que apresentem boas características do projeto ou que possa ser implementada de forma evolucionária facilitando, portanto, a implementação e os testes.
Um projeto deve ser modular e o software deve ser logicamente dividido em elementos ou subsistemas, de modo que seja facilmente testado e mantido.
Um projeto deve conter representações distintas de: dados, arquitetura, interfaces e componentes.
Um projeto deve levar as estruturas de dados adequadas às classes a serem implementadas e baseadas em padrões de dados reconhecíveis.
Um projeto deve levar a componentes que representem características funcionais independentes (baixo acoplamento).
Um projeto deve levar a uma interface que reduza a complexidade das conexões entre os componentes e o ambiente externo (encapsulamento).
Um projeto deve ser obtido usando-se um método repetível, isto é, dirigido por informações obtidas durante a análise de requisitos de software.
Um projeto deve ser representado usando-se uma notação que efetivamente comunique seu significado.
Pressman (2011), ainda, enfatiza que essas diretrizes não são atingidas por acaso. Elas são alcançáveis por meio da aplicação de princípios de projeto fundamentais, de metodologia e sistemática e de revisão.

O PMBOK (2004) descreve que o projeto é um empreendimento temporário, de elaboração progressiva e com o objetivo de criar um produto ou serviço único, apresentando as seguintes fases:

Temporário - O projeto possui início e fim bem definidos e pode ser de curta ou longa duração. O projeto chega ao fim quando os seus objetivos são atingidos.
Elaboração progressiva - O desenvolvimento ocorre em etapas e continua por incrementos.
Produto ou serviço único - Cada projeto é exclusivo.
A qualidade de software não pode ser entendida como perfeição.

Perceba que cada atributo de avaliação permite conhecer melhor o sistema que está sendo projetado, ou seja, relaciona a adoção de abordagem consistente em um contexto prático específico para o desenvolvimento de sistemas ou aplicações Web.

É a partir de cada atributo de qualidade que o projetista tem a noção do que precisa ser feito, o que deve melhorar e o que já tem avançado progressivamente.

Referências:
PRESSMAN, R.S.. Engenharia de Software. McGraw-Hill. 6 ed. 2006.
PMBOK. Um guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. Uma Norma Nacional Americana ANSI/PMI 99-001-2004. 3. ed.

Este material foi baseado em:
RIBEIRO, Maria Ivanilse Calderon; COSTA, Juliana Braz da; BRAVIM, Jhordano Malacarne. Projeto de Sistemas Web. Universidade Federal de Mato Grosso/Rede e-Tec Brasil, Cuiabá: 2015.
Última atualização: terça, 25 jan 2022, 14:37


6.7 Projeto de sistemas e padrões de projeto (design patterns)
Como você já conhece alguns conceitos acerca de projetos de sistemas, certamente, deve saber algo sobre patterns, ou seja, sobre padrões.

Com certeza, você deve ter percebido que as respostas para as três perguntas direcionam para a reutilização de um projeto já existente, vez que não é necessário partir do zero, caso algum projeto apresente aspectos desejáveis que possam ser reutilizados em outros projetos. Assim, estamos falando da reutilização que é um aspecto fundamental para o desenvolvimento de software.

Lembre-se de que, de alguma maneira, quando tratamos de um projeto de desenvolvimento de sistema, estamos tratando de um novo projeto que será novo na medida em que vamos progredindo com o novo sistema. Isso pode ocorrer por vários motivos e não é preciso que seja desenvolvido do zero, vez que podem existir peculiaridades em sistemas já projetados.

Assim, você deve entender que um padrão (pattern) é uma solução já existente, testada e aprovada para problemas que de certa forma podem surgir em diversas outras necessidade de cliente diferentes.

Design patterns não são aplicados somente na informática, podem ser encontrados em diversas áreas de conhecimento como a engenharia e a arquitetura.


Foi o arquiteto austríaco Christopher Alexander (1936-) que introduziu a ideia de patterns, em 1970, para construir um vocabulário comum para discussões sobre design.

Para Pressman (2011), cada Pattern descreve um problema que ocorre várias vezes ao nosso redor e, com isso, descrevem a solução para o problema de uma maneira que você pode usar essa solução diversas vezes sem ter que fazer a mesma coisa duas ou mais vezes.

O objetivo de um padrão de projeto é registrar uma experiência no projeto de software, que possa ser efetivamente utilizada por projetistas. Cada padrão sistematicamente nomeia, explica e avalia uma importante situação de projeto que ocorre repetidamente em sistemas (GAMMA et al., 1995).

Um profissional que conheça padrões poderá utilizá-los evitando, assim, o trabalho de um novo projeto para problemas já conhecidos. Não será necessário pensar o mundo real para o mundo computacional, vez que já possui o conhecimento de abstrações já feitas e daí apenas prosseguir para a tomada de decisões do projeto.

Observando os estudos de Buschmann et al. (1996), um padrão tem os seguintes elementos:

Nome: identificação de uma ou duas palavras, utilizadas para nomear o padrão.
Contexto: uma situação que dá origem a um problema.
Problema: explica o problema que surge repetidamente no dado contexto.
Solução: descreve uma solução comprovada para o problema, incluindo os elementos que compõem o projeto, seus relacionamentos, responsabilidades e colaborações.
Consequências: são os resultados e os comprometimentos feitos ao se aplicar o padrão.

Um pattern não descreve um projeto específico, sendo, na verdade, uma oportunidade de reutilizar um problema já abstraído do mundo real. Por esse motivo, devem-se observar criteriosamente os resultados e o comprometimento existentes a partir dessa utilização.

De certa forma, um pattern de projeto descreve uma estrutura comumente recorrente de componentes que se comunicam, capaz de resolver um problema de projeto geral dentro de um particular contexto (GAMMA et al., 1995).

Os padrões de projeto devem ser observados como ferramentas para o projetista e o desenvolvedor de software, vez que auxiliará na solução de problemas que ocorrem com frequência, permitindo que os esforços de tais profissionais sejam utilizados em outra demanda.

Referências:

BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M. PatternOriented Software Architecture: A System of Patterns. Vol. 1. S.l.: Wiley, 1996.

GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.M., Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

PRESSMAN, R.S.. Engenharia de Software. McGraw-Hill. 6 ed. 2006.

6.8 Documentação do projeto
Por se tratar de projeto, você deve compreender a importância da documentação do projeto de sistemas Web. Você já aprendeu que o projeto de um sistema é o início técnico do processo de desenvolvimento e por isso é de grande importância, caso você queira obter sucesso com vida longa ao projeto implementado.

Assim, ao projetar um sistema, o projetista precisará da documentação do projeto do sistema para qualquer manutenção futura, lembrando que a equipe de profissionais envolvidos em determinado projeto pode ser transitória ou sofrer alguma modificação durante a construção do projeto. Outra necessidade que já se pode visualizar é em relação às peculiaridades de diferentes projetos.

No desenvolvimento de um sistema, uma gama de profissionais pode estar envolvida, às vezes com diferentes necessidades e, por isso,  a documentação do projeto se faz importante. Em outras palavras, diferentes interessados vão requerer informações diferentes e a documentação de projeto é primordial para a comunicação entre esses profissionais.

Para Bass; Clements; Kazman (2003), a documentação do projeto de sistemas deve conter:

informações gerenciais, tais como versão, responsáveis, histórico de alterações;
uma descrição geral do sistema; e
uma lista das visões consideradas e informações acerca do mapeamento entre elas.
Lembre-se de que as visões podem ser apresentadas por meio de representação gráfica, tabular ou textual. Elas são essenciais e a documentação deve abranger visões consideradas relevantes e abrangentes do sistema.

Referência:

BASS, L., CLEMENTS, P., & KAZMAN, R. Software Architecture in Practice. Addison-Wesley Professional, 2nd edition,2003.

Este material foi baseado em:
RIBEIRO, Maria Ivanilse Calderon; COSTA, Juliana Braz da; BRAVIM, Jhordano Malacarne. Projeto de Sistemas Web. Universidade Federal de Mato Grosso/Rede e-Tec Brasil, Cuiabá: 2015.