Fundamentos

de Sistemas de
Informação
 Fundamentos
de Sistemas de Informação

1ª edição
2017
Unidade 4
Desenvolvimento de Sistemas

Para iniciar seus estudos

4
Caro aluno, seja bem-vindo à quarta unidade do nosso curso!
Conhecer os principais Sistemas de Informação, distinguir suas principais
características e ter capacidade para sugerir e orientar aquisições são,
de fato, habilidades fundamentais para alguém do ramo de Sistemas de
Informação. Sem elas, o desempenho do profissional ficaria comprome-
tido e sua reputação arranhada com o tempo.
Ocorre, no entanto, que o conhecimento de aspectos relacionados ao
desenvolvimento dos sistemas também é essencial nessa atividade.
Nesse sentido, esta unidade aborda, além desse tema, o perfil do profis-
sional envolvido na criação de uma ferramenta computacional e o ciclo
de vida de um sistema.
Mesmo que desenvolver programas não seja sua prioridade imediata, o
conhecimento do seu processo de criação será absolutamente indispensável
para que seus contatos com a equipe de desenvolvimento sejam exitosos.
Então, sem mais demora, iniciamos nossa caminhada nesta unidade.
Bom estudo!

Objetivos de Aprendizagem

• O aluno será capaz de compreender conceitos principais, profis-

sionais envolvidos, carreiras em Sistemas de Informação, ciclo de
vida do software.

3
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

Tópicos de estudo
Iniciamos, nesta unidade, nosso estudo sobre desenvolvimento de sistemas. Embora as oportunidades para a reali-
zação profissional em Tecnologia da Informação sejam amplas, é na atividade de desenvolvimento de sistemas que
boa parte dos envolvidos baseiam suas carreiras. Há que se registrar, desde já, que “desenvolver sistemas” não se
restringe à programação de computadores. Mais do que isso, o sucesso nessa atividade requer domínio do processo
de construção de uma ferramenta computacional, que inclui levantamento de requisitos, desenho da solução,
transformação do desenho em código de programa, testes e a efetiva implantação da aplicação.
No entanto, antes de nos aventurarmos pelo ciclo de vida de um software, estudaremos juntos os conceitos bási-
cos de desenvolvimento de sistemas e um pouco do que se espera de um profissional de TI.
Preparado? Boa leitura!

4.1 Conceitos fundamentais

Desenvolver softwares não se restringe ao uso de uma linguagem de programação para criar uma aplicação de
computador. Embora a efetiva criação do programa nessa etapa seja importante do processo que abordaremos,
ela não se completa de forma isolada.
Para que possamos entender como um processo de desenvolvimento de software efetiva-se, é necessário que
entendamos as partes que compõem seu conceito, sempre considerando o âmbito da Engenharia de Software
em suas caracterizações.

Glossário

Engenharia de software: O IEEE elaborou a seguinte definição para engenharia de software:

(1) A aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvol-
vimento, na operação e na manutenção de software; isto é, a aplicação de engenharia ao
software. (2) O estudo de abordagens como definido em (1) (PRESSMAN; MAXIM, 2016).

Iniciamos nossa abordagem pela caracterização de processo. Pressman e Maxim (2016) ensinam que processo
é um conjunto de atividades, ações e tarefas realizadas na criação de algum artefato. Embora correta, essa defi-
nição nos parece bastante genérica e pode ser aplicada a quase a totalidade dos ramos de atividade humana. A
figura a seguir ilustra, como exemplo, o processo de montagem de um automóvel.

4
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

Figura 4.1 - Processo de montagem de um automóvel.

Legenda: Imagem com ilustração de uma linha de produção de automóveis.

Fonte: Plataforma Deduca (2018).

