Pontos importantes da Engenharia de software

Prévia do material em texto

Pontos importantes da Engenharia 
de software 
 
 
1 Introdução a Engenharia de Software 
 
Engenharia de software e uma disciplina de engenharia que se preocupa 
com todos os aspectos da produção de software. 
• Software não e apenas um programa ou programas; ele inclui também 
a documentação. Os atributos principais de um produto de software são 
manutenibilidade, confiança, proteção, eficiência e aceitabilidade. 
• O processo de software inclui todas as atividades envolvidas no 
desenvolvimento do software. Atividades de alto nível de especificação, 
desenvolvimento, validação e evolução são parte de todos os processos 
de software. 
• As ideias fundamentais da engenharia de software são universalmente 
aplicáveis para todos os tipos de desenvolvimento de sistemas. Esses 
fundamentos incluem processos de software, confiança, proteção, 
requisitos e reuso. 
• Existem vários tipos diferentes de sistemas, e cada um requer 
ferramentas e técnicas de engenharia de software adequadas a seu 
desenvolvimento. Existem poucas, se houver alguma, técnicas 
especificas de projeto e implementação aplicáveis para todos os tipos de 
sistemas. 
• As ideias básicas da engenharia de software são aplicáveis a todos os 
tipos de sistemas de software. Esses fundamentos incluem processos de 
software gerenciados, confiança e proteção de software, engenharia de 
requisitos e reuso de software. 
• Engenheiros de software tem responsabilidades com a profissão de 
engenharia e com a sociedade. Eles não devem se preocupar apenas 
com as questões técnicas. 
• Sociedades profissionais publicam códigos de conduta que definem os 
padrões de comportamento esperado de seus membros. 
 
 
 
 
2 Processos de Software 
 
• Os processos de software são as atividades envolvidas na produção de 
um sistema de software. Modelos de 
processos de software são representações abstratas desses processos. 
• Modelos gerais de processo descrevem a organização dos processos 
de software. Exemplos desses modelos 
gerais incluem o modelo em cascata, o desenvolvimento incremental e o 
desenvolvimento orientado a reuso. 
• Engenharia de requisitos e o processo de desenvolvimento de uma 
especificação de software. As especificações 
destinam-se a comunicar as necessidades de sistema dos clientes para 
os desenvolvedores do sistema. 
• Processos de projeto e implementação estão relacionados com a 
transformação das especificações dos requisitos 
em um sistema de software executável. Métodos sistemáticos de projeto 
podem ser usados como parte 
dessa transformação. 
• Validação de software e o processo de verificação de que o sistema 
esta de acordo com sua especificação e satisfaz as necessidades reais 
dos usuários do sistema. 
• Evolução de software ocorre quando se alteram os atuais sistemas de 
software para atender aos novos requisitos. As mudanças são continuas, 
e o software deve evoluir para continuar util. 
• Processos devem incluir atividades para lidar com as mudanças. 
Podem envolver uma fase de prototipação, que ajuda a evitar mas 
decisões sobre os requisitos e projeto. Processos podem ser 
estruturados para o desenvolvimento e a entrega iterativa, de forma que 
mudanças possam ser feitas sem afetar o sistema como um todo. 
• O Rational Unified Process (RUP) e um moderno modelo genérico de 
processo, organizado em fases (concepção, elaboração, construção e 
transição), mas que separa as atividades (requisitos, analises, projeto 
etc.) dessas fases. 
 
 
 
 
 
 
 
 
 
 
 
 
3 Desenvolvimento ágil de Software 
 
