Buscar

Livro 'Engenharia de software' - Aprofundando o conhecimento

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 4 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

Engenharia de software
Pontos importantes dos quadros ‘Aprofundando o conhecimento’, de todas as unidades do livro.
Unidade 1
A engenharia de software é uma disciplina de engenharia relacionada a todos os aspectos de produção de software.
Os produtos de software consistem em programas desenvolvidos e documentação associada. Os atributos essenciais do produto são: facilidade de manutenção, confiança, eficiência e aceitação.
O processo de software inclui todas as atividades envolvidas no desenvolvimento de software. As atividades de alto nível na especificação, desenvolvimento, validação e evolução de software são parte de todos os processos de software.
Métodos são meios organizados de produção de software. Eles incluem sugestões sobre o processo a ser seguido, as notações a serem usadas, os modelos de sistemas a serem desenvolvidos, as regras que regem esses modelos e diretrizes do projeto.
Ferramentas CASE são sistemas de software projetados para apoiar as atividades de rotina no processo de software, como edição de diagramas de projeto, verificação da consistência de diagramas e manutenção do controle de testes de programa realizados.
Os engenheiros de software têm responsabilidades com a profissão de engenharia e com a sociedade. Eles não devem se preocupar apenas com questões técnicas.
Sociedades profissionais publicam códigos de conduta que definem os padrões de comportamento esperados de seus membros.
Unidade 2
Com o crescimento da pressão para a entrega rápida de software, a abordagem iterativa para o desenvolvimento do software está se tornando cada vez mais usada como técnica-padrão de desenvolvimento de sistemas pequenos e médios, especialmente no mundo dos negócios.
Os métodos ágeis são métodos iterativos de desenvolvimento que enfocam a especificação, projeto e implementação de sistemas incrementais. Eles envolvem diretamente o cliente no processo de desenvolvimento. A redução de overhead de desenvolvimento pode fazer o desenvolvimento de software ser o mais rápido possível.
A extreme programming é um método ágil bastante conhecido que integra uma gama de boas práticas de programação, tais como teste sistemático, aprimoramento contínuo do software e participação do cliente na equipe de desenvolvimento.
Um ponto forte em particular da extreme programming é o desenvolvimento de testes automatizados antes da criação de um recurso do programa. Todos os testes deverão ser executados com sucesso quando um incremento for integrado ao sistema.
O desenvolvimento rápido de aplicações envolve o uso de ambientes de desenvolvimento que incluem ferramentas poderosas para apoiar a produção de software. Estas incluem linguagens de programação de banco de dados, geradores de formulários e relatórios, e links para as aplicações de escritório.
A prototipação throw-away é um processo de desenvolvimento iterativo no qual um protótipo de sistema é usado para explorar as opções de requisitos e de projeto. Esse protótipo não se destina à implantação pelo cliente.
Ao implementar um protótipo throw-away são desenvolvidas primeiro as partes do sistema menos compreendidas; por outro lado, em uma abordagem incremental, começa-se pelo desenvolvimento das partes do sistema mais bem compreendidas.
Unidade 3
Um bom gerenciamento de projeto de software é essencial para que os projetos de engenharia de software sejam desenvolvidos dentro do cronograma e do orçamento.
O gerenciamento de software é diferente do gerenciamento em outras áreas da engenharia. O software é intangível. Os projetos podem ser novos ou inovadores, portanto, não existe um conjunto de experiências para guiar seu gerenciamento. Os processos de software não são bem compreendidos.
Os gerentes de software possuem diversos papéis. As atividades mais significativas são planejamento, elaboração de estimativas e desenvolvimento de cronograma do projeto. O planejamento e a elaboração de estimativas são processos iterativos. Eles continuam ao longo de um projeto. À medida que mais informações se tornam disponíveis, os planos e os cronogramas devem ser revisados.
Um marco de projeto é um resultado previsível de uma atividade, no qual algum relatório formal de progresso deve ser apresentado à gerência. Os marcos devem ocorrer regularmente ao longo de um projeto de software. Um produto é um marco disponibilizado para o cliente do projeto.
O desenvolvimento do cronograma do projeto envolve a criação de várias representações gráficas de partes do plano de projeto. Elas incluem diagramas de atividades, que mostram os inter-relacionamentos entre as atividades de projeto, e diagramas de barras, que mostram as durações de atividades.
Os principais riscos do projeto devem ser identificados e avaliados para definir sua probabilidade e as consequências para o projeto. Você deve elaborar planos para evitar, gerenciar ou lidar com os prováveis riscos se ou quando eles ocorrerem. Os riscos devem ser explicitamente discutidos em cada reunião de progresso do projeto.
Unidade 4
Os requisitos de um sistema de software definem o que o sistema deve fazer e as restrições sobre suas operações e sua implementação.
Os requisitos funcionais são declarações dos serviços que o sistema deve fornecer ou são descrições de como algumas computações devem ser realizadas. Os requisitos de domínio são requisitos funcionais derivados das características do domínio da aplicação.
Os requisitos não funcionais restringem o sistema que está sendo desenvolvido e o processo de desenvolvimento que deve ser usado. Eles podem ser requisitos de produto, requisitos organizacionais ou requisitos externos. Estão, frequentemente, relacionados as propriedades emergentes do sistema e, portanto, aplicam-se ao sistema como um todo.
Os requisitos de usuário destinam-se às pessoas envolvidas no uso e na aquisição do sistema. Eles devem ser redigidos com o uso de linguagem natural, tabelas e diagramas de fácil compreensão.
Os requisitos de sistema destinam-se a comunicar, de maneira precisa, as funções que o sistema deve fornecer. Para reduzir a ambiguidade, podem ser escritos em linguagem natural, de maneira estruturada, e complementados com tabelas e modelos de sistemas.
O documento de requisitos de software é a declaração aprovada dos requisitos de sistema. Ele deve ser organizado de tal modo que os clientes de sistema e os projetistas de software possam usá-lo.
O padrão do IEEE para documentos de requisitos é um ponto de partida útil para padrões de especificação de requisitos mais específicos.
Unidade 5
O gerenciamento de qualidade de software dedica-se a assegurar que o software tem baixo número de defeitos e que atinge os padrões necessários de facilidade de manutenção, confiabilidade, portabilidade etc. As atividades de gerenciamento de qualidade incluem a garantia de qualidade que estabelece padrões para o desenvolvimento de software, o planejamento de qualidade e o controle de qualidade que verifica o software em relação aos padrões definidos.
Você deve documentar um conjunto de procedimentos de garantia de qualidade em um manual de qualidade da organização. Ele pode basear-se no modelo genérico de um manual de qualidade nos padrões ISO 9000.
Os padrões de software são importantes para a garantia de qualidade quando representam uma identificação da ‘melhor prática’. O processo de controle de qualidade dedica-se a verificar se o processo de software e o software em desenvolvimento estão em conformidade com esses padrões.
As revisões de produtos relacionados ao processo de software envolvem uma equipe de pessoas que verificam se os padrões de qualidade estão sendo seguidos. As revisões são a técnica mais amplamente usada para a avaliação de qualidade.
As medições de software podem ser usadas para juntar dados quantitativos sobre o software e o processo de software. Você pode ser capaz de usar os valores das métricas de software coletados para fazer inferências sobre a qualidade de produto e de processo.
As métricas de qualidade de produto são particularmente valiosas para destacar componentes anômalosque podem ter problemas de qualidade. Esses componentes devem então ser analisados mais detalhadamente.
Não existem métricas de software padronizadas e universalmente aplicáveis. As organizações devem selecionar suas métricas e analisar as medições baseadas no conhecimento e nas circunstâncias locais.
Unidade 6
O desenvolvimento e a evolução de software devem ser um processo único, integrado e iterativo que pode ser representado por meio de um modelo em espiral
As leis de Lehman, como a noção de que a mudança é contínua, descrevem uma série de percepções derivadas de estudos de longo prazo sobre a evolução de sistemas.
Existem três tipos de manutenção de software: correção de defeitos, modificação de software para operar em um novo ambiente e implementação de novos requisitos ou de requisitos alterados.
Para sistemas sob encomenda, os custos de manutenção de software geralmente excedem os custos de desenvolvimento.
O processo de evolução de software é dirigido por solicitações de mudanças e inclui análise de impactos de mudanças, planejamento de releases e implementação de mudanças.
A reengenharia de software está relacionada à reestruturação e nova documentação do software para tomá-lo mais compreensível e mais fácil de mudar
O valor de mercado de um sistema legado e a qualidade do software da aplicação bem como seu ambiente devem ser avaliados para determinar se o sistema deve ser substituído, transformado ou mantido.
Referências
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson Addison- Wesley, 2007.

Outros materiais