| << Chapter < Page | Chapter >> Page > |
Design de software facilita a comunicação , pois contém conhecimento sobre o sistema que pode ser gravado, transmitido e discutido entre os interessados. Um caso bem comum é o de apresentar um sistema a novos membros de um time de desenvolvimento. Informações valiosas, como por exemplo, quais os principais módulos e seus diversos comportamentos, lhes podem ser passadas através do design do sistema antes de mostrá-los o código-fonte. Dessa maneira, essas informações de alto nível de abstração ajudarão a situá-los no código posteriormente. No entanto, o design não serve apenas para os desenvolvedores. Um usuário do sistema pode procurar no design informações de um nível ainda maior de abstração, como quais funções o sistema é capaz de realizar, ou qual o desempenho delas.
Por outro lado, design de software também demanda algumas observações importantes.
O problema a ser resolvido pode não permanecer o mesmo durante todo o processo de design. Ao passo que o design é implementado, o cliente, que é o stakeholder interessado em que o software construído solucione um problema em particular, (1) pode mudar de ideia quanto à natureza do problema; (2) pode ter descrito o problema incorretamente; ou ainda (3) pode decidir que o problema mudou ou mesmo que já fora resolvido enquanto o design é feito. Essas possibilidades não devem ser ignoradas durante o desenvolvimento, uma vez que elas podem ocasionar em perda de tempo e dinheiro durante a fase de design ou ainda ocasionar o fracasso no atendimento das necessidades do cliente.
Há diferenças entre o design e o sistema construído a partir dele. O design de um software é apenas um modelo, do qual o nível de detalhes pode não ser adequado para certos tipos de avaliação. Por sinal, avaliar um design insuficientemente detalhado pode levar a resultados errôneos e, consequentemente, há sistemas que não resolvem os problemas da forma esperada. Isso é comum acontecer, por exemplo, quando por erro do projetista, detalhes importantes para a avaliação não são incluídos no design. O exemplo a seguir ilustra um caso em que a avaliação inadequada resultou em um produto com problemas.
Um caso conhecido de produto com falhas por avaliação inadequada é o caso de um sistema de controle de armamento para cruzadores da marinha norte-americana que foi desenvolvido pela empresa Aegis. Depois de desenvolvido, o sistema de armamento foi instalado no cruzador U.S.S. Ticonderoga para o primeiro teste operacional. No entanto, os resultados do teste demonstraram que o sistema errava 63% dos alvos escolhidos devido a falhas no software. Posteriormente, foi descoberto que a avaliação e os testes do software de controle foram realizados numa escala menor do que as condições reais e que, além disso, os casos de teste incluíam uma quantidade de alvos menor que a esperada em campo de batalha. Uma descrição mais completa deste caso pode ser encontrada no artigo The Development of Software for Ballistic-Missile Defense [link] , de Lin.
Notification Switch
Would you like to follow the 'Arquitetura de software' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|