• Métodos ágeis são métodos de desenvolvimento incrementai que se 
concentram em desenvolvimento rápido, releases frequentes do 
software, redução de overheads dos processos e produção de códigos 
de alta qualidade. 
Eles envolvem o cliente diretamente no processo de desenvolvimento. 
• A decisão de usar uma abordagem ágil ou uma abordagem dirigida a 
planos para o desenvolvimento deve depender do tipo de software a ser 
desenvolvido, das habilidades da equipe de desenvolvimento e da cultura 
da empresa que desenvolve o sistema. 
• Extreme Programming e um método ágil, bem conhecido, que integra 
um conjunto de boas praticas de programação, como releases frequentes 
do software, melhorias continuas do software e participação do cliente na 
equipe de desenvolvimento. 
• Um ponto forte da Extreme Programming e o desenvolvimento de testes 
automatizados antes da criação de um recurso do programa. Quando um 
incremento e integrado ao sistema, todos os testes devem ser 
executados com sucesso. 
• O método Scrum e uma metodologia ágil que fornece um framework de 
gerenciamento de projetos. E centralizado em torno de um conjunto de 
sprints, que são períodos determinados de tempo, quando um 
incremento de sistema e desenvolvido. O planejamento e baseado na 
priorização de um backlog de trabalho e na seleção das tarefas mais 
importantes para um sprint. 
• O escalamento de métodos ágeis para sistemas de grande porte e 
difícil. Tais sistemas necessitam de projeto adiantado e alguma 
documentação. A integração continua e praticamente impossível quando 
existem varias equipes de desenvolvimento separadas trabalhando em 
um projeto. 
 
 
 
 
 
4 Engenharia de Requisitos 
 
• Os requisitos para um sistema de software estabelecem o que o 
sistema deve fazer e define as restrições sobre seu funcionamento e 
implementação. 
• Os requisitos funcionais são declarações dos serviços que o sistema 
deve fornecer ou descrições de como alguns processamentos devem ser 
efetuados. 
• Muitas vezes, os requisitos não funcionais restringem o sistema que 
esta sendo desenvolvido e o processo de desenvolvimento que esta 
sendo usado. Estes podem ser os requisitos de produto, requisitos 
organizacionais ou requisitos externos. Eles costumam se relacionar com 
as propriedades emergentes do sistema e, portanto, aplicam-se ao 
sistema como um todo. 
• O documento de requisitos de software e uma declaração acordada dos 
requisitos do sistema. Deve ser organizado para que ambos — os 
clientes do sistema e os desenvolvedores de software — possam usa-lo. 
• O processo de engenharia de requisitos inclui um estudo da viabilidade, 
elicitacao e analise de requisitos, especificação de requisitos, validação e 
gerenciamento de requisitos. 
• Elicitação e analise de requisitos e um processo iterativo que pode ser 
representado como uma espiral de atividades — descoberta de 
requisitos, classificação e organização de requisitos, negociação de 
requisitos e documentação de requisitos. 
• A validação de requisitos e o processo de verificação da validade, 
consistência, completude, realismo e verificabilidade dos requisitos. 
• Mudanças organizacionais, mudanças nos negócios e mudanças 
técnicas inevitavelmente geram mudanças nos requisitos para um 
sistema de software. O gerenciamento de requisitos e o processo de 
gerenciamento e controle dessas mudanças. 
 
 
 
 
 
 
5 Modelagens de sistemas 
 
