Engenharia de Software - Projetos e Processos - Vol. 2

Visualizações: 43
Classificação: (0)

Referência para cursos de Computação e afins. Engenharia de Software – Projetos e Processos, de Wilson de Pádua Paula Filho, é uma ferramenta para estudantes e profissionais e apresenta conteúdos relevantes sobre manutenção e desenvolvimento de software. Agora em dois volumes, esta segunda parte trata de questões ligadas ao gerenciamento e seus fundamentos. Entre elas estão: produção de software, capacitação em processos, gestão da qualidade, de alterações e de projetos, engenharia de processos e de sistemas, experimentação e o engenheiro de software. Além disso, apresenta detalhes dos métodos gerenciais do processo Praxis “clássico” (SPraxis) e dos métodos de nível de empresa (EPraxis). Em relação à gestão de projetos, este conteúdo obedece às linhas gerais do PMBOK®, complementadas por outras fontes e pela experiência do autor, e segue os padrões de Engenharia de Software do Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE) e suas atualizações, bem como os exemplos de processos que utilizam a notação SPEM 2.0. Com material suplementar para professores, Engenharia de Software abrange tópicos requeridos por cursos de graduação diversos, como Informática, Engenharia da Computação, Ciência da Computação, Análise de Sistemas, Processamento de Dados, entre outros. Por que ler Engenharia de Software? Os sistemas informatizados têm enorme potencial de trazer benefícios, bem como prejuízos quando elaborados de maneira errada. Uma vez que o software é a alma dos sistemas informatizados, a Engenharia de Software é a disciplina que ensina a construir produtos reais a partir dos conceitos fundamentais da Informática. Assim, este livro apresenta as práticas mais consagradas dessa disciplina.

FORMATOS DISPONíVEIS

Impresso
eBook

Disponível no modelo assinatura da Minha Biblioteca

12 capítulos

Formato Comprar item avulso Adicionar à Pasta

Capítulo 1 Produção de software

ePub Criptografado

A produção industrial de software é quase sempre uma atividade coletiva. Alguns produtos são construídos inicialmente por indivíduos ou pequenas equipes, como produtos comerciais de prateleira, conhecidos como COTS (commercial off-the-shelf). À medida que se tornam sucesso de mercado, passam a evoluir. A partir daí um número cada vez maior de pessoas passa a cuidar da sua manutenção e evolução. Outras vezes trata-se de produtos desenvolvidos por encomenda de um cliente. Quando esses produtos são bem recebidos, as organizações passam a receber encomendas cada vez maiores, tendo de crescer para atendê-las.

Por isso, quase todas as atividades de engenharia de software são empreendidas por organizações, ou seja, estruturas administrativas em que pessoas conduzem um ou mais projetos, sob uma diretoria e partilhando as mesmas políticas [CMMI10]. Uma organização produtora de software pode ser toda uma empresa (ou fundação, órgão governamental etc.) na qual a produção de software é a atividade-fim, ou uma das atividades-fim; ou uma divisão de uma empresa que tem outros objetivos, sendo a produção de software uma atividade-meio.

 

Capítulo 2 Capacitação em procesos

ePub Criptografado

Um programa de melhoria de processos não pode ser desenhado de maneira intuitiva. Ele deve refletir o acervo de experiência dos profissionais e organizações da área. Diversas organizações do mundo propuseram paradigmas para a melhoria dos processos dos setores produtivos; em particular, algumas desenvolveram modelos de referência para a melhoria dos processos de software. Interessam aqui, especialmente, os paradigmas chamados de modelos de maturidade de capacitação (capability maturity model): modelos que contêm os elementos essenciais de processos eficazes para uma ou mais disciplinas, e descrevem um caminho de melhoria evolutiva que parte de processos imaturos e ad hoc, até chegar a processos maduros e disciplinados, que melhoram de forma significativa a qualidade dos produtos e a eficácia do trabalho [CMMI10].

