Modelagens de Sistemas de Informação

(1)

Modelagens de

Sistemas de Informação

(2)

(3)

a 1° Revisão - 19/04/0 7 || Revi sor a: Sueli / Syl via - Corr

eeção: Lilian - par

a 2ª r evis ão: 23 /04/0 7 // C orr eção: Már cio - 26/04/0 7 1 ENGENHARIA DE SISTEMAS

Como conseqüência do crescimento e da necessidade de desenvolver grandes sistemas de informação, para a substituição dos pequenos programas que eram utilizados em separado dentro das empresas, surgiu um grande problema, que era a falta de experiência e de métodos para o desenvolvimento desses grandes sistemas. Toda essa diﬁ culdade permitiu o nascimento da engenharia de sistemas.

O custo para o desenvolvimento de grandes sistemas corresponde a uma percentagem cada vez maior nos gastos das empresas, pois a tecnologia de desenvolvimento de sistemas implica cada vez mais uma grande carga de trabalho, envolvendo um grande número de pessoas e um prazo relativamente logo para o seu desenvolvimento. Esse desenvolvimento é realizado na maioria das vezes de forma ad-hoc, não respeitando os cronogramas que foram traçados e acrescendo assim custos ao desenvolvimento.

De uma forma clássica, podemos também deﬁ nir esses sistemas como um conjunto de instruções, componentes e partes que, quando executados, produzem funções e desempenhos que são desejados. A estrutura dos seus dados permite que as informações relativas ao problema a ser resolvido sejam manipuladas adequadamente.

Um sistema é sistematicamente destinado a ser utilizado por usuários que podem ter formações diferentes, sendo necessária a preocupação no desenvolvimento, para que o produto

Engenharia de Sistemas

5 10 15 20 25 O desenvolvimento de grandes sistemas é realizado na maioria das vezes de forma ad-hoc, não respeitando os cronogramas que foram traçados e acrescendo assim custos ao desenvolvimento.

(4)

a 2ª r evis ão: 23 /04/0 7 // C orr eção: Már cio - 26/04/0 7

tenha uma interface amigável e uma documentação rica em informações, o que possibilita o conhecimento e exploração de todos os recursos que o sistema oferece de forma eﬁ ciente. Todos esses sistemas devem ser submetidos a uma grande série de testes, pois é inviável que os usuários tenham que detectar e corrigir os erros encontrados.

Para caracterizar melhor o signiﬁ cado da engenharia de um sistema, algumas particularidades devem ser observadas:

• Um sistema é desenvolvido como resultado de um trabalho de engenharia e não manufaturado no sentido clássico; • Um sistema não se desgasta como a maioria dos produtos,

pois não se caracteriza por um aumento na possibilidade de falhas à medida que o tempo passa.

Em função das características citadas, o processo de desenvolvimento de sistemas pode gerar um conjunto de problemas que terão inﬂ uência direta na qualidade do produto ﬁ nal.

Algumas questões que caracterizam as preocupações com o desenvolvimento de sistemas são:

• Por que os sistemas demoram tanto para serem construídos?

• Por que o custo para a construção de um sistema é tão elevado?

• Por que é tão complicado detectar todos os erros que o sistema possui antes de ser entregue ao cliente?

• Por que é tão difícil fazer uma medição de progresso no desenvolvimento do sistema?

Essas são algumas questões que a engenharia de sistemas pode auxiliar a resolver.

5

10

15

20

(5)

Vamos citar alguns pontos que causam os problemas que citamos acima:

• Durante o desenvolvimento do sistema, raramente é dedicado um tempo para que seja feita uma coleta de dados sobre o processo de desenvolvimento em si. A pouca quantidade desse tipo de informação e as tentativas utilizadas para se estimar a duração e os custos para a produção têm gerados resultados insatisfatórios;

• Ocorre freqüentemente o questionamento de clientes insatisfeitos com os sistemas, pois grande parte desse desenvolvimento é feita por meio de informações vagas sobre as necessidades e desejos dos clientes;

