Processos de Software
Introduzir modelos de processo de software
Descrever três modelos de processo genérico
e quando estes podem ser utilizados
Descrever modelos de delineamento de
processos para engenharia de requisitos, desenvolvimento de software, testes e evolução
Explicar o modelo Rational Unified Process
Introduzir a tecnologia CASE para apoiar
atividades de processo de software
modelos de processo de software
Iteração do processo
Atividades do Processo
O Rational Unified Process
Computer-Aidade Software Engineering -
CASE
Um conjunto estruturado de atividades
necessárias para desenvolver um sistema de software
◦ Especificação;
◦ Design (Projeto);
◦ Validação;
◦ Evolução.
Um modelo de processo de software é uma
representação abstrata de um processo. Ele apresenta uma descrição de um processo a partir de uma perspectiva particular.
O modelo em cascata
◦ Separa as fases distintas de especificação e desenvolvimento.
desenvolvimento evolucionário
◦ Especificação, desenvolvimento e validação são intercaladas.
engenharia de software baseada em componentes
◦ O sistema é montado a partir de componentes existentes.
Existem muitas variantes destes modelos por
exemplo, um desenvolvimento formal onde um
processo em cascata é usado, mas a especificação é uma especificação formal que é refinada através de várias etapas até chegar a um projeto implementável.
Requirements definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
Análise dos requisitos e definição
Design do sistema e do software
Implementação e teste das unidade
Integração e testes do sistema
Operação e manutenção
A principal desvantagem do modelo cascata
é a dificuldade de acomodar mudanças depois que o processo está em
andamento. Uma fase deve ser concluída antes de passar para a próxima fase.
Partição inflexível do projeto em estágios distintos,
torna difícil de atender às novas necessidades do cliente.
Portanto, este modelo só é apropriado quando os
requisitos são bem compreendidos e as alterações serão bastante limitadas durante o processo de
design.
Poucos Sistemas de negócios possuem requisitos
estáveis.
O modelo em cascata é utilizado principalmente para
grandes projetos de engenharia de sistemas em que um sistema é desenvolvido em diversos locais.
desenvolvimento exploratório
◦ O objetivo é trabalhar com clientes e evoluir para um sistema final a partir da especificação de um primeiro esboço. Deve começar com requisitos bem compreendidos e adicionar novos recursos, na medida em que forem propostos pelo cliente.
Prototipagem descartável
◦ Objetivo é entender os requisitos do
sistema. Deve começar com requisitos mal
entendidos para posterior esclarecimento do que realmente é necessário.
Concurrent activities
Validation versionFinal Development Intermediateversions
Specification versionInitial
Outline description
Problemas
◦ Falta de visibilidade do processo;
◦ Os sistemas são muitas vezes mal estruturados;
◦ habilidades especiais (por exemplo, em
linguagens para prototipagem rápida) podem ser necessárias.
Aplicabilidade
◦ Para sistemas interativos pequenos ou médios;
◦ Para pedaços de grandes sistemas (por exemplo,
a interface com o usuário);
◦ Para os sistemas de vida curta.
Baseado no reuso sistemático onde sistemas são
integrados a partir de componentes existentes ou Sistemas COTS (Commercial-off-The-Shell).
fases do processo
◦ análise de componentes;
◦ modificação dos requisitos;
◦ Projeto do Sistema com reutilização;
◦ Desenvolvimento e integração.
Esta abordagem vem sendo cada vez mais
utilizada na medida em que surgem novos componente.
Engenharia de Software baseada em
componentes
Desenvolvimento Orientado
à
Reutilização
Requirements specification Component analysis Development and integrationSystem design with reuse Requirements modification System validation
Requisitos de sistema SEMPRE evoluem ao
longo do projeto portanto a iteração do
processo onde os estágios iniciais são
retrabalhados, é sempre parte do processo
para sistemas de grande porte.
Iteração pode ser aplicada a qualquer um
dos modelos de processo genéricos.
Duas abordagens (relacionadas)
◦ entrega incremental;
◦ desenvolvimento em espiral.
Ao invés de entregar o sistema de uma vez, o
sistema é entregue dividido em incrementos, cada um contendo partes da funcionalidade necessária.
Requisitos do usuário são priorizados e os
requisitos de prioridade mais alta são incluídos nos incrementos iniciais.
Uma vez que o desenvolvimento de um
incremento é iniciado, os requisitos são congelados apesar dos requisitos dos
incrementos posteriores continuarem a evoluir.
Validate increment Develop system increment Design system architecture Integrate increment Validate system Define outline requirements Assign requirements to increments System incomplete Final system
desenvolvimento incremental
Respostas do cliente podem ser fornecidas
em cada incremento, assim a
funcionalidade do sistema está disponível mais cedo.
Incrementos iniciais atuam como um
protótipo para ajudar a obter os requisitos dos incrementos posteriores.
Menor risco de fracasso do projeto global.
A prioridade maior é dada para serviços que
tendem a receber mais testes
Uma abordagem ao desenvolvimento
baseada no desenvolvimento e entrega de pequenos incrementos funcionais.
Confia na melhora constante do código,
envolvimento do usuário com a equipe de desenvolvimento e programação em pares.
Abordados posteriormente
O Processo é representado como uma
espiral em vez de uma seqüência de atividades com retorno.
Cada volta na espiral representa uma fase
do processo.
Nenhuma fase fixa como especificação ou
projeto – as voltas na espiral são escolhidas dependendo do que for necessário.
Os riscos são explicitamente avaliados e
resolvidos ao longo do processo.
Risk analysis Risk analysis Risk analysis Risk analysis Proto-type 1 Prototype 2
Prototype 3 Opera-tional protoype
Concept of Operation
Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration test Acceptance test
Service Develop, verify
next-level product Evaluate alternatives, identify, resolve risks Determine objectives,
alternatives and constraints
Plan next phase
Integration and test plan Development
plan Requirements plan
Life-cycle plan REVIEW
Definição dos objetivos
◦ Os objetivos específicos para a fase são identificados.
A avaliação e redução dos riscos
◦ Os riscos são avaliados e as atividades postas em prática para reduzir os principais riscos.
Desenvolvimento e validação
◦ Um modelo de desenvolvimento para o sistema
escolhido, que pode ser qualquer um dos modelos genéricos.
Planejamento
◦ O projeto é revisado e a próxima fase da espiral é planejada.
Especificação de Software
Concepção e implementação do software
Validação de Software
Evolução do Software
O processo de estabelecer quais serviços
são necessários e as restrições no sistema
de operação e desenvolvimento.
Processo de engenharia de requisitos
◦ Estudo da viabilidade;
◦ Descoberta e análise dos requisitos; ◦ Especificação de requisitos;
◦ Validação dos requisitos.
Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models
User and system requirements
Requirements document
O processo de converter a especificação do
sistema em um sistema executável.
Projeto de Software
◦ Projetar uma estrutura de software que realiza a especificação;
Implementação
◦ Traduzir essa estrutura em um programa executável;
As atividades de projeto e implementação
estão intimamente relacionadas e podem ser intercaladas.
A concepção arquitetônica
especificação abstrata
Projeto da interface
Projeto dos componentes
Projeto das Estruturas de Dados
Projeto do Algoritmo
Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Requirements specification
Design activities
Design products
Abordagens sistemáticas para desenvolver
um projeto de software.
O projeto é geralmente documentadas
como um conjunto de modelos gráficos.
Possíveis modelos
◦ modelo de objeto;
◦ modelo de seqüência;
◦ modelo da transição de estados;
◦ modelo estrutural;
◦ Modelo de fluxo de dados.
Traduzir um projeto em um programa e
remover erros do programa.
A programação é uma atividade pessoal -
não há processo genérico de programação.
Programadores realizam testes para
descobrir falhas no programa e remover essas falhas no processo de depuração.
Locate error
Design
error repair Repairerror programRe-test
Verificação e validação (V & V) é a intenção
de mostrar que o sistema está de acordo com sua especificação e cumpre os
requisitos do cliente do sistema.
Envolve verificar e testar processos e o
sistema.
teste de sistema envolve executar o
sistema com casos de teste que são
derivados da especificação dos dados reais a serem processados pelo sistema.
Component
testing Systemtesting Acceptancetesting
testes de unidades e componentes
◦ Os componentes individuais são testados de forma
independente;
◦ Os componentes podem ser funções ou objetos ou
agrupamentos coerente dessas entidades.
Teste do Sistema
◦ Teste do sistema como um todo. Os testes das
propriedades emergentes é particularmente importante.
Os testes de aceitação
◦ Testes com dados do cliente para verificar se o sistema atende as necessidades do cliente.
Requirements specification System specification System design Detailed design Module and unit code and test Sub-system integration test plan System integration test plan Acceptance test plan Service Acceptance test System integration test Sub-system integration test
fases de testes
Um Software é inerentemente flexível e
pode sofrer mudanças.
Como os requisitos mudam através da
alteração das circunstâncias de negócios, o software utilizado pelo negócio também
deve evoluir e mudar.
Embora haja uma demarcação entre
desenvolvimento e evolução (manutenção), isto é cada vez mais irrelevante, menos e menos sistemas são completamente novos.
Assess existing systems Define system requirements Propose system changes Modify systems New system Existing systems
evolução do sistema
Um modelo moderno de processo
desenvolvido a partir dos trabalhos sobre
a UML outros trabalhos relacionados.
Normalmente descrito a partir de 3
perspectivas
◦ A perspectiva dinâmica que mostra as fases ao longo do tempo;
◦ A perspectiva estática que mostra as atividades do processo;
◦ A perspectiva prática que sugere boas práticas.
Phase iteration
Inception Elaboration Construction Transition
Início
◦ Estabelecer o plano de negócios para o sistema.
Elaboração
◦ Desenvolver uma compreensão do domínio do
problema e da arquitetura do sistema.
Construção
◦ Projeto do Sistema, programação e testes.
Transição
◦ Implantar o sistema em seu ambiente
operacional.
Desenvolver software iterativamente
Gerenciar os requisitos
Uso de arquiteturas baseadas em
componentes
Modelar visualmente o software
Verificar a qualidade do software
controle das mudanças no software
Workflow Description
Business modelling The business processes are modelled using business use cases. Requirements Actors who interact with the system are identified and use cases are
developed to model the system requirements.
Analysis and design A design model is created and documented using architectural models, component models, object models and sequence models. Implementation The components in the system are implemented and structured into
implementation sub-systems. Automatic code generation from design models helps accelerate this process.
Test Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation.
Deployment A product release is created, distributed to users and installed in their workplace.
Configuration and change management
This supporting workflow managed changes to the system (see Chapter 29).
Project management This supporting workflow manages the system development (see Chapter 5).
Environment This workflow is concerned with making appropriate software tools available to the software development team.
Computer-Aided Software Engineering (CASE) é
um software de apoio ao desenvolvimento de software e de processos de evolução.
automação de atividades
◦ Editores gráficos para o desenvolvimento do modelo do sistema;
◦ Dicionário de dados para gerenciar entidades do projeto; ◦ Construtor gráfico da para auxílio na construção da
interface do usuário;
◦ Depuradores para auxílio no encontro de erros no programa;
◦ tradutores automáticos para gerar novas versões do programa.
tecnologia CASE tem levado a melhorias
significativas no processo de software. No
entanto, estas melhorias não são tão
importantes como previstos
◦ A engenharia de software requer pensamento
criativo - este não é facilmente automatizado;
◦ Engenharia de software é uma atividade em
equipe e, para grandes projetos, muito tempo é gasto em interações da equipe. As tecnologias CASE ainda não dão apoio a essas iniciativas.
Classificação nos ajuda a entender os diferentes
tipos de ferramentas CASE e seu suporte para o processo de atividades.
perspectiva funcional
◦ As ferramentas são classificadas de acordo com sua função específica.
perspectiva dos processos
◦ As ferramentas são classificadas de acordo com o processo de atividades que dão suporte.
Perspectivas de Integração
◦ As ferramentas são classificadas de acordo com a sua organização em unidades integradas.
Tool type Examples
Planning tools PERT tools, estimation tools, spreadsheets Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems Configuration management tools Version management systems, system building tools Prototyping tools Very high-level languages, user interface generators Method-support tools Design editors, data dictionaries, code generators Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic analysers Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems
Specification Design Implementation Verification and Validation Re-engineering tools Testing tools Debugging tools
Program analysis tools Language-processing tools
Method support tools Prototyping tools Configuration management tools
Change management tools Documentation tools
Editing tools Planning tools
classificação de ferramentas baseada na
atividades
Ferramentas
◦ Dão suporte a tarefas isoladas do processo, tais
como verificação de consistência do projeto, edição de texto, etc.
Bancadas - Workbenches
◦ Apoiam uma fase do processo como especificação
projeto, incluem normalmente um grande número de ferramentas integradas.
Ambientes
◦ Dão apoio a totalidade ou uma parte substancial de
todo o processo. Normalmente incluem várias bancadas integrada.
Single-method workbenches General-purpose workbenches Multi-method workbenches Language-specific workbenches Programming Testing Analysis and design Integrated environments Process-centred environments File comparators Compilers Editors Environments Workbenches Tools CASE technology
Processos de software são as atividades envolvidas na
produção e evolução de um sistema de software.
modelos de processos de software são representações
abstratas desses processos.
As atividades gerais são especificação, projeto e
implementação, validação e evolução.
modelos de processo genéricos descrevem a
organização dos processos de software. Exemplos incluem o modelo em cascata, desenvolvimento
evolucionário e engenharia de software baseada em componentes.
modelos de processo iterativos descrevem o processo
de software como um ciclo de atividades.
Engenharia de requisitos é o processo de
desenvolvimento de uma especificação de software.
Projeto e implementação transformam a
especificação em um programa executável.
A validação envolve verificar se o sistema atende às
suas especificações e necessidades do usuário.
A Evolução está preocupado com a modificação do
sistema após ele estar em uso.
O Rational Unified Process é um modelo de processo
genérico que separa as fases das atividades.
tecnologias CASE dão suporte às atividades de
processo de software.