Um modelo de maturidade de capacitação serve de referência para avaliar a maturidade dos processos de uma organização. Isso é feito comparando-se as práticas reais da organização com aquelas que o modelo de capacitação prescreve ou recomenda. Essa apreciação (appraisal) produz um diagnóstico da organização quanto à maturidade de seus processos oficiais e reais. O diagnóstico serve de base para recomendações de melhoria de processos, e essas recomendações podem ser consolidadas em um plano de melhoria, como sugere o modelo IDEAL.

 

Capítulo 3 Gestão da qualidade

ePub Criptografado

Este capítulo trata de assuntos referentes à qualidade em projetos e produtos de software. O Glossário do IEEE define qualidade como “Grau de conformidade de um sistema, componente ou processo com os respectivos requisitos”, ou, alternativamente, como “Grau de conformidade de um sistema, componente ou processo com as necessidades e expectativas de clientes ou usuários”. Ambas as definições refletem aspectos importantes da qualidade; diversos autores apresentam outras definições, geralmente girando em torno dos temas de conformidade com os requisitos e atendimento das expectativas. Naturalmente, pode haver diferenças entre as aplicações dessas definições, se os requisitos explícitos não refletirem corretamente as necessidades reais. Como salienta [Glass03], a qualidade é definida por uma coleção de atributos, sendo funcionalidade, confiabilidade, satisfação do usuário e desempenho aspectos importantes, mas parciais.

Um conceito central deste capítulo é o de garantia da qualidade, definida pelo Glossário do IEEE como “Conjunto planejado e sistemático de ações necessárias para estabelecer um nível adequado de confiança de que um item ou produto está em conformidade com seus requisitos técnicos”. Essas ações incluem ações preventivas, como o uso de processos e ferramentas adequadas e a capacitação das equipes no uso desses processos e ferramentas. A definição de garantia da qualidade constante do CMMI enfatiza a aderência aos processos: “Conjunto planejado e sistemático de meios para garantir à gerência que os padrões, métodos, práticas e procedimentos definidos por um processo são aplicados”.

 

Capítulo 4 Gestão de projetos

ePub Criptografado

Este capítulo trata dos métodos da disciplina de Gestão de projetos. Na definição do CMMI [CMMI10], projeto é “um conjunto gerido de recursos inter-relacionados, que entrega um ou mais produtos a um cliente ou usuário, com início definido e que, tipicamente, opera conforme um plano”; segundo o Project Management Body of Knowledge, conhecido como PMBoK1 [PMI17], um projeto é “um esforço temporário empreendido para criar um produto, serviço ou resultado único”. Na definição do PMBoK, destacam-se os aspectos:

Temporário – todo projeto tem um início e um fim. A duração é sempre finita, ainda que possa ser longa. O resultado de um projeto pode ser duradouro, mas a oportunidade de sua realização e a equipe que nele trabalha também são geralmente de natureza temporária.

Produtos, serviços ou resultados distintos – cada projeto resulta em uma entrega singular, distinta de outras entregas.

 

Capítulo 5 Gestão das al terações

ePub Criptografado

Projetos e produtos de software sofrem muitos tipos de alterações durante todo o ciclo de vida. Excetuando-se os projetos e produtos de organizações minúsculas e quase individuais, todos envolvem quantidades significativas de artefatos, pessoas e procedimentos. Para evitar a explosão de possibilidades de introdução de defeitos, é indispensável executar todos os tipos de alterações dentro de procedimentos disciplinados, de preferência usando soluções automatizadas. As alterações em artefatos dos projetos e produtos são administradas pelo uso dos procedimentos e técnicas da disciplina de Gestão de alterações. Essas técnicas são aqui divididas em três grupos, descritos a seguir.