• Um modelo e uma visão abstrata de um sistema que ignora alguns 
detalhes do sistema. Modelos de sistema complementares podem ser 
desenvolvidos para mostrar o contexto, as interações, a estrutura e o 
comportamento do sistema. 
• Modelos de contexto mostram como um sistema que esta sendo 
modelado e posicionado em um ambiente com outros sistemas e 
processos. Eles ajudam a definir os limites do sistema a ser 
desenvolvido. 
• Diagramas de caso de uso e diagramas de sequencia são usados para 
descrever as interações entre o usuário do sistema que será projetado e 
usuários ou outros sistemas. Os casos de uso descrevem as interações 
entre um sistema e atores externos. Diagramas de sequencia 
acrescentam mais informações a eles, mostrando as interações entre os 
objetos do sistema. 
• Os modelos estruturais mostram a organização e a arquitetura de um 
sistema. Os diagramas de classe são usados para definir a estrutura 
estática de classes em um sistema e suas associações. 
• Os modelos comportamentais são usados para descrevero 
comportamento dinâmico de um sistema em execução. Podem ser 
modelados a partir da perspectiva dos dados processados pelo sistema 
ou pelos eventos que estimulam respostas de um sistema. 
• Os diagramas de atividades podem ser usados para modelar o 
processamento de dados, em que cada atividade representa uma etapa 
do processo. 
• Os diagramas de estado são usados para modelar o comportamento de 
um sistema em resposta a eventos internos ou externos. 
• A engenharia dirigida a modelos e uma abordagem de desenvolvimento 
de software em que um sistema e representado como um conjunto de 
modelos que pode ser automaticamente transformado em código 
executável. 
 
 
 
 
 
 
 
 
6 Projeto de arquitetura 
Uma arquitetura de software e uma descrição de como um sistema de 
software e organizado. As propriedades de um sistema, como 
desempenho, proteção e disponibilidade, são influenciadas pela 
arquitetura adotada. 
• As decisões de projeto de arquitetura incluem decisões sobre o tipo de 
aplicação, a distribuição do sistema, os estilos da arquitetura a serem 
utilizados e as formas como a arquitetura deve ser documentada e 
avaliada. 
• As arquiteturas podem ser documentadas a partir de diferentes 
perspectivas ou visões. As possíveis visões incluem uma visão 
conceitual, uma visão logica, uma visão de processo, uma visão de 
desenvolvimento e uma visão física. 
• Os padrões da arquitetura são um meio de reusar o conhecimento 
sobre as arquiteturas genéricas de sistemas. 
Eles descrevem a arquitetura, explicam quando elas podem ser usadas e 
discutem suas vantagens e desvantagens. 
• Entre os padrões de arquitetura comumente usados estão: Modelo-
Visão-Controlador, Arquitetura em camadas, Repositório, Cliente-servidor 
e Duto e filtro. 
• Modelos genéricos de arquiteturas de sistemas de aplicação ajudam-
nos a compreender o funcionamento das aplicações, comparar 
aplicações do mesmo tipo, validar projetos de sistemas de aplicação e 
avaliar os componentes para reuso em larga escala. 
• Sistemas de processamento de transações são sistemas interativos que 
permitem que as informações em um banco de dados sejam acessadas 
remotamente e modificadas por vários usuários. Os sistemas de 
informação e de gerenciamento de recursos são exemplos de sistemas 
de processamento de transações. 
• Sistemas de processamento de linguagens são usados para traduzir 
textos de uma linguagem para outra e para realizar as instruções 
especificadas em uma linguagem de entrada. Eles incluem um tradutor e 
uma maquina abstrata que executa a linguagem gerada. 
 
 
 
 
 
 
 
 
 
 
7 Projeto e Implementação 
 
O projeto e a implementação de software são atividades intercaladas. O 
nível de detalhamento no projeto depende do tipo de sistema a ser 
desenvolvido e se esta sendo usada uma abordagem ágil ou dirigida a 
planos. 
• O processo de projeto orientado a objetos inclui atividades para projetar 
a arquitetura do sistema, identificar objetos no sistema, descrever o 
projeto usando diferentes modelos de objetos e documentar as interfaces 
dos componentes. 
• Vários modelos diferentes podem ser produzidos durante um processo 
de projeto orientado a objetos. Estes incluem modelos estáticos (modelos 
de classes, modelos de generalização, modelos de associação) e 
modelos dinâmicos (modelos de sequencia, modelos da maquina de 
estado). 
• As interfaces de componentes devem ser definidas precisamente, de 
forma que outros objetos possam usa-las. Um estereotipo de interface da 
UML pode ser usado para definir as interfaces. 
• Ao desenvolver um software, você sempre deve considerar a 
possibilidade de reusar um software existente, como seus componentes, 
serviços ou sistemas completos. 
• O gerenciamento de configuração e o processo de gerenciamento de 
mudanças para um sistema de software em evolução. E essencial 
quando uma equipe esta cooperando no desenvolvimento de software. 
• A maioria dos desenvolvimentos de software e desenvolvimento host-
target. Um IDE e usado em uma maquina host para desenvolver o 
software, que e transferido para uma maquina target para a execução. 
• O desenvolvimento open source envolve a disponibilização publica do 
codigo-fonte de um sistema. Isso significa que muitas pessoas podem 
propor alterações e melhorias no software. 
 
 
 
 
8 Teste de Software 
• Os testes só podem anunciar a presença de defeitos em um programa. 
Não podem demonstrar que não existem defeitos remanescentes. 
• Testes de desenvolvimento são de responsabilidade da equipe de 
desenvolvimento de software. Outra equipe deve ser responsável por 
testar o sistema antes que ele seja liberado para os clientes. No 
processo de testes de usuário, clientes ou usuários do sistema fornecem 
dados de teste e verificam se os testes são bem-sucedidos. 
• Testes de desenvolvimento incluem testes unitários, nos quais você 
testa objetos e métodos específicos; testes de componentes, em que 
você testa diversos grupos de objetos; e testes de sistema, nos quais 
você testa sistemas parciais ou completos. 
• Ao testar o software, você deve tentar 'quebrar' o software usando sua 
experiência e diretrizes para escolher os tipos de casos de teste que tem 
sido eficazes na descoberta de defeitos em outros sistemas. 
• Sempre que possível, você deve escrever testes automatizados. Os 
testes são incorporados em um programa que pode ser executado cada 
vez que uma alteração e feita para um sistema. 
• O desenvolvimento test-first e uma abordagem de desenvolvimento na 
qual os testes são escritos antes do código que será testado. Pequenas 
alterações no código são feitas, e o código e refatorado ate que todos os 
testes sejam executados com êxito. 
• Testes de cenário são uteis porque replicam o uso pratico do sistema. 
Trata-se de inventar um cenário típico de uso e usar isso para derivar 
casos de teste. 
• Teste de aceitação e um processo de teste de usuário no qual o 
objetivo e decidir se o software e bom o suficiente para ser implantado e 
usado em seu ambiente operacional. 
 
 
 
 
 
 
 