• A qualidade do sistema desenvolvido é suspeita, pois pouca atenção foi dada e não foram utilizadas técnicas de teste e conceitos de qualidade de software;

• O sistema existente é normalmente difícil de manter em operação, pois grandes custos são alocados para atividades relacionadas à manutenção, sendo reﬂ exo da pouca importância que foi dada na manutenção do sistema no momento da sua concepção;

Como causa dos problemas citados acima, podemos citar alguns pontos:

• Falta de experiência dos proﬁ ssionais que estão conduzindo o projeto;

• Falta de treinamento em técnicas e métodos de desenvolvimento de softwares;

• A resistência a mudanças que os proﬁ ssionais antigos apresentam às novas técnicas de desenvolvimento de sistemas.

É preciso estar ciente de que não existe uma abordagem- padrão que seja a solução para todos os problemas citados, mas uma combinação de métodos que sejam abrangentes a

5 10 15 20 25 30

(6)

todas as etapas do desenvolvimento de um sistema. Todos esses métodos devem ser suportados por um conjunto de ferramentas que permita a automatização dessas etapas e, junto com essas ferramentas, é necessária a deﬁ nição clara dos critérios de qualidade a serem aplicados.

1.1 Modelos de desenvolvimento

O processo de desenvolvimento corresponde a um conjunto de atividades ordenadas de modo que o produto desejado seja obtido. O modelo de desenvolvimento é uma representação abstrata do processo de desenvolvimento que vai definir como as etapas relativas ao desenvolvimento do sistema serão direcionadas e relacionadas para que possam atingir o objetivo desejado, que é obtenção de um produto de alta qualidade.

Podemos organizar o processo de desenvolvimento em três grandes fases:

Deﬁ nição: está associada ao que vai ser feito. Nesta fase,

devem ser identifi cadas as informações que serão manipuladas. Na fase de defi nição, são caracterizadas três etapas específi cas:

• Análise do sistema;

• Planejamento do projeto do sistema; • Análise dos requisitos.

Desenvolvimento: será determinado como realizar as

funções do sistema, envolvendo a sua arquitetura, estrutura dos dados, procedimento e a utilização das linguagens de programação. Na fase de desenvolvimento, são caracterizadas três etapas especíﬁ cas:

• Projeto do sistema; • Codiﬁ cação; • Teste. 5 10 15 20 25

(7)

Manutenção: a manutenção é iniciada a partir do momento

que o sistema é entregue ao cliente. São realizadas alterações de diversos tipos, seja a correção de erros, inclusão de novas funções ou adaptação de novas conﬁ gurações. Nesta fase, caracterizamos as seguintes atividades:

• Correção; • Adaptação;

• Melhoramento Funcional.

Considerando a situação atual do mercado, foi criado o conceito de engenharia reversa, que utiliza técnicas e ferramentas da engenharia de software para que o sistema existente sofra uma reforma geral com objetivo de aumentar a sua qualidade e atualizá-lo com respeito às novas tecnologias.

2 UML

Na disciplina de Estrutura de Sistemas de Informação, ﬁ zemos uma rápida passagem sobre a UML, em que falamos da sua importância na modelagem dos sistemas de informação. Neste capítulo, iremos nos aprofundar mais na UML, dando maior ênfase aos seus diagramas, que são poderosas ferramentas utilizadas na modelagem de sistemas.

A UML surgiu para resolver o grande problema existente no desenvolvimento de softwares, utilizando a orientação a objeto, que é a modelagem. Não existia uma notação padronizada que proporcionasse abrangência a qualquer tipo de aplicação que se desejasse, além de resultar em várias simbologias e terminologias diferentes, originando assim uma grande confusão para os desenvolvedores. Com o lançamento da UML, grande parte dos desenvolvedores de softwares ﬁ caram entusiasmados com a notícia, pois esse tipo de padronização já era esperado há muito tempo. 5 10 15 20 25

(8)