A Gestão de configurações, segundo o CMMI e o IEEE, é a “disciplina que aplica direção e vigilância técnicas e administrativas à identificação e documentação das características físicas e funcionais de itens, ao controle de alterações dessas características, ao registro e relato do processamento e status de implementação de alterações, e à verificação de conformidade com requisitos especificados”. Ela abrange a identificação, a agregação e a organização dos artefatos quanto ao controle de alterações, assim como os processos usados para garantir que as alterações possam ser feitas sem prejuízo da qualidade.

 

Capítulo 6 Engenharia de processos

ePub Criptografado

Os processos realizam a integração do conjunto de métodos e padrões aplicáveis às disciplinas da engenharia de software. Um processo definidotem uma descrição que é mantida, e contribui produtos de trabalho, medidas e outras informações de melhoria de processos para o patrimônio de processos da organização” [CMMI10]. Processos publicados, como é o caso do Praxis, do RUP e de muitos outros, são processos definidos que publicam essa descrição em formatos de utilização fácil, como livros e hipertextos.

Um processo publicado pode ser suficiente como instrumento de estudo e aprendizado, mas, para passar à prática de uma organização produtora de software, qualquer processo deve ser complementado e personalizado. Devem ser adicionados novos padrões que cubram aspectos específicos das aplicações, da tecnologia, dos métodos gerenciais e até da cultura da organização. Nenhum processo é perfeito para qualquer organização, qualquer tecnologia e qualquer aplicação. Mesmo os processos de fabricantes comerciais requerem um esforço considerável de adaptação. A disciplina de Engenharia de processos trata da adaptação, da manutenção e do desenvolvimento dos próprios processos, assim como das tecnologias e do treinamento que dão suporte a esses processos.

 

Capítulo 7 Engenharia de sistemas

ePub Criptografado

Produtos de software desenvolvidos por encomenda, principalmente para clientes que são organizações de grande porte, raramente existem em forma isolada. Geralmente, diversos produtos devem se articular de variadas maneiras. Entre outros, são comuns os casos em que produtos se integram:

• partilhando dados, por exemplo, por meio de bancos de dados;

• apresentando uma fachada de acesso comum, ou pelo menos partilhando convenções de interface de usuários;

• utilizando recursos tecnológicos comuns, como componentes, plataformas e arquiteturas;

• funcionando de forma concorrente ou paralela;

• dividindo funções de uma missão organizacional comum.

Além disso, sistemas compostos de vários produtos de software podem ser, por sua vez, partes de sistemas ainda maiores, que envolvem recursos de hardware, de dados, de comunicações e de dispositivos e equipamentos da área de aplicação. Sistemas de comunicação, eletrodomésticos, sistemas de computação embarcada (como automóveis, aviões, trens, embarcações), instrumentação médica e muitos outros são responsáveis por grande parte do mercado atual de Engenharia de software.

 

Capítulo 8 Experimentação

ePub Criptografado

Está cada vez mais difícil ter artigos aceitos em boas conferências e publicações de Engenharia de software sem ter os resultados desses artigos validados por experimentos conduzidos de acordo com o método científico. Isso representa a consolidação do aspecto científico da Engenharia de software, já que a consistência lógica e a elegância não são mais vistas como suficientes para a aceitação de teorias e modelos, mas está sendo cada vez mais exigida a validação empírica.

Mesmo os resultados da experiência prática dependem cada vez mais de serem tratados como experimentos científicos, para que possam ser considerados de aplicação geral. Várias das referências mais importantes deste livro baseiam suas recomendações práticas nos resultados de experimentos. O simples relato de casos de sucesso geralmente não é suficiente para convencer os revisores dessas conferências e publicações quanto ao valor dos relatos, como contribuições ao estado da arte.

 

Capítulo 9 O engenheiro de software

ePub Criptografado

A profissão de Engenheiro de software é uma das profissões mais demandadas nas áreas de alta tecnologia e, ao que tudo indica, continuará a sê-lo no futuro previsível. Não apenas grandes empresas de software estão entre as maiores do mundo como as empresas de petróleo, automóveis, comércio e bancos, que formam a maioria no topo da lista, são todas grandes consumidoras de tecnologia da informação.

