Unidade 1_Engenharia de Software

Prévia do material em texto

Introdução 
Unidade 1 
Engenharia de software 
 
A unidade 1 da disciplina Sistemas de Informação irá abordar a engenharia 
de software. Friedrich Ludwig Bauer definiu-a como: “Engenharia de 
Software é a criação e a utilização de sólidos princípios de engenharia a fim 
de obter software de maneira econômica, que seja confiável e que trabalhe 
em máquinas reais.” (BAUER, 1970). Margaret Hamilton é creditada por ter 
criado o termo “engenharia de software”. O próprio significado de 
engenharia já traz os conceitos de criação, construção, análise, 
desenvolvimento e manutenção. A engenharia de software se concentra 
nos aspectos práticos da produção de um sistema de software, enquanto a 
ciência da computação estuda os fundamentos teóricos dos aspectos 
computacionais. O termo foi criado na década de 1960 e utilizado 
oficialmente em 1968 na Nato Science Committee. Sua criação surgiu em 
uma tentativa de contornar a crise do software e dar um tratamento de 
engenharia (mais sistemático, controlado e de qualidade mensurável) ao 
desenvolvimento de sistemas de software complexos. Um sistema de 
software complexo se caracteriza por um conjunto de componentes 
abstratos de software (estruturas de dados e algoritmos) encapsulados na 
forma de algoritmos, funções, módulos, objetos ou agentes interconectados 
entre si, compondo a arquitetura do software, que deverão ser executados 
em sistemas computacionais. Para maiores detalhes do entendimento da 
engenharia de software, recomenda-se o vídeo Engenharia de software. 
Os fundamentos científicos envolvem o uso de modelos abstratos e precisos 
que permitem ao engenheiro especificar, projetar, implementar e manter 
sistemas de software, avaliando e garantindo sua qualidade. Além disso, 
oferecem mecanismos para se planejar e gerenciar o processo de 
desenvolvimento. Empresas desenvolvedoras de software passaram a 
empregar esses conceitos sobretudo para orientar suas áreas de 
desenvolvimento, muitas delas organizadas sob a forma de fábrica de 
software. Diante do exposto, cabe uma leitura detalhada do artigo Uma 
breve introdução à engenharia de software. São importantes o 
planejamento e o gerenciamento do desenvolvimento de software, 
processos de desenvolvimento de software, metodologias ágeis, 
engenharia de requisitos, arquitetura de software e padrões de projeto, 
validação e verificação de sistemas e qualidade de software. Uma das 
características da engenharia de software é a necessidade de planejamento 
e gerenciamento adequados para o projeto. Tendo em vista que a criação 
de um software pode ser encarada como um projeto, a engenharia de 
software utiliza como base os conceitos de gerência de projetos, como é o 
caso, por exemplo, dos conceitos do Project Management Body of 
Knowledge – PMBOK. De acordo com o PMBOK, o gerenciamento de 
projetos é a aplicação de conhecimentos, habilidades, ferramentas e 
técnicas às atividades do projeto, a fim de atender aos requisitos das partes 
interessadas. Ele define que o ciclo de vida de um projeto é dividido em 
cinco fases: iniciação, planejamento, execução, controle e finalização. Na 
fase de iniciação, o levantamento inicial dos riscos e requisitos do projeto é 
realizado, a viabilidade do projeto é analisada, e se obtém a autorização para 
início do projeto. Já na fase de planejamento, os objetivos são refinados, as 
atividades são definidas, o esforço e o custo do projeto são estimados, os 
riscos identificados são analisados e detalhados, e o cronograma é 
elaborado, dando origem ao plano de projeto. Na fase de execução, as ações 
planejadas são executadas, objetivando atingir os resultados esperados. Já 
a fase de controle é responsável por acompanhar o planejamento e 
execução do projeto, de modo a propor ações corretivas e preventivas, no 
menor espaço de tempo possível, após a detecção de anormalidade. A fase 
de finalização do projeto consiste na entrega final do produto gerado e 
análise dos resultados obtidos. Nessa fase, a aceitação do produto pelo 
cliente é verificada, e o desempenho do projeto em termos de custo, escopo 
e cronograma é consolidado. Embora apresentem necessidades comuns, o 
gerenciamento de projetos que envolvem o desenvolvimento de software 
distingue-se dos demais em dificuldades como, por exemplo, estimar o 
tempo de desenvolvimento, mensurar a evolução do projeto e medir a 
aceitação do produto, antes que seja entregue ao cliente. Diante de tais 
diferenças, os gerentes de projetos de software costumam seguir processos 
de desenvolvimento a fim de honrar os cronogramas e produzir produtos 
de qualidade. O processo de desenvolvimento de software compreende 
todas as atividades, ações e tarefas envolvidas no desenvolvimento do 
software, e a forma como esses elementos se relacionam define um modelo. 
Atualmente, existem inúmeros modelos de processos de desenvolvimento 
de software; dentre eles, podemos destacar: o cascata, o evolutivo, o 
incremental, o espiral, o RUP, o extreme programming – XP e o scrum. O 
modelo cascata foi o precursor dos modelos de processo de 
desenvolvimento de software. Esse modelo é constituído de cinco fases 
executadas sequencialmente, ou seja, uma fase só é iniciada quando a 
anterior é completada. A dificuldade em atender mudanças no decorrer do 
processo e a demora na disponibilidade de uma versão operacional do 
produto são os problemas encontrados nesse modelo. Diante das 
limitações do modelo cascata, foram criados os modelos evolutivo e 
incremental. A ideia do primeiro é entregar uma versão inicial do produto 
para avaliação do cliente e, em seguida, refinar o produto repetidamente 
até que uma versão atenda às suas expectativas. O desenvolvimento 
exploratório e a prototipação são exemplos desse modelo. Já o modelo 
incremental se diferencia do evolutivo, uma vez que a entrega inicial é um 
produto que atende aos requisitos básicos do cliente, e sua construção é 
feita por meio de incrementos (modificação e adição de novas 
funcionalidades). O RUP é um modelo de desenvolvimento iterativo e 
incremental, que possui duas dimensões: o eixo horizontal e o eixo vertical. 
O eixo horizontal representa o tempo e mostra as fases (iniciação, 
elaboração, construção e transição) do projeto. O eixo vertical é constituído 
pelas disciplinas de: modelagem do negócio, requisito, análise e projeto, 
implementação, teste e implantação, além das atividades de 
gerenciamento de projeto, de configuração e do ambiente. Cada uma das 
fases do RUP é constituída por iterações e foca em uma ou mais disciplinas. 
As metodologias supracitadas seguem processos orientados à 
documentação e, portanto, são consideradas metodologias pesadas. As 
metodologias ágeis visam reduzir essa carga na documentação, tornando o 
processo de desenvolvimento mais flexível e menos burocrático. Duas 
metodologias ágeis se destacam: XP e scrum. A XP é uma metodologia ágil 
para pequenas e médias equipes que desenvolvem softwares baseados em 
requisitos vagos e que se modificam rapidamente. Dentre as principais 
diferenças da XP em relação às outras metodologias estão: o feedback 
constante, a abordagem incremental e a comunicação entre as pessoas. De 
acordo com as práticas do XP, a construção do software deve ser 
padronizada, em pares, e realizada à medida que os requisitos surgem. 
Entre os desenvolvedores, deve existir o espírito de propriedade coletiva, ou 
seja, o código do projeto pertence a todos os membros da equipe. Nesse 
processo, o cliente deve estar sempre presente para sanar dúvidas de 
requisitos, evitando, assim, atrasos e até mesmo construções erradas. O 
scrum é uma metodologia ágil de desenvolvimento e gerenciamento de 
projetos de destaque atualmente. Ele estabelece um processo de 
desenvolvimento iterativo e incremental, podendo ser aplicado no 
gerenciamento de qualquer atividade. Ele define conjunto de regras e 
práticas de gestão para alcançar o sucesso dos projetos, como o trabalho 
em equipe e comunicação melhorada. Em um projeto scrum, dois papéissão fundamentais: o scrum master – SM e o product owner – PO. O SM é 
responsável pela aplicabilidade das práticas do scrum no projeto, enquanto 
o PO representa os interesses do cliente no projeto. O ciclo de vida do scrum 
inicia com a definição do product backlog. Este consiste em uma lista de 
itens, priorizados pelo PO, que precisam ser executados no projeto. Antes 
de cada iteração, é realizada a sprint planning, uma reunião de 
planejamento da sprint na qual são selecionados itens do product backlog 
que irão compor o sprint backlog. Com base em todo esse contexto, vamos 
trabalhar com o estudo de caso Engenharia de software para fortalecer 
mais os conceitos iniciais. Recomenda-se, para um entendimento mais 
apurado das próximas etapas ligadas aos paradigmas da engenharia do 
software, uma leitura cautelosa dos slides Paradigmas da engenharia de 
software. A engenharia de software compreende um conjunto de etapas 
que envolvem métodos, ferramentas e procedimentos. Essas etapas muitas 
vezes são citadas como paradigmas da engenharia de software. Um 
paradigma de engenharia de software é escolhido tendo-se como base a 
natureza do projeto e da aplicação, os métodos e ferramentas a serem 
usados, os controles e os produtos que precisam ser entregues. Quatro 
paradigmas têm sido amplamente discutidos e debatidos: ciclo de vida 
clássico ou cascata, prototipação, modelo espiral e técnicas de quarta 
geração. Ciclo de vida clássico. É o modelo mais antigo utilizado. É um 
método sistemático e sequencial, em que o resultado de uma fase se 
constitui na entrada da outra fase. Foi modelado de acordo com o ciclo da 
engenharia convencional e, segundo Pressman (1995), abrange as seguintes 
fases: 
• Análise de engenharia de sistema: conhecer o sistema e, por meio 
dele, estabelecer os requisitos que devem fazer parte do software. 
• Análise de requisitos de software: revisão de informações e 
requisitos e especificações das funcionalidades, desempenho e 
interface. 
• Projeto: constituído de pontos distintos: estrutura de dados, 
arquitetura do software, detalhes procedimentais e caracterização de 
interface. Traduz os requisitos levantados para avaliação e qualidade 
do software antes da codificação. 
• Codificação: transformação do projeto para que possa ser 
interpretado pela máquina. Se o projeto for bem detalhado, a 
codificação torna-se praticamente mecânica. 
• Testes: etapa em que são verificados os erros e se o código produz o 
resultado desejado. 
• Manutenção: correção de erros e adaptação do software ao ambiente 
em que será instalado. 
• Análise de engenharia de sistema: conhecer o sistema e, por meio 
dele, estabelecer os requisitos que devem fazer parte do software. 
• Análise de requisitos de software: revisão de informações e 
requisitos e especificações das funcionalidades, desempenho e 
interface. 
• Projeto: constituído de pontos distintos: estrutura de dados, 
arquitetura do software, detalhes procedimentais e caracterização de 
interface. Traduz os requisitos levantados para avaliação e qualidade 
do software antes da codificação. 
• Codificação: transformação do projeto para que possa ser 
interpretado pela máquina. Se o projeto for bem detalhado, a 
codificação torna-se praticamente mecânica. 
• Testes: etapa em que são verificados os erros e se o código produz o 
resultado desejado. 
• Manutenção: correção de erros e adaptação do software ao ambiente 
em que será instalado. 
Dentre as vantagens que podemos citar é que o modelo tem uma 
abordagem disciplinada e dirigida à documentação, tendo como 
problemas a dificuldade de seguir o fluxo, a determinação de requisitos 
iniciais (incerteza natural) e o fato de o resultado efetivo aparecer apenas no 
final. Segundo Pressman (1995): “O ciclo de vida clássico continua sendo o 
modelo procedimental mais amplamente usado pela Engenharia de 
Software. Embora tenha fragilidade, ele é significativamente melhor do que 
uma abordagem casual ao desenvolvimento de software.” Prototipação A 
prototipação é usada para identificar os requisitos e pode ser a melhor 
escolha quando o cliente definiu apenas objetivos gerais para o software, 
sem requisitos detalhados de entrada, processamento ou saída, ou o 
desenvolvedor pode não ter certeza daquilo que precisa ser desenvolvido. A 
vantagem da prototipação é a facilidade para determinar os requisitos 
iniciais e a garantia de atingir as necessidades do cliente, enquanto as 
desvantagens são a implementação rápida do protótipo comprometido, a 
determinação do fim do desenvolvimento e tendência a utilizar o protótipo 
como produto final. Modelo espiral Segundo Pressman (1995), esse modelo 
foi desenvolvido pela engenharia de software para abranger as melhores 
características do ciclo de vida clássico e da prototipação, acrescentando, ao 
mesmo tempo, um novo elemento — a análise de riscos — que falta a esses 
outros paradigmas. O modelo espiral define quatro importantes atividades: 
• Planejamento: determinação dos objetivos, alternativas e restrições. 
• Análise de riscos: análise de alternativas e identificação/resolução 
dos riscos. 
• Engenharia: desenvolvimento do produto no “nível seguinte”. 
• Avaliação feita pelo cliente: avaliação dos resultados da engenharia. 
O modelo espiral usa a prototipação como um mecanismo de redução de 
riscos, mantém uma abordagem de passos sistemáticos sugerida pelo ciclo 
de vida clássico e ainda incorpora uma estrutura iterativa que reflete mais 
realisticamente o mundo real. Técnicas de quarta geração O paradigma 
técnicas de quarta geração, ou 4GT, da engenharia de software concentra-
se na capacidade de se especificar software a uma máquina em um nível 
que esteja próximo à linguagem natural ou de se usar uma notação que 
comunique uma função significativa. Para transformar a implementação de 
uma 4GT em um produto, o desenvolvedor deve realizar testes cuidadosos, 
desenvolver uma documentação significativa e executar todas as demais 
atividades de “transição” que também são exigidas em outros paradigmas 
da engenharia de software. Para que possamos entender de forma mais 
específica e abrangente os paradigmas da engenharia de software, vamos 
fazer uma leitura mais dinâmica sobre o Ciclo de vida de sistemas e seus 
paradigmas. As técnicas de quarta geração já se tornaram uma parte 
importante do desenvolvimento de software na área de aplicação de 
sistemas de informação, e a demanda de software continuará em ascensão, 
porém o software produzido com métodos e paradigmas convencionais 
contribuirá cada vez menos para todo software desenvolvido. As técnicas de 
quarta geração preencherão a lacuna (PRESSMAN, 1995). Também é 
importante ressaltarmos os Princípios da engenharia de software. É 
importante nesse momento, após vários conteúdos pertinentes à 
engenharia de software, fazermos uma leitura atenta para o entendimento 
do Metodologias de desenvolvimento de software. Em muitas 
organizações que desenvolvem software, a gerência de riscos é vista como 
um processo difícil de ser executado de maneira adequada em função das 
pressões de custo e prazo que caracterizam o ambiente de negócios e da 
pouca disponibilidade de informações. Por outro lado, o aumento contínuo 
da qualidade e produtividade exigido pelo mesmo mercado, cada vez mais 
competitivo, só é conseguido por meio da melhoria e evolução dos 
processos de gerência e de desenvolvimento de software. Nas seções 
seguintes, serão apresentados e analisados alguns modelos e abordagens 
para gerenciamento de riscos de projetos de software. Diante do cenário e 
da necessidade, vamos ler atentamente o artigo Modelos e abordagens 
para gerenciamento de riscos de projetos de software. Modelos e 
abordagens para gerir riscos Riscos em ambientes de desenvolvimento de 
software passaram a receber uma atenção maior no final da década de 1980, 
quando Barry Boehm propôs e apresentou uma abordagem para gerir 
riscos (BOEHM, 1991). De acordo com Harold Kerzner, as atividades de 
gerenciamentode riscos associadas ao desenvolvimento de software 
passaram a ter destaque no cenário internacional em 1996, ainda como 
reflexo da crise do software e a necessidade de melhoria dos sistemas 
(KERZNER, 2000). Existe uma diversidade de modelos e abordagens que 
tratam atividades para gerenciamento de projetos de desenvolvimento de 
software. Para facilitar o estudo analítico, foram estabelecidos dois critérios 
de comparação entre os modelos: 
• Modelo de referência – Dentro do estudo dos modelos de gerência 
de riscos, um dos pontos fundamentais é verificar a base teórica 
utilizada. Essa base teórica é composta por características e requisitos 
que são refletidos no processo utilizado e nas atividades definidas no 
modelo. A base teórica também reflete a atualidade das pesquisas 
para a definição e adaptação do modelo. De forma adicional, promove 
a evolução do conhecimento para a construção do modelo em 
análise. 
• Componentes do modelo e relacionamentos – Outro ponto a 
considerar, não menos importante, é a captura dos componentes 
arquiteturais do modelo e suas relações como componentes que 
foram criados para garantir a aplicação da gerência de riscos, 
promovendo a confiabilidade do resultado esperado. Esse critério está 
intimamente ligado ao modelo de referência utilizado. 
A escolha de modelos e abordagens que serão apresentados a partir de 
agora foi baseada em sua influência nos atuais modelos de gestão de 
projetos e de qualidade de software, em especial gerenciamento de riscos 
em ambientes de desenvolvimento de software. Gerência de riscos 
segundo Barry W. Boehm O modelo que introduziu o estudo da gerência 
de riscos na engenharia de software foi apresentado por Barry Boehm no 
final da década de 1980. Nessa época, Boehm era membro integrante do 
Departamento de Defesa dos Estados Unidos (Department of Defense – 
DoD). O modelo apresentado por Boehm está baseado no modelo espiral, 
também de sua autoria (BOEHM, 1988). Esse modelo foi desenvolvido ao 
longo de muitos anos com base na experiência adquirida pela aplicação do 
modelo cascata (waterfall model) em grandes projetos do governo norte-
americano. O modelo espiral tem um típico ciclo de vida apresentando 
como atividade inicial a identificação dos objetivos relacionados: 
• Ao produto em elaboração. 
• Às alternativas de solução para os objetivos definidos. 
• Às restrições de implementação dessas alternativas. 
O passo seguinte é avaliar as alternativas identificadas para implementação 
dos objetivos do produto em elaboração e suas restrições. Frequentemente, 
nesse processo, são identificadas áreas de incertezas que são origens 
significantes de riscos de projetos. Uma vez avaliados os riscos, é necessário 
definir as formas de tratá-los. Desse modo, técnicas como prototipagem, 
simulações e benchmarking são realizadas. O processo é contínuo, e 
existirão validações dos requisitos, especificação do projeto (design), 
implementação e testes, em que cada ciclo é planejado e avaliado. Para que 
possamos fechar bem as abordagens vistas até agora, é preciso que 
saibamos como podemos trabalhar com uma das tendências que mais 
cresce. Vamos assistir ao vídeo sobre Metodologias ágeis: manifesto ágil. 
 
	Introdução
	Unidade 1 Engenharia de software
	Unidade 1 Engenharia de software