É interessante observar que a UML tem como característica abordar o caráter estático e dinâmico do sistema que está sendo avaliado, proporcionando já na modelagem, características futuras do sistema com relação à linguagem utilizada, banco de dados e algumas outras especiﬁ cações ﬁ nais do sistema.

2.1 Objetivos da UML

• Proporcionar a modelagem de sistemas utilizando todos os conceitos da orientação a objeto;

• Fixar uma junção nos métodos conceituais, tornando-os executáveis;

• Deﬁ nir uma linguagem de modelagem que possa ser utilizada tanto pelo homem, quanto pela máquina.

A UML tem como característica ser uma linguagem de modelagem dominante, sendo baseada em padrões e conceitos que foram testados em metodologias anteriores.

2.2 A Utilização da UML

A UML pode ser utilizada no desenvolvimento dos mais variados tipos de sistemas, pois tem como característica abranger qualquer atributo do sistema, utilizando os seus diagramas nas diferentes fases de desenvolvimento. O objetivo principal é descrever qualquer tipo de sistema, utilizando diagramas orientados a objeto.

Citaremos abaixo alguns sistemas e suas características:

Sistemas de informação: têm como característica

principal o armazenamento, pesquisa, edição e demonstração de informações para os seus usuários. Possuem uma grande quantidade de relacionamentos, que envolve certa complexidade, além de armazenar uma grande quantidade de informações em bases de dados relacionais ou orientadas a objetos.

A UML proporciona, já na modelagem, características futuras do sistema com relação a linguagem utilizada, banco de dados e algumas especiﬁ cações ﬁ nais do sistema.

5

10

15

20

(9)

Sistemas em tempo real: são executados por Hardwares

especíﬁ cos integrados a veículos, aparelhos telefônicos, eletrodomésticos, entre outros. Utilizam uma programação de baixo nível, requerendo suporte em tempo real.

Sistemas distribuídos: têm como característica principal

serem distribuídos por várias máquinas, cuja transferência de dados entre ambas é feita facilmente, possuindo mecanismos de sincronização que garantem a integridade dos dados.

2.3 Notações da linguagem UML

A UML é composta por algumas notações que são utilizadas para modelar os mecanismos gerais de um sistema. Todas essas notações, em conjunto, permitem especifi car e exemplifi car a defi nição de um sistema no que diz respeito às suas funcionalidades, estáticas e dinâmicas. Falaremos um pouco sobre cada um desses componentes, focalizando mais os diagramas.

2.3.1 Visões

O principal atributo das visões é a demonstração dos diferentes aspectos existentes no sistema que está sendo modelado. A visão não é considerada um gráfico, mas sim uma abstração que é constituída por uma série de diagramas. Com a definição do número de visões, cada uma será responsável por demonstrar aspectos do sistema, em que é dado um maior enfoque aos ângulos e níveis de abstrações diferentes e, com isso, será possível gerar uma figura completa do sistema.

2.3.2 Modelos de elementos

Os conceitos que são utilizados nos diagramas são modelos de elementos que têm, como característica, representar as

5

10

15

20

(10)

definições mais comuns da orientação a objeto, como as classes, os objetos, as mensagens, os relacionamentos, entre outros.

Ilustraremos abaixo o conjunto dos principais elementos de estrutura:

Agora ilustraremos os principais elementos de comportamento (estados e mensagens), agrupamento (pacotes) e anotações.

2.3.3 Tipos de relações

Em um conceito geral, as relações apresentam uma sintaxe e uma semântica bem deﬁ nidas, permitindo o estabelecimento de interdependência entre os elementos básicos citados acima.

5

(11)

a 2ª r evis ão: 23 /04/0 7 // C orr eção: Már cio - 26/04/0 7 2.3.4 Diagramas

A UML é composta por diagramas que juntos podem modelar vários tipos de sistemas. Como falamos anteriormente, a maioria dos sistemas possuem estruturas estáticas e estruturas dinâmicas. As estruturas estáticas podem ser modeladas pelos diagramas de classe e de objeto. As estruturas dinâmicas são modeladas pelos diagramas de estado, seqüência, colaboração e atividade. Os diagramas de componentes e execução são suportados pelo modelo funcional.

