Download Biblioteca_477480.pdf PDF

TitleBiblioteca_477480.pdf
TagsSoftware Quality (Business) Software Engineering Science And Technology Software Development Process
File Size1.9 MB
Total Pages176
Document Text Contents
Page 1

autor

SAULO FRANÇA AMUI

1ª edição

SESES

rio de janeiro 2015

PROCESSOS DE
DESENVOLVIMENTO DE
SOFTWARE

Page 2

Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti;

helcimara afonso de souza

Autor do original saulo frança amui

Projeto editorial roberto paes

Coordenação de produção gladis linhares

Coordenação de produção EaD karen fernanda bortoloti

Projeto gráfico paulo vitor bastos

Diagramação bfs media

Revisão linguística bfs media

Imagem de capa semisatch | dreamstime.com

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida

por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em

qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2015.

Dados Internacionais de Catalogação na Publicação (cip)

A529p Amui, Saulo

Processos de desenvolvimento de software / Saulo Amui.

Rio de Janeiro : SESES, 2015.

176 p. : il.

isbn: 978-85-5548-040-9

1. Processos de software. 2. Engenharia de software.

3. Requisitos. 4. Métodos de desenvolvimento. I. SESES. II. Estácio.

cdd 005.1

Diretoria de Ensino — Fábrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus João Uchôa

Rio Comprido — Rio de Janeiro — rj — cep 20261-063

Page 88

88 • capítulo 3

3.Processos organizacionais: implementam uma estrutura constituída de

processos de ciclo de vida e pessoal associados, melhorando continuamente a

estrutura e os processos.

a) Gerência: gerenciamento de processos.

b) Infraestrutura: fornecimento de recursos para outros processos. Inclui:

hardware, software, ferramentas, técnicas, padrões de desenvolvimento, opera-

ção ou manutenção.

c) Melhoria: atividades para estabelecer, avaliar, medir, controlar e me-

lhorar um processo de ciclo de vida de software.

d) Treinamento: atividades para prover e manter pessoal treinado.

A norma detalha cada um dos processos mostrados. Ela define ainda como

eles podem ser usados de diferentes maneiras por diferentes organizações (ou

parte destas), representando diversos pontos de vista para esta utilização. Cada

uma destas visões representa a forma como uma organização emprega estes

processos, agrupando-os de acordo com suas necessidades e objetivos.

As visões têm o objetivo de organizar melhor a estrutura de uma empresa,

para definir suas gerências e atividades alocadas às suas equipes. Existem cinco

visões diferentes: contrato, gerenciamento, operação, engenharia e apoio.

A ISO/IEC 12207 é a primeira norma internacional que descreve em deta-

lhes os processos, atividades e tarefas que envolvem o fornecimento, desenvol-

vimento, operação e manutenção de produtos de software. A principal finali-

dade desta norma é servir de referência para os demais padrões que venham

a surgir. Lançada em agosto de 1995, ela é citada em quase todos os trabalhos

relacionados à engenharia de software desde então, inclusive aqueles relativos

à qualidade.

3.5 MPS.BR

A SOFTEX (Associação para Promoção da Excelência do Software Brasileiro),

com o apoio do Ministério da Ciência e Tecnologia (MCT), da FINEP (Finan-

ciadora de Estudos e Projetos) e do BID (Banco Interamericano de Desenvolvi-

mento), coordena um programa para a Melhoria de Processo do Software Brasi-

leiro, desde 2003, chamado de MPS.BR (Guia Geral MPS.BR, 2006, p. 4), sendo

um modelo de qualidade de processos das empresas de desenvolvimento de

Page 89

capítulo 3 • 89

software, com o objetivo de melhorar os processos e serviços a médio e longo

prazo, de acordo com as necessidades de negócio, buscando ainda o reconheci-

mento nacional e internacional como um modelo que seja aplicável à indústria

de software e serviços (De BONA e SANTOS, 2012).

De acordo com o Guia Geral MPS.BR (2006, p. 5), para que as empresas bra-