Nosso trabalho de definição dos termos avança com a retomada da caracterização de software, que já foi defi-
nido em unidade anterior. Embora seja bastante comum considerarmos software como sinônimo de programa
de computador, nossa conceituação não pode contentar-se apenas com isso.
Sommerville (2010) amplia os limites da expressão e afirma que software não é apenas um programa, mas tam-
bém todos os dados de documentação e configuração associados necessários para que o programa opere cor-
retamente.
A criação de um produto de software não se restringe, definitivamente, a um ato isolado. A adoção de um pro-
cesso bem estruturado e dominado pela equipe tem o potencial de proporcionar segurança e economia de
recursos durante a execução do projeto. Por sua vez, um processo caótico, no qual etapas e funções não são bem
definidas, oferece alta probabilidade de insucesso do projeto.
Existem diversas conceituações relacionadas ao processo de software, mas podemos defini-lo como uma sequ-
ência de etapas que objetivam a produção e a manutenção de um software. Nessas etapas, incidem padrões,
verificam-se entradas e saídas e verifica-se o inter-relacionamento de recursos humanos e materiais.
Por causa de sua complexidade e abrangência, foram criados diversos modelos de processo de desenvolvimento
de software, cada um com suas particularidades e facilidades de aplicação em contextos específicos. Dois dos
mais conhecidos incluem:
• Processo evolucionário
Como o nome sugere, esse processo baseia-se na evolução de uma implementação inicial de um produto de sof-
tware. A cada ciclo evolutivo, versões mais aprimoradas do sistema são oferecidas ao usuário, até que o produto
desejado e nas especificações corretas esteja pronto. Sommerville (2010) apresenta dois tipos fundamentais de
processo evolucionário:
a. Desenvolvimento exploratório: nesta modalidade, o profissional envolvido deve entrar em sintonia com
o cliente para explorar os requisitos e promover a entrega do sistema final. O desenvolvimento segue
um padrão bastante racional: começa com as partes do sistema que já são compreendidas e evolui para
versões mais bem-acabadas por meio da adição de novas funcionalidades sugeridas pelo cliente e/ou
usuário.

5
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

b. Prototipação: é uma versão inicial de um sistema de software usada para demonstrar conceitos, expe-
rimentar opções de projeto e, geralmente, conhecer mais sobre o problema e suas possíveis soluções
(SOMMERVILLE, 2010). O protótipo de uma interface de usuário, por exemplo, pode ser desenvolvido para
que o usuário tenha parâmetro para decidir sobre localização de campos e menus.
O desenvolvimento do protótipo deve ser rápido, a fim de não comprometer prazos. Ele pode ser usado na fase de
requisitos, para ajudar na descoberta e validação destes; na fase de projeto; e na fase de testes.
Por fim, é sempre importante alertar o cliente que o protótipo não corresponde à versão final do produto.
Essa abordagem de desenvolvimento coloca o cliente como figura ativa do processo de desenvolvimento e mini-
miza a ocorrência de mal-entendidos entre ele e a equipe de desenvolvimento. No entanto, a maior efetividade
desse paradigma em relação a outros (o modelo em cascata, por exemplo) também dá-se pelo fato de existirem
mais oportunidades para que o cliente mude de ideia em relação a determinada funcionalidade do sistema sem
que cause grande prejuízo financeiro e de tempo.

Se as etapas para a construção de um software já foram definidas e testadas ao longo do

tempo, será então coerente afirmar que, ao segui-las com rigidez e assertividade, um profis-
sional de TI conseguirá, em todos os casos, concluir com êxito seu projeto de criação de um
sistema computacional?

Essa abordagem, aliás, inspirou o surgimento de metodologias ágeis de desenvolvimento, incluindo o Extreme
Programming. É justamente sobre elas que lançaremos luz em nosso próximo item do conteúdo.
• Processo Ágil de Desenvolvimento
Em sua essência, os métodos ágeis têm menos ênfase nas definições de atividades e mais ênfase nos fatores
humanos do desenvolvimento. São claramente mais adequados à natureza do trabalho de profissionais de TI,
já que se baseiam na necessidade de sucessivas revisões na obra. Atividades intelectuais não são executadas de
forma linear e não são determinísticas.
Durante a construção de um software, há que se considerar uma infinidade de detalhes que nem sempre são lem-
brados logo na primeira oportunidade. Da mesma forma, ao tratar pela primeira vez das funcionalidades que deseja
para o produto, o cliente ainda não as conhece por completo e não consegue ter visão global do que necessita. Que
tal darmos a ele a oportunidade de aprender e mudar de ideia ao longo do processo de desenvolvimento?
Na Unidade 6 do nosso curso, quando tratarmos especificamente de requisitos de software, teremos oportuni-
dade de constatar que o comportamento das condições necessárias para que um sistema exista é bastante volátil
e altera-se com muita facilidade. Sabedores desse fato, os criadores do XP o adequaram para suportar tal incons-
tância.
Outra característica marcante dessa metodologia é sua adequação para equipes pequenas, com não mais do que
10 membros. É sempre bom lembrarmos que o cliente (sim, o cliente) também faz parte da equipe e, como todos
os demais, é um elemento que tem direitos e deveres.
Outra marca do XP é sua indicação para projetos implementados em linguagens orientadas a objetos. Pela utili-
zação desse paradigma, é possível, desde o começo, entregar ao cliente partes executáveis do produto para que