Apresentaremos algumas características dos diagramas existentes na UML:

2.3.4.1 Diagrama de caso de uso

É utilizado na demonstração de relacionamentos entre atores e casos de uso. Os atores representam o papel de uma entidade externa ao sistema, como um usuário, um hardware, ou um outro sistema. Os atores iniciam a comunicação com o sistema por meio dos casos de uso, os quais representam uma seqüência de ações que são executadas pelo sistema.

2.3.4.2 Diagrama de classe

É utilizado na demonstração da estrutura estática das classes de um sistema, cujas classes representam as “coisas” que são

5

10

(12)

gerenciadas pelo sistema que está sendo modelado. Uma classe pode se relacionar com outra por meio das:

Associações: classes conectadas entre si;

Dependências: uma classe depende de outra classe;

Especialização: uma classe é uma especialização de outra

classe;

Pacotes: classes que são agrupadas por possuírem

características similares.

No diagrama de classe, são apresentados todos esses relacionamentos e suas estruturas internas que são os atributos e as operações.

2.3.4.3 Diagrama de seqüência

Mostra o dinamismo existente entre a colaboração dos vários objetos de um sistema. A partir do diagrama de seqüência, é possível perceber a seqüência de mensagens que são enviadas entre os objetos, mostrando a interação entre

5

10

(13)

os objetos e o que acontecerá em um ponto especíﬁ co na execução do sistema.

2.3.4.4 Diagrama de colaboração

Ilustra de maneira semelhante ao diagrama de seqüência, o dinamismo existente na colaboração dos objetos. Em alguns casos, pode-se escolher em utilizar o diagrama de colaboração ou o diagrama de seqüência.

2.3.4.5 Diagrama de estado

O diagrama de estado funciona como um complemento para a descrição das classes, mostrando todos os estados possíveis em que o objeto de uma dada classe pode encontrar-se e apresentando quais são os eventos do sistema que provocam tais mudanças.

5

(14)

a 2ª r evis ão: 23 /04/0 7 // C orr eção: Már cio - 26/04/0 7 2.3.4.6 Diagrama de atividade

Foca o trabalho executado na implementação de um método e suas atividades em uma instância de um objeto. É uma variação do diagrama de estado, possuindo um propósito um pouco diferente que é o trabalho e as atividades a serem executadas e os seus resultados no que diz respeito à mudança de estado dos objetos.

2.3.4.7 Diagrama de componente

Mostra o sistema por um lado funcional em que são expostas as relações entre os seus componentes e a execução dos seus módulos durante a execução.

2.3.4.8 Diagrama de execução

Ilustra a arquitetura de hardware e software do sistema, juntamente com as conexões que são estabelecidas entre si. Especiﬁ ca os componentes executáveis e os objetos que são alocados para ilustrar e quais unidades serão executadas.

5

(15)

O uso de um tipo ou outro de diagrama depende na maioria das vezes do grau de detalhamento que é requerido para o desenvolvimento do sistema. Os diagramas mais utilizados são os de classe, caso de uso e o diagrama de seqüência. Para uma boa utilização da UML, é recomendado o uso de ferramentas CASE para o auxílio na construção de diagramas.

3 MODELO DE INFORMAÇÕES

ORGANIZACIONAIS E MODELO DECISÓRIO

O modelo de informações organizacionais é de vital importância para as organizações, no planejamento, desenvolvimento ou aquisição de sistemas de informação. Sem a elaboração desse documento, algumas organizações estão enfrentando prejuízos ﬁ nanceiros e pessoais, principalmente quando desejam a aquisição de um sistema de informação ou o seu desenvolvimento.