sileiras se posicionem em um cenário competitivo em relação à outras empre-

sas de desenvolvimento de software do mundo, elas necessitam que seus em-

preendedores coloquem a eficiência e a eficácia dos seus processos em foco nas

empresas, oferecendo produtos de softwares com a qualidade proporcional e

conforme padrões internacionais de qualidade

Guias do MPS.BR

Busca-se que ele seja adequado ao perfil de empresas com diferentes tamanhos e ca-

racterísticas, públicas e privadas, embora com especial atenção às micros, pequenas e

médias empresas. Também espera-se que o MPS.BR seja compatível com os padrões de

qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de

toda a competência existente nos padrões e modelos de melhoria de processo já disponí-

veis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos

de melhoria de processo e atende a necessidade de implantar os princípios de Engenharia

de Software de forma adequada ao contexto das empresas brasileiras, estando em con-

sonância com as principais abordagens internacionais para definição, avaliação e melhoria

de processos de software .

O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a ava-

liação e melhoria da qualidade e produtividade de produtos de software e serviços corre-

latos. Dentro desse contexto, o MPS.BR possui três componentes: Modelo de Referência

(MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS).

O MPS.BR está descrito através de documentos em formato de guias:

• Guia Geral: contém a descrição geral do MPS.BR e detalha o Modelo de Referência

(MR-MPS), seus componentes e as definições comuns necessárias para seu entendi-

mento e aplicação.

• Guia de Aquisição: descreve um processo de aquisição de software e serviços corre-

latos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de

software e serviços correlatos apoiando-se no MR-MPS.

• Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisi-

tos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA).

Guia Geral MPS.BR (2006, p. 6)

Page 175

capítulo 5 • 175

podendo passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja

disponibilizar o sistema a funcionar, devido à Dificuldade em responder a mudanças dos

requisitos.

03. Letra “e”

04. Letra “e”

Capítulo 5

01. Alguns exemplos de ferramentas que poderão ser citadas são:

System Architect

Rational Rose

Oracle Designer

GDPro

Power Designer

Silverrun

ERWin

Genexus

02. Algumas das principais vantagens das ferramentas CASE:

Uniformização do processo de desenvolvimento, das atividades realizadas e dos artefatos

produzidos.

Reutilização de vários artefatos ao longo do mesmo projeto, e entre projetos, promoven-

do o consequente aumento da produtividade.

Automatização de atividades, com particular destaque ao nível da geração de código e

de documentação.

Diminuição do tempo de desenvolvimento, recorrendo à geração automática de diversos

artefatos do projeto, ou à reutilização de outros previamente existentes.

Integração de artefatos produzidos em diferentes fases do ciclo de desenvolvimento de

software, em que as saídas de uma ferramenta são utilizadas como entrada de outra.

Demonstração da consistência entre os diversos modelos e possibilidade de verificar a

correção do software.

Qualidade do produto final superior, pois a utlização de ferramentas impõe um rigor que

obriga a uma abordagem mais estruturada no processo de desenvolvimento.

03. As fases do Processo Unificado podem ser divididas em:

Concepção (Inception) – entendimento da necessidade e visão do projeto,

Elaboração (Elaboration) – especificação e abordagem dos pontos de maior risco,

Construção (Construction) – desenvolvimento principal do sistema,

Page 176

176 • capítulo 5

Transição (Transition ou Deployment) – ajustes, implantação e transferência de proprie-

dade do sistema

04. Apesar de parecer um modelo em cascata, na verdade cada fase é composta de uma

ou mais iterações. Estas iterações são em geral curtas (1-2 semanas) e abordam algumas

poucas funções do sistema. Isto reduz o impacto de mudanças, pois quanto menor o tempo,

menor a probabilidade de haver uma mudança neste período para as funções em ques-

tão.Além das fases e iterações, existem os workflows. Cada workflow é na verdade uma

sequência de tarefas encadeadas e relacionadas a um aspecto importante do projeto, tal

como análise do negócio, testes etc.

05. Letra “c”

Similer Documents