6
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

ele possa aprender sobre a solução que se desenha e registrar suas impressões para a equipe. A essa comunica-
ção em duas vias e em curtos períodos damos o nome de feedback.
Embora parte da literatura sobre o XP liste cinco valores fundamentais da metodologia, descreveremos quatro
deles.
• Feedback: baseia-se na comunicação entre cliente e equipe à medida que o sistema cresce em funciona-
lidades. Funciona assim:
(i) A equipe entrega ao cliente parte executável do sistema.
(ii) O cliente utiliza, revisa e eventualmente muda de ideia em relação a certas funcionalidades já imple-
mentadas.
(iii) De posse dessas informações, a equipe faz a devida readequação no sistema (ou na parte já imple-
mentada), inclui mais funcionalidades e retorna-o ao cliente, que repete a operação anterior.
• Comunicação: por meio de suas práticas, o XP visa promover a estreita comunicação entre membros da
equipe e entre a equipe e o cliente. O esforço para tornar o cliente parte efetiva da equipe procura evitar
que o desenvolvimento do projeto ou mesmo a implementação de funcionalidades sejam feitos de forma
especulativa. As reuniões diárias entre membros da equipe são, por exemplo, providência efetiva no esta-
belecimento da comunicação.
• Simplicidade: é comum entre profissionais de TI o raciocínio de que implementar funções que o cliente
não solicitou e tornar mais complexas as que ele, de fato, pediu, é um meio de causar boa impressão. O XP,
no entanto, prega que a simplicidade é elemento-chave para o desenvolvimento de sistemas eficientes,
objetivos e perfeitamente adequados às necessidades dos clientes.
• Coragem: uma das práticas do XP incentiva a permissão para que todos os membros da equipe tenham
acesso pleno e irrestrito ao código que está sendo construído. Outra prática estimula que o programa,
mesmo pronto e funcional, seja alterado para acomodar as regras de codificação da linguagem Java.
A implantação de uma nova metodologia de desenvolvimento, bem diferente da tradicional e baseada na intensa
interação entre cliente e equipe, pode gerar desconfiança no alto escalão da empresa. Bem, já temos argumen-
tos suficientes para entender que a coragem deve ser um dos fundamentos do XP, não acha?

De acordo com o documento intitulado “Manifesto Ágil”, os métodos ágeis valorizam:

• indivíduos e interação entre eles mais que processos e ferramentas,
• software em funcionamento mais que documentação abrangente,
• colaboração com o cliente mais que negociação de contratos,
• responder a mudanças mais que seguir um plano.
Disponível em: <http://www.manifestoagil.com.br/>

7
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