Como falamos anteriormente, os níveis de decisão organizacional obedecem a uma hierarquia que é padrão na maioria das organizações. O tipo de decisão que é tomado em cada nível requer diferentes graus de agregação de informações. Para tomar essas decisões, são necessárias informações sobre seus diversos tipos de produtos, as quais podem ser apresentadas por meio de relatórios, telas, entre outros.

O modelo de informações organizacionais descreve todas as informações necessárias para a gestão de atividades e negócios e essas informações devem atender a todos os requisitos funcionais, requeridos de um ou mais sistemas de informação. Possui como principal objetivo auxiliar a organização na aquisição de sistemas de informação, e contribuir para o processo de desenvolvimento ou manutenção de um projeto de sistemas de informação.

Essas informações estruturam-se em níveis, sendo: estratégicas, gerenciais e operacionais. As informações podem estar distribuídas em diversas funções organizacionais, tais

Um Sistema de Informações deve possuir todas as informações necessárias para a gestão de atividades e negócios de uma organização. Estas informações estão estruturadas nos níveis: estratégicos, gerenciais e operacionais. 5 10 15 20 25 30

(16)

como: comercial, logística, ﬁ nanceira, RH, jurídico, entre outros. Além disso, podem ser desmembradas e divididas em subsistemas.

Para a elaboração dessa atividade nas organizações, um documento em forma de tabela pode ser feito, no qual são descritas apenas as informações e, em outro, procedimentos de como construir informações necessárias.

Abaixo, temos um exemplo de um modelo de documento de informações organizacionais:

Função: Financeira

Nível de Informação Módulo: Contas a Receber

Estratégico - Valor total de contas a receber X valor total de contas a pagar;

- Percentual do valor de contas a receber X valor do ﬂ uxo de caixa.

Gerencial _{- Valor total de contas a receber;} - Quantidade de títulos pagos; - Quantidade de inadimplentes. Operacional - Nome do cliente;

- Valor do título; - Data de vencimento; - Data de pagamento; - Nome do banco.

É importante ressaltar que as informações devem-se integrar nos níveis, ou seja, para se obterem informações gerenciais e estratégicas, é necessária a existência das informações operacionais. O modelo de informações organizacionais pode conter informações que estão integradas nos seguintes tipos: convencional, personalizadas e oportunas. As informações personalizadas e oportunas facilitam o mapeamento do conhecimento organizacional, chamadas informações inteligentes.

5

10

(17)

a 2ª r evis ão: 23 /04/0 7 // C orr eção: Már cio - 26/04/0 7 3.1 Modelo Decisório

O modelo decisório contribui para o processo de tomada de decisão, tanto na ordem tática como na ordem estratégica. Busca fornecer informações e conhecimentos inteligentes, adequando-se às situações peculiares de cada organização.

Esses modelos estão interligados aos sistemas de informação, e as organizações necessitam deles, pois, com o seu auxílio, os gestores podem analisar os dados dos meios internos e externos, visando propor soluções importantes.

Vamos analisar alguns tipos de modelos decisórios existentes e observar suas particularidades.

3.1.1 Modelo convencional

O modelo convencional trata os dados para serem transformados em informações e, conseqüentemente, em conhecimento, com isso, alguns gestores podem tomar decisões de ordem mental ou executar ações de ordem física. Essas ações geram resultados que podem ser positivos ou negativos, existindo sempre uma retroalimentação do ciclo decisório.

5

10

(18)

Essa alimentação faz-se necessária por causa das mudanças internas e externas no ambiente, por exemplo: os clientes, fornecedores, movimentação bancária, entre outros.

Esse modelo decisório é mais indicado para decisões triviais e rotineiras, que não geram grandes impactos futuros.

3.1.2 Modelo dinâmico

Como nem sempre o modelo convencional atende completamente às necessidades das organizações, o modelo dinâmico foi apresentado com o intuito de fornecer informações, e não o tratamento de dados como é feito no modelo convencional.