19 Arquitetura Orientada a serviço 
• Arquitetura orientada a serviços e uma abordagem de engenharia de 
software em que os serviços reusaveis padronizados são os blocos 
básicos de construção para os sistemas de aplicação. 
• Interfaces de serviço podem ser definidas em uma linguagem baseada 
em XML chamada WSDL. Uma especificação WSDL inclui uma definição 
dos tipos e operações de interface, o protocolo de ligação usado pelo 
serviço e a locação de serviço. 
• Os serviços podem ser classificados como serviços utilitários que 
fornecem uma funcionalidade de uso geral, serviços de negócios que 
implementam parte de um processo de negócios ou serviços de 
coordenação que executam outros serviços. 
• O processo de engenharia de serviço envolve a identificação de 
serviços candidatos a implementação, a definição de interface e a 
implementação de serviço e teste e a implantação de serviço. 
• As interfaces de serviço podem ser definidas para sistemas legados 
que continuam uteis para uma organização. 
Em seguida, a funcionalidade do sistema legado pode ser reusada em 
outras aplicações. 
• O desenvolvimento de software usando serviços baseia-se na ideia de 
que os programas são criados por composição e configuração de 
serviços para criar novos serviços compostos. 
• Modelos de processos de negócios definem as atividades e o 
intercambio de informações que se realizam em um processo de 
negócios. Atividades em um processo de negócios podem ser 
implementadas por serviços para que o modelo de processo represente 
uma composição de serviço. 
 
 
 
 
 
25 Gerenciamento de Configurações 
 