Essas bases do XP são elementos motivadores das práticas adotadas pela metodologia. Uma delas é a prática do
cliente presente. Ela assume o papel principal no processo de quebra de paradigmas proposto pelo XP. Afinal,
não era considerada como válida – sequer aconselhável – a presença efetiva do cliente durante o desenvolvi-
mento de um programa. Via de regra, a participação dele no projeto dava-se apenas no momento da coleta de
requisitos e na implantação do sistema.
O modelo ágil, no entanto, sugere que o cliente deve conduzir o desenvolvimento a partir da utilização do sis-
tema e que sua proximidade da equipe viabiliza essa condução. Essa prática nos revela que:
• O distanciamento é natural entre equipe e cliente.
• A proximidade fomenta o feedback, torna-o mais constante e evita mudanças bruscas na condução do
projeto.
• Cliente próximo evita trabalho especulativo.
• Quanto mais distante o cliente estiver, mais difícil será demonstrar o valor do serviço.
• Para ter um cliente mais presente, deve-se enfrentar o desafio cultural, bem como a falta de disponibili-
dade dele e a distância entre ele e a equipe.
Outra prática importante e de fácil operacionalização é a programação em par.
Desenvolvedores não trabalham sozinhos em um projeto XP. Você também pode achar pouco convencional, mas
na programação em par, dois programadores trabalham em um mesmo problema, ao mesmo tempo. Aliás, quem
foi que disse que o XP é convencional?
Em determinado momento, o condutor assume o teclado e o navegador acompanha o trabalho, fazendo revi-
sões e sugestões. Em outro, há revezamento de papéis. As correções são feitas no momento da programação,
evitando que pequenos erros se tornem grandes problemas no futuro.
A condução da programação deve ser realizada, em tempos alternados, pelos dois programadores. Eles devem
alternar-se, escrevendo código a cada 15 ou 20 minutos. Conveniente, não acha?
Feitas as considerações sobre esses processos (ou modelos) de desenvolvimento de software, é esperado que
você consiga eleger o que melhor se adeque ao perfil da equipe, dos recursos e do problema que se apresenta. E
lembre-se: os modelos não são mutuamente exclusivos e a combinação de suas melhores características é um
meio de aumentar as chances de bons resultados.
Passemos agora para a abordagem de alguns perfis profissionais em nosso ramo de atividade.

4.2 Perfis profissionais em Sistemas de Informação

Cumpre iniciar este item com um breve conselho: duvide de quem afirma saber absolutamente tudo a respeito de
Tecnologia da Informação! Pela complexidade e variedade dos temas relacionados a essa área, fica muito difícil
acreditar que isso seja possível, ainda mais quando se considera a necessidade sempre urgente de atualizações
naquilo que se imagina conhecer.
Por isso, não é de se espantar que a TI abrigue atualmente tantos perfis e funções em seus quadros profissionais.
Como temos afirmado, não é apenas de desenvolvedores (antes chamados programadores) que vive a área de
Sistemas de Informação. Se desenvolver programas não é sua maior habilidade, não desanime. A TI ainda assim
tem guardado um bom lugar para você.

8
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