As organizações nos dias de hoje devem ser dinâmicas, o mercado e a sociedade exigem esse dinamismo. Com isso, a tomada de decisões complexas é feita a todo o momento no processo de gestão e, diferentemente da produção, a gestão não é repetitiva nem estruturada. Essas decisões nem sempre são fáceis de serem tomadas, pois podem favorecer ou contrariar o resultado ﬁ nal do processo, acabando por prejudicá-lo. Algumas diﬁ culdades podem ser encontradas em três fases do processo decisório:

• Fase de investigação: Diﬁ culdades em identiﬁ car,

categorizar e deﬁ nir o problema;

• Fase de concepção: Diﬁ culdade em gerar, avaliar e

descrever alternativas para o desempenho;

• Fase de escolha da decisão: Diﬁ culdade em identiﬁ car

métodos de seleção, organizar e apresentar a informação. Por causa de todas as diﬁ culdades apontadas, faz-se necessário que as organizações apresentem modelos dinâmicos,

5

10

15

20

(19)

pois nem sempre os dados que estão armazenados são necessários para gerar informações e conhecimentos requeridos.

O maior desaﬁ o para implementar o modelo decisório dinâmico é a criação, modelagem e estruturação das informações, pois elas são muito importantes para a gestão das organizações que as utilizam.

4 QUALIDADE NO DESENVOLVIMENTO DE SOFTWARES

Hoje em dia, a qualidade é um diferencial para que as empresas possam alcançar boas vendas e atingir metas lucrativas, e um pré-requisito indispensável para que as empresas coloquem-se no mercado global.

Na área de desenvolvimento de software, existe uma grande necessidade de deﬁ nir o que realmente é qualidade. Abaixo, algumas deﬁ nições para qualidade:

• Qualidade é estar em concordância com os requisitos solicitados pelo cliente.

• Qualidade é prover satisfação aos desejos do cliente.

5

10

(20)

Segundo a NBR ISO 8402, qualidade é:

“A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer as necessidades implícitas e explícitas.”

• Entidade: é um produto que pode ser um bem ou

serviço;

• Necessidades explícitas: são as condições e objetivos

propostos pelo produto;

• Necessidades implícitas: são as diferenças entre usuários,

evoluções futuras, segurança e outras visões subjetivas.

4.1 Preocupações com a qualidade

Para o sucesso e sobrevivência no mercado de desenvolvimento de softwares, é indispensável que as empresas produzam softwares de boa qualidade. Para que isto seja possível, devemos levar em conta algumas observações:

Competitividade: o diferencial de um produto no mercado atual para que ele seja competitivo é a sua qualidade, pois os usuários não querem apenas saber que a empresa fale que possui qualidade, mas que o demonstre por meio de certiﬁ cados de renome.

Essencial para sobrevivência: como grande parte dos clientes pede por qualidade no desenvolvimento de produtos, as empresas devem possuir a habilidade de sobreviver ao mercado competitivo.

Custo/benefício: um bom sistema é responsável pelo aumento da produtividade além de promover as reduções dos custos com correções de erros.

4.2 Qualidade no desenvolvimento de software

A qualidade de um software está diretamente ligada ao processo utilizado tanto na modelagem, como no seu

5

10

15

20

(21)

desenvolvimento. É muito importante a organização fazer um levantamento de necessidades e requisitos, pois com isso ﬁ ca bem mais fácil de obter um produto consistente.

Existem alguns objetivos que devem ser cumpridos para a produção de um software de qualidade:

• Utilizar as melhores práticas existentes na engenharia de software;

• Equipe formada por proﬁ ssionais altamente treinados e responsáveis;

• Priorizar a correção de erros no momento em que foram detectados.

Para proporcionar o alcance de todos os objetivos citados anteriormente, existem padrões a serem seguidos e responsáveis pela criação de normas que garantam a qualidade dos softwares desenvolvidos.

A ISO (Organização Internacional de Padrões) criou a norma ISO/IEC 9126, formada por um conjunto de características que devem ser observadas em um software, para que ele seja considerado um “software de qualidade”. Estas características estão divididas em seis grupos, os quais são formados por subgrupos.