Política e economicamente, a indústria de software tem um papel global importante. No segundo país mais populoso do mundo, a Índia, o software representa um dos principais produtos de exportação. A indústria de software contribuiu para transformar a Irlanda, um país pequeno que, historicamente, sempre tinha sido um dos mais pobres da Europa, em um dos países de maior renda per capita do mundo (apesar das crises mundiais do passado recente). O conceito de combater a exclusão digital faz parte de muitas políticas de distribuição de renda, no Brasil e no mundo.

 

Apêndice A O Processo SPraxis – disciplinas gerenciais

ePub Criptografado

Este apêndice complementa a versão preferencial do Praxis, conhecida como SPraxis (de Simplificada ou Standard), focalizando suas disciplinas de caráter gerencial. Na Tabela A.1, essas são as disciplinas que formam os grupos de Gestão (que focaliza os projetos) e Ambiente (que focaliza os processos).

As disciplinas de caráter técnico, referentes aos grupos de Especificação e Solução, são tratadas no Apêndice A do primeiro volume. Este apêndice também trata de aspectos gerais aplicáveis a todas as disciplinas, e recomenda-se a consulta a ele, sempre que for necessário.

Tabela A.1 Disciplinas do Praxis

GRUPO

DISCIPLINA

SIGLA

OBJETIVO

Especificação

Requisitos

RQ

Obter o enunciado completo, claro e preciso dos requisitos de um produto de software.

Análise

 

Apêndice B O Processo EPraxis

ePub Criptografado

Este apêndice apresenta a versão mais estendida do processo Praxis, chamada de EPraxis (de E mpresa). Ela agrupa métodos que não aparecem em projetos isolados, tratados nos capítulos referentes a disciplinas de gestão (da qualidade, de projetos e de alterações) e de engenharia (de processos e de sistemas). As disciplinas que recebem acréscimos pertencem aos grupos de Gestão (que focaliza os projetos) e de Ambiente (que focaliza os processos).

As disciplinas de caráter técnico usadas pertencem aos grupos SPraxis e XPraxis, tratados nos demais apêndices.

No processo EPraxis, a disciplina de Gestão da qualidade tem um único acréscimo, referente ao Processamento de defeitos. Note-se que esse elemento trata de problemas mais complexos que os tratados na Resolução de anomalias, cuja solução não se esgota no âmbito de um único projeto, embora comumente se origine de algum dos projetos em execução.

 

Glossário

ePub Criptografado

 

 

Este glossário procura, sempre que possível, ser coerente com as definições contidas nos padrões do IEEE [IEEE03], PMBoK [PMI17], CMMI [CMMI06], UML [Rumbaugh+05, OMG05], P-CMM [Curtis+01] e SPEM [OMG08]. Diferenças, quando introduzidas, destinam-se à compatibilização entre esses padrões, adaptações em relação ao processo Praxis ou simplificações de natureza didática. As definições com a indicação “Praxis” são definições incorporadas ao processo Praxis, sem que estejam explícitas em alguma das fontes acima; geralmente são tiradas de livros especializados no respectivo assunto, ou de dicionários de uso geral.

TERMO

VERSÃO EM INGLÊS

DEFINIÇÃO

Abstrato

Abstract

(UML) Classificador que não pode ser instanciado.

Ação

Action

(UML) Nodo de atividade primitivo, cuja execução resulta em uma mudança de estado do sistema ou devolução de um valor. Cf. atividade, nodo de atividade.

 

Detalhes do Produto

Livro Impresso
Book
Capítulos

Formato
ePub
Criptografado
Sim
SKU
BPE0000271062
ISBN
9788521636731
Tamanho do arquivo
16 MB
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
Formato
ePub
Criptografado
Sim
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
SKU
Em metadados
ISBN
Em metadados
Tamanho do arquivo
Em metadados