Não se trata, contudo, de descrever e classificar exaustivamente cada uma das funções da área. Ao invés disso,
esta parte do nosso conteúdo deverá lhe servir como um delineador de perfis de pessoas que poderão fazer parte
do seu convívio profissional, seja como colega de trabalho, seja como alguém que temporariamente dividirá seu
tempo em um projeto específico.
Comecemos pela descrição de uma equipe de trabalho típica da metodologia Extreme Programming.
É bem verdade que as metodologias ágeis, de modo geral, estimulam a convivência de habilidades diversas em
sua equipe. Em outras palavras, elas buscam não promover a especialização como meio para o sucesso da equipe.
Mesmo assim, é preciso definir funções entre os participantes do projeto, inclusive para fins de organização da
equipe, como segue:
Gerente do projeto: tem a responsabilidade de conduzir as etapas do projeto, tratar diretamente com o cliente
e tratar dos assuntos administrativos. Embora o cliente idealmente faça parte da equipe de desenvolvimento, é
com esse gerente que ele terá contato com mais frequência.
Coach: compete a ele a escolha e a manutenção da tecnologia que será utilizada no desenvolvimento do pro-
duto. Deve ser experiente e conhecedor das habilidades técnicas da equipe para que a linguagem de programa-
ção seja de domínio comum na equipe.
Analista de teste: este profissional escreve os testes que serão realizados no produto (ou em parte dele) junto
com o cliente. Ele também é responsável por enviar ao pessoal de desenvolvimento os resultados dos testes
como meio de promover o feedback.
Redator técnico: documentar é preciso, mas esse processo não pode tornar-se motivo para morosidade do
desenvolvimento. É com a missão de livrar a equipe da documentação que o redator técnico entra em cena.
Desenvolvedor: antes chamado simplesmente de programador, este profissional é responsável, inclusive, por
levantar requisitos junto ao cliente, esboçar a solução e codificar o programa.
Tanto na condição de desenvolvedor quanto em qualquer outra que você esteja engajado no projeto do Sistema
de informação, será absolutamente comum o contato com o usuário e/ou o cliente. De tão importantes no con-
texto, esses perfis merecem desdobramentos.
Tipicamente, o cliente é o primeiro e mais importante componente do projeto. Para fins de conceituação, trata-
-se da pessoa ou do grupo de pessoas para quem o sistema é construído. É ele que define as características do
sistema e tem o direito de não pagar se não ficar satisfeito com o produto.
Sim, há grandes possibilidades de mal-entendidos entre o profissional que cuida do desenvolvimento do sistema
e o cliente. Problemas de comunicação são frequentes.
Outro elemento-chave no contexto é o usuário. A comunicação com ele é tão importante que se sugere que o
usuário seja membro da equipe de projeto. Caso não seja possível a comunicação direta com o usuário, deve-se
redobrar a atenção na documentação do sistema.
É fato que usuários têm perfis heterogêneos e que é um erro presumir que todos são iguais. Vejamos alguns dos
seus tipos:
• Usuários operativos: são funcionários burocratas, operacionais e até mesmo administradores que terão
contato diário com o sistema. Estão interessados em qual tipo de entrada terão que realizar ou como
reverter uma entrada incorreta. Tendem a ter uma visão local e conhecer apenas a tarefa específica que
executam. Podem ter dificuldades em explicar como suas atividades encaixam-se na organização ou qual
a finalidade da organização.
• Usuários supervisores: são funcionários em atividades de supervisão. Geralmente, chefiam um grupo
de usuários operativos, sendo responsáveis por seus desempenhos. Não raro, já foram usuários operati-

9
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

vos um dia e acabaram sendo promovidos. Por isso, conhecem o serviço do subordinado. Têm interesse
em aumentar o volume de trabalho realizado e reduzir custos e erros por meio do sistema. Esse perfil de
usuário pode considerar o sistema como um meio de reduzir a quantidade de usuários operativos ou de
evitar o aumento desse número quando o volume de trabalho crescer. Nesse contexto, o analista (você,
no caso) pode ser envolvido em disputas políticas.
• Usuários executivos: geralmente, não se envolvem diretamente com o projeto. É a autoridade financeira
para as necessidades do projeto e, na maioria dos casos, não foram usuários operativos ou esqueceram-
-se dessa experiência. Seu interesse no sistema gira em torno de aspectos estratégicos de lucros e per-
das a longo prazo, incluindo novos mercados, novos produtos e novas vantagens competitivas. Eles são
interessados na visão global do sistema e desprezam detalhes, principalmente aqueles relacionados à
execução do projeto.
Quanto mais elevado o nível do executivo, menos provável que conheça ou se interesse por tecnologia. Você deve
concentrar as discussões com ele nas características essenciais do sistema. As metas e prioridades da gerência
podem ser conflitantes com as dos usuários.
E lembre-se sempre: gerentes têm diferentes opiniões e visões e competem entre si. Alguns serão favoráveis,
outros serão contra ou omissos em relação ao novo sistema. As opiniões podem mudar ao longo do desenvolvi-
mento do projeto.
Embora a caracterização dos usuários por tipo de função já cubra a maioria dos perfis que poderemos encontrar,
outra classificação pode ser bastante útil: por nível de experiência.
• Usuário amador: sempre pronto a dizer: “Não entendo nada de computador!”. Normalmente, tem longa
experiência de trabalho e começou suas atividades antes do advento do computador. Pode até ser jovem,
mas acha o computador tedioso, intimidante ou irrelevante. Seu verdadeiro problema é a dificuldade em
compreender a linguagem do profissional. Se esse usuário não entender o sistema, há grande possibili-
dade de insatisfação e boicote.
• Usuário novato: geralmente, já participou de projetos anteriores ou já escreveu alguns “programinhas”.
Com alguma frequência, acha que sabe exatamente o que quer que o sistema faça e está sempre dis-
posto a apontar todos os erros do profissional de TI. Pode envolver-se demais em discussão de tecnologia
sem estar apto para isso.
• Usuário perito: de fato, conhece Sistemas de Informação e tecnologia de computadores e geralmente
colabora efetivamente com o projeto. Considere tê-lo como aliado como multiplicador do projeto junto
aos demais usuários.
Em relação aos profissionais de TI que podem estar envolvidos no projeto do Sistema de Informação, apresen-
tamos no início deste item o perfil do pessoal do desenvolvimento ágil. Vejamos agora algumas das funções
tradicionais em um projeto:
• Analista de Sistemas: membro essencial de qualquer projeto de desenvolvimento de sistemas. Ele é
comparado a um arqueólogo e escriba, pois desvenda os anseios do cliente e documenta especificações.
Deve ter perfil inovador e explorar novas maneiras para o cliente conduzir seu negócio ou atividade. É
esperado que seja diplomático e hábil negociador, já que pode ver-se diante de desentendimentos entre
os diversos tipos de usuários. Não raramente será o líder técnico do projeto. Enfim, um analista precisa ter
habilidade com as pessoas, conhecimento de aplicações e habilidade em tecnologia.
• Pessoal de operação: responsável por tarefas indispensáveis na continuidade dos serviços no setor de TI,
tais como instalação e manutenção de redes, segurança de hardware, backups, manipulação e manuten-
ção de impressoras, entre outras. Tem pouco contato com o analista, mas eventuais restrições técnicas
colocadas pelo pessoal de operação devem ser conhecidas e consideradas.