• O gerenciamento de configurações e o gerenciamento de um sistema 
de software em constante evolução. Durante a manutenção de um 
sistema, uma equipe de CM e responsável por garantir que as mudanças 
sejam incorporadas no sistema de uma forma controlada e que os 
registros sejam mantidos com os detalhes das Mudanças que foram 
implementadas.• Os principais processos de gerenciamento de configurações estão 
interessados no gerenciamento de mudanças, no gerenciamento de 
versões, na construção de sistema e no gerenciamento de releases. 
Ferramentas de software estão disponíveis para apoiar todos esses 
processos. 
• O gerenciamento de mudanças envolve avaliar propostas de mudanças 
dos clientes de sistema e outros stakeholders e decidir se e efetivo 
implementa-las em um novo release de um sistema. 
• O gerenciamento de versões envolve o acompanhamento das 
diferentes versões dos componentes de software criadas à medida que 
as mudanças são feitas. 
• A construção de sistemas e o processo de montagem de componentes 
de sistema em um programa executável para executar em um sistema de 
computador-alvo. 
• O software deve ser reconstruído e testado frequentemente, 
imediatamente apos a construção de uma nova versão. Isso facilita a 
detecção de bugs e problemas introduzidos desde a ultima construção. 
• Os releases de sistema incluem códigos executáveis, arquivos de 
dados, arquivos de configuração e documentação. O gerenciamento de 
versões envolve tomar decisões sobre as datas de release de sistema, 
preparar todas as informações para distribuição e documentar cada 
release de sistema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16 Reuso de Software 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
• Atualmente, a maioria dos novos sistemas de software de negócios e 
desenvolvida com reuso de conhecimento e códigos de sistemas já 
implementados. 
• Existem muitas maneiras de se reusar um software, desde o reuso de 
classes e métodos em bibliotecas ate o reuso de sistemas de aplicação 
completos. 
• As vantagens do reuso de software são redução de custos, 
desenvolvimento de software mais rápido e diminuição de riscos, além de 
aumento da confiança no sistema. Ademais, especialistas podem ser 
usados mais eficazmente, concentrando sua expertise no projeto de 
componentes reusáveis. 
• Frameworks de aplicações são coleções de objetos concretos e 
abstratos projetados para o reuso por meio da especialização e a adição 
de novos objetos. Geralmente, eles incorporam boas praticas de projeto 
por meio de padrões de projeto. 
• As linhas de produtos de software são aplicações relacionadas, 
desenvolvidas a partir de uma ou mais aplicações-base. Um sistema 
genérico e adaptado e especializado para atender aos requisitos 
específicos de funcionalidade, plataforma de destino ou configuração 
operacional. 
• O reuso de produtos COTS esta preocupado com o reuso de sistemas 
de prateleira em grande escala. Eles fornecem uma grande 
funcionalidade e seu reuso pode reduzir radicalmente os custos e o 
tempo de desenvolvimento. Os sistemas podem ser desenvolvidos por 
meio da configuração de um único produto genérico COTS ou integrando 
dois ou mais produtos COTS. 
• Os sistemas ERP (Enterprise Resource Planning) são exemplos de 
reuso de COTS em grande escala. Você cria uma instancia de um 
sistema ERP por meio da configuração de um sistema genérico com 
informações sobre regras e processos de negócios do cliente. 
• Possíveis problemas com o reuso baseado em COTS incluem a falta de 
controle sobre a funcionalidade e o desempenho, a falta de controle 
sobre a evolução de sistema, a necessidade de suporte dos 
fornecedores externos e as dificuldades em assegurar que os sistemas 
possam interoperar. 
 
17 Engenharia de software baseada em componentes 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
• A engenharia de software baseada em componentes e uma abordagem 
baseada no reuso para definição, implementação e composição de 
componentes independentes, fracamente acoplados em sistemas. 
• Um componente e uma unidade de software cuja funcionalidade e 
dependências são completamente definidas por um conjunto de 
interfaces publicas. Os componentes podem ser compostos com outros 
componentes sem o conhecimento de sua implementação e podem ser 
implantados como uma unidade executável. 
• Os componentes podem ser implementados como unidades de 
programa que são incluídas em um sistema ou como serviços externos 
que são referenciados a partir de dentro de um sistema. 
• Um modelo de componente define um conjunto de padrões para 
componentes, incluindo normas de interface, normas de uso e normas de 
implantação. A implementação do modelo de componente fornece um 
conjunto de serviços comuns que podem ser usados por todos os 
componentes. 
• Durante o processo CBSE, você precisa intercalar os processos de 
engenharia de requisitos e projeto de sistemas. Você precisa negociar os 
requisitos desejáveis pelos serviços que estão disponíveis a partir dos 
componentes reusáveis existentes. 
- A composição do componente e o processo de 'conexão' dos 
componentes para a criação de um sistema. Os tipos de composições 
incluem a composição sequencial, a composição hierárquica e a 
composição aditiva. 
• Ao compor componentes reusáveis que não foram escritos para sua 
aplicação, você talvez precise escrever adaptadores ou 'gluecode' para 
reconciliar as diferentes interfaces de componentes. 
• Ao escolher as composições, você deve considerar a funcionalidade 
requerida para o sistema, os requisitos não funcionais e a facilidade com 
que um componente pode ser substituído quando o sistema e alterado.