A tabela abaixo ilustra os grupos e subgrupos que compõem a norma ISO/IEC 9126:

Característica Subcaracterística Pergunta-chave para a _{subcaracterística}

Funcionalidade

(satisfaz as necessidades?)

Adequação Propõe-se a fazer o que é _apropriado? Acurácia Faz o que foi proposto de forma _correta? Interoperabilidade Interage com os sistemas _{especiﬁ cados?}

Conformidade Está de acordo com as normas, leis, _{e outros?} Segurança de Evita acesso não autorizado aos

5

10

15

(22)

a 2ª r evis ão: 23 /04/0 7 // C orr eção: Már cio - 26/04/0 7 Conﬁ abilidade (é imune a falhas?)

Maturidade Com que freqüência apresenta _falhas? Tolerância a falhas Ocorrendo falhas, como ele reage? Recuperabilidade É capaz de recuperar dados em caso _{de falha?}

Usabilidade

(é fácil de usar?)

Inteligibilidade É fácil entender o conceito e a _aplicação? Aprensibilidade É fácil de aprender a usar? Operacionalidade É fácil de operar e controlar?

Eﬁ ciência

(é rápido e “enxuto”?)

Tempo Qual é o tempo de resposta, a _{velocidade de execução?} Recursos Quanto recurso usa? Durante _{quanto tempo?}

Manutenibilidade

(é fácil de modiﬁ car?)

Analisabilidade É fácil de encontrar uma falha, _{quando ocorre?} Modiﬁ cabilidade É fácil de modiﬁ car e adaptar? Estabilidade Há grande risco quando se fazem _{alterações?} Testabilidade É fácil testar quando se fazem _{alterações?}

Portabilidade

(é facil de usar em outro ambiente?)

Adaptabilidade É fácil de adaptar-se a outros _ambientes? Capac. para ser

instalado É fácil de instalar-se em outros ambientes? Conformidade Está de acordo com padrões de _{portabilidade?} Capac. Para

substituir É fácil de usar para substituir outro? 4.3 Implementação de um sistema de

qualidade

Um software de qualidade é o resultado da aplicação de grandes esforços e para o aumento na qualidade é necessário o envolvimento de aspectos de caráter técnico e cultural, pois o sistema a ser melhorado é formado tanto por tecnologia quanto por pessoas.

Características técnicas: Desenvolvimento de padrões e

técnicas para a aplicação de qualidade em todos os processos de desenvolvimento.

(23)

Características culturais: A aplicação da qualidade no

processo de desenvolvimento deve ser aceito e compreendido por toda a equipe envolvida no processo.

Para iniciar um sistema de qualidade, devemos preparar políticas de qualidade, as quais devem ser declaradas e publicadas, proporcionando o entendimento e a implementação em todos os setores que estão envolvidos no processo de desenvolvimento.

É necessário o estabelecimento de uma equipe responsável por:

• Deﬁ nições de estratégias e metas;

• Estabelecimento de um controle de aumento e melhoramento da qualidade, sempre revendo sua performance;

• Autorização e aprovação de gastos para o programa de qualidade;

• Suporte de alto nível para o programa de qualidade; • Treinamento para o auxílio ao programa de qualidade; • Revisão periódica de procedimentos padrões;

• Estabelecimento do programa com o intuito de medir o processo de desenvolvimento do software, seus produtos e serviços.

4.4 O futuro da qualidade

O futuro da qualidade estará focado no marketing, vendas e suporte, pois está diretamente ligado à satisfação do cliente. De nada adianta uma empresa conseguir várias certiﬁ cações internacionais, se continua desenvolvendo sistemas da mesma forma e recebendo as mesmas reclamações. Por isso, é importante a ênfase na satisfação do cliente, pois o seu impacto será maior do que os procedimentos que são adotados no desenvolvimento de software.

Um software de qualidade depende do envolvimento de aspectos de caráter técnico e cultural, pois o sistema é formado tanto por tecnologia quanto por pessoas.

5

10

15

20