10
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

É muito provável que você já tenha tido contato com alguma outra nomenclatura de funções e cargos em TI.
Arquiteto de software, engenheiro de software, administrador de bancos de dados certamente são algumas des-
sas denominações que você já conhece. Vale a pena conhecê-las melhor.

Uma grande variedade de funções e especialidades surgiu nos últimos anos no mundo da
TI. Reportagem da Revista Exame, disponível em <https://exame.abril.com.br/carreira/os-7-
-profissionais-mais-disputados-na-area-de-ti/> (Acesso em: 23 jan. 2018) analisa algumas
das mais disputadas habilidades que um profissional de TI deve reunir para ter êxito para ser
bem-sucedido.
Assista ao vídeo disponibilizado pelo canal Olhar Digital, disponível em <https://www.you-
tube.com/watch?v=ZqkARSPXUJI> (Acesso em: 23 jan. 2018). As profissões do futuro são
resumidamente descritas em pouco menos de seis minutos.

Que tal uma olhada mais detida em um dos (ainda) principais modelos de desenvolvimento de software? Então,
sigamos com o ciclo de vida tradicional de um software.

4.3 Ciclo de vida do software

Embora a expressão “ciclo de vida do software” possa ser aplicada a qualquer processo de desenvolvimento, é ao
modelo em cascata que ele é associado com mais frequência. Esse modelo é o mais tradicional e, embora venha
sendo alvo de críticas, ainda tem lugar garantido entre os preferidos das empresas de desenvolvimento.
A figura a seguir mostra a representação das fases do modelo em cascata.

11
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

Figura 4.2 - Representação das fases do modelo em cascata.

Requisitos

Projeto

Implementação

Testes

Manutenção

Fonte: Elaborada pelo autor (2018).

Note que uma fase do processo depende do resultado ou do produto gerado pela fase anterior. As setas de retro-
alimentação, dispostas no sentido contrário à cascata, indicam a possibilidade de retorno às fases anteriores,
considerando nelas a ocorrência de falhas. Em outras palavras, o retrocesso a uma fase anterior serve, em tese,
para sanar problemas que, se levados adiante, acarretariam mais prejuízo ao desenvolvimento.
Para que a proposta de ensino desta unidade seja contemplada, cada uma das fases do modelo será descrita
sucintamente.

4.3.1 Requisitos

A fase de requisitos de software preocupa-se com descoberta, análise, especificação e validação das proprieda-
des que devem ser apresentadas para resolver tarefas relacionadas ao software que será desenvolvido. Requisitos
são as condições necessárias para que determinado evento aconteça. Tome como exemplo uma aula presencial.
Para que ela aconteça, é necessária a presença de professor, alunos, lousa, giz, carteiras. Todos esses itens for-
mam o conjunto de requisitos da aula. No desenvolvimento de software, acontece o mesmo. Além das funções
que desempenhará, fazem parte dos requisitos de um software as restrições às quais ele estará sujeito. Exemplos
dessas restrições incluem questões ligadas ao orçamento disponível ou ao armazenamento de dados.

O projeto de um software fica vulnerável quando o levantamento dos requisitos é executado

de forma inapropriada. Caso uma falha seja cometida na fase de levantamento dos requi-
sitos do produto, ela deverá propagar-se nas fases seguintes de projeto e implementação.
Assim, quanto antes a falha for corrigida, menos dispendioso será seu reparo.

12
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

4.3.2 Projeto

Uma vez levantados, analisados, especificados e validados os requisitos, o processo deverá nos levar ao desenho
do produto. Se os requisitos nos mostram o que o sistema deverá fazer, o projeto deverá refletir como ele o fará.
Por meio do projeto, os requisitos são refinados de modo a tornarem-se aptos a serem transformados em pro-
grama. O trabalho principal de um projetista é o de decompor o produto em módulos, que podem ser conceitu-
ados como blocos de código que se comunicam com outros blocos por meio de interfaces.

4.3.3 Implementação

É na implementação que o produto se torna palpável e pode ser apresentado ao cliente. A correta tradução dos
requisitos mais uma vez estará sendo colocada em teste, já que as funcionalidades e restrições se tornam “visí-
veis” agora. Como estratégia de implementação, a equipe poderá dividir o trabalho de forma que cada progra-
mador (ou um pequeno grupo deles) fique responsável por um módulo do sistema. Idealmente, a documentação
gerada pela fase de projeto deve servir como principal embasamento para a codificação, o que não afasta a
necessidade de novas consultas ao cliente e à equipe de projetistas.

4.3.4 Testes

Aplicar testes significa executar um programa para que defeitos sejam descobertos. Embora não se trate de asse-
gurar que o código está perfeito, a confiança no produto aumenta bastante conforme a qualidade dos testes
aplicados. O processo inclui planejamento, elaboração de casos de teste, a efetiva execução do programa e a
análise dos resultados.
Em que pese a existência de outras igualmente importantes, é nas técnicas funcional e estrutural que os testa-
dores mais se apóiam. A primeira baseia-se nas funções do software para a geração dos requisitos de teste e a
segunda baseia-se no conhecimento da estrutura interna (ou implementação) do programa.

4.3.5 Manutenção

Com o produto implementado, testado e disponibilizado ao cliente, chega ao fim o trabalho da equipe, certo?
Ainda não!
Embora espere-se que o software inicialmente atenda aos requisitos colocados pelo usuário, o produto deverá
sofrer alterações e evoluir durante sua utilização. Defeitos não detectados na fase de teste também se manifes-
tarão e tudo isso requer manutenção.
Embora os esforços durante o desenvolvimento tendam a gerar um produto próximo do ideal, não se pode abrir
mão da manutenção como parte integrante do ciclo de vida do produto.
Os dois tipos mais comuns de manutenção incluem manutenção corretiva, que corrigirá problemas detectados
durante a plena utilização do programa; e manutenção perfectiva, que irá aprimorar funções já existentes ou
incluir outras novas.

13
 Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas

Terminamos nosso estudo sobre processo de desenvolvimento de sistemas e nossa abordagem dos principais
perfis profissionais em um ambiente de criação de software. Esperamos que o conteúdo aqui tratado seja apro-
priado e útil em sua vida profissional. Bom senso e bom nível de percepção no trato com os usuários e clientes
certamente serão fundamentais para que você se torne uma boa referência nos projetos dos quais participar.
Esmere-se nas leituras adicionais, na resolução dos exercícios e até nosso próximo encontro!

14
 Considerações finais
Nesta unidade, você teve contato com alguns dos principais processos de
desenvolvimento de sistemas e com o perfil de profissionais que atuam
no ramo. Em resumo, estudamos:
Conceitos fundamentais de desenvolvimento de sistemas: neste item,
tratamos do desenvolvimento de sistemas como a sequência de passos
que visam à produção e manutenção de um software e que se inter-rela-
cionam com recursos (humanos e materiais), padrões, entradas e saídas e
com a própria estrutura da organização.
Nesse contexto, focamos em dois métodos de desenvolvimento bas-
tante utilizados nos dias atuais, quais sejam, o processo evolucionário e
o Extreme Programming. O processo evolucionário, como o próprio nome
sugere, baseia-se na evolução de uma implementação inicial de um pro-
duto de software. A cada ciclo evolutivo, versões mais aprimoradas do sis-
tema são oferecidas ao usuário, até que o produto desejado e nas especi-
ficações corretas esteja pronto.
O Extreme Programming (XP) é uma metodologia ágil de desenvolvi-
mento, adequada para projetos que possuem requisitos que se alteram
constantemente, para equipes pequenas e para a construção de progra-
mas orientados a objetos. É indicado também para ocasiões em que se
deseja partes executáveis do programa logo no início do desenvolvimento
e que ganhem novas funcionalidades assim que o projeto avança.
O XP apoia-se em quatro pilares para atingir seus objetivos: feedback,
comunicação, simplicidade e coragem e duas das suas principais práticas
incluem o cliente presente e a programação em par.
Perfis profissionais em Sistemas de Informação: a grande variedade de
habilidades que se requer de um profissional acaba gerando uma miríade
de perfis desejados para atuação em TI. Neste item, tratamos de alguns
perfis de pessoas envolvidas em projetos, com ênfase em clientes/usuá-
rios. No entanto, começamos a abordagem do tema com a descrição dos
componentes de uma equipe típica do XP. Ela é composta por gerente do
projeto, coach, analista de teste, redator técnico e desenvolvedor.
A necessidade de estabelecer uma boa comunicação com usuários e
cliente será muito frequente em qualquer projeto. O cliente é peça funda-
mental na definição das características do sistema e tem o direito de não

15
pagar se não ficar satisfeito com o produto. Por sua vez, o usuário deverá
operar diretamente o sistema e sua variedade de perfis pode ser agrupada
em usuários operativos, usuários supervisores e usuários executivos. Além
disso, pelo seu nível de conhecimento, costuma-se classificá-los como
usuário amador, novato e perito.
O Analista de Sistemas é peça essencial de qualquer projeto de desenvol-
vimento de sistemas e deve conduzir a atividade do cliente na busca por
inovações em seus processos de negócios. É esperado que seja diplomá-
tico e hábil negociador, além de conhecedor de tecnologia.
Ciclo de vida do software: esta expressão é mais comumente associada
ao modelo tradicional ou em cascata. Ele é composto pelas fases de requi-
sito, projeto, implementação, testes e manutenção, nessa ordem. A fase
de requisitos de software preocupa-se com descoberta, análise, especi-
ficação e validação das propriedades que devem ser apresentadas para
resolver tarefas relacionadas ao software que será desenvolvido. Uma vez
levantados, analisados, especificados e validados os requisitos, o processo
deverá nos levar ao desenho do produto ou projeto de software. Na fase
de implementação, o projeto é transformado em linguagem de progra-
mação para que, de fato, o produto passe a ser executável. Com a parte
ou o todo pronto, o processo passa para a fase de testes. Aplicar testes
significa executar um programa para que defeitos sejam descobertos.
Embora não se trate de assegurar que o código está perfeito, a confiança
no produto aumenta bastante conforme a qualidade dos testes aplicados.
O processo inclui planejamento, elaboração de casos de teste, a efetiva
execução do programa e a análise dos resultados.

16
 Referências bibliográficas
PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de Software - Uma
Abordagem Profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 968p.
ISBN 9788580555332.

SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: A. Wesley

Publishing Company, 2010. 552p.

17