Mestrado em Informática e Sistemas 2017/2018

Metodologias de Desenvolvimento de Software

Aplicação do processo da Critical Software ao caso de

estudo “Titanic Books”

Ana Carolina Janeiro

Maria Inês Cruz

21 Novembro 2017

Resumo
Este relatório apresenta a aplicação e adaptação de um processo já definido pela Critical Software, a
um caso de estudo específico que neste relatório será o “Titanic Books”. Será resumido o caso de
estudo e explicadas as várias opcões de tailoring efectuadas no processo. Por fim, serão
especificadas cada uma das fases do ciclo de vida do processo assim como a justificação das opções
tomadas.
1. Introdução
Em Setembro de 2009, Charles Saley, CEO da empresa Titanic Books decidiu oferecer à sua
companhia 80 000 livros em formato eletrónico. Como é possível verificar, hoje em dia qualquer
comércio tem a sua plataforma online e como tal Saley também decidiu colocar os seus livros à
venda online garantindo assim a viabilidade da empresa na próxima década. Ele acha que para
garantir o sucesso, o sistema deverá estar pronto a utilizar em Setembro de 2010.
Saley marcou então uma reunião com o chefe do departamento de informação, Gregor Padalka,
no qual tinha total confiança, e propôs-lhe então que ficasse a liderar a implementação deste
projeto. O que mais preocupava Saley era a qualidade das páginas reproduzidas quando visualizadas
eletronicamente, a singularidade do serviço e a segurança dos seus ativos devido à pirataria
eletrónica. Sublinhou ainda que não queria que o consumidor necessitasse de comprar hardware
adicional e que a experiência de venda fosse semelhante à de uma livraria, mas realizada
exclusivamente na web. Estabeleceu então o prazo de duas semanas para o projeto ser iniciado.
Padalka reuniu então com os desenvolvedores e com o chefe de marketing e vendas, Sven
Torsen, onde percebeu que iria ser um grande projeto, que era necessário cerca de 300 KLOCS para
este sistema, que seria o seu primeiro grande projeto, o que lhe daria algumas vantagens. O maior
sistema que tinham desenvolvido tinha 80 KLOCS (maior parte código reutilizado) e demorou 6
meses com 15 desenvolvedores. Torsen concordou com ele e acrescentou que como a Titanic Books
tinha uma relação com vendedores privados e livrarias de universidades, que contém 80% das
vendas da empresa não seriam postos de parte neste projeto.
Depois de duas semanas foi então entregue o projeto com os vários requisitos descritos, entre
os quais:
• qualidade na reprodução de cada página eletrónica;
• serviço único;
• segurança dos ativos face a pirataria eletrónica;
• cliente não deve precisar de hardware adicional;
• a experiência de venda deve ser comparável à de uma loja física, mas feita
exclusivamente através da internet;
• tem de estar comercialmente viável em Setembro de 2010 (1 ano);
• será necessário manter relação com livrarias privadas e de universidades;
• o cliente tem de visitar uma loja antes de aderir ao serviço eletrónico, sendo essa a
única forma de aderir;
• a loja fica com o email do cliente e cartão de crédito, valida os dados e envia um link
para o cliente;
• cliente faz download do software e manual de utilizador e define a chave
pública/privada;
• cliente não precisa de voltar a inserir o cartão de crédito online;
• cliente pode visitar a loja ou ligar para apoio personalizado;
• loja tem histórico completo do cliente;
 • cliente pode, além de comprar online: comprar livro físico com desconto substancial na
loja física; comprar livro quer físico quer eletrónico com desconto; comprar só livro
eletrónico na loja física;
• cliente pode fazer download ao chegar a casa;
• revendedores recebem uma percentagem do livro original;
• revendedores recebem uma taxa todos os meses para dar apoio ao cliente;
• todas as cópias dos livros utilizam Public Key Encryption.
Este texto é baseado em [1].

2. Ciclo de vida

De acordo com a norma ISO/IEC 12207:2008 [4], para ajustar o ciclo de vida de um projeto é
necessário identificar e documentar as circunstâncias que influenciam o tailoring. Estas influências
incluem:
a) Estabilidade e variedade de ambientes operacionais;
b) Riscos, comerciais ou de performance, que digam respeito às partes interessadas;
c) Novidade, tamanho e complexidade;
d) Data de início e duração da utilização;
e) Questões de integridade como segurança, privacidade, usabilidade e disponibilidade;
f) Oportunidades de tecnologias emergentes;
g) Perfil de orçamento e recursos organizacionais disponíveis;
h) Disponibilidade dos serviços de sistemas;
i) Papéis e responsabilidades em todo o ciclo de vida do sistema;
j) A necessidade de respeitar outras normas.
Tendo estas questões em consideração, para dar resposta aos requisitos do projeto, foi definido o
ciclo de vida seguinte:

Figura 1 – Ciclo de vida

Na definição do ciclo de vida da Figura 1, foram tidos em conta os seguintes aspetos:

- Um dos requisitos apresentados foi o sistema estar comercialmente viável no prazo de um ano (em
Setembro de 2010). Por esse motivo, a data final para a fase de aceitação foi definida como sendo
23 de Setembro de 2010;
- Uma vez que os requisitos se encontram já bem definidos no caso de estudo, optou-se por juntar
as fases de engenharia do sistema e de engenharia dos requisitos. Atribuiu-se a duração de um mês
a esta fase, com base no histórico da empresa;
- O maior sistema desenvolvido até à data pela empresa havia sido de 80 KLOC, sendo metade do
código reutilizado e tendo demorado 6 meses com 15 developers. Para sistemas do tipo do
pretendido neste projeto, a estimativa da indústria ronda os 300 KLOC. Assim, pressupondo que a
empresa não tem developers suficientes para o desenvolvimento de um sistema desta dimensão,
foram ponderadas duas alternativas: outsourcing ou contratação de novos colaboradores. Uma vez
que o CEO considera que esta é uma oportunidade para a empresa para produzir um sistema deste
tipo, optou-se por incluir uma nova fase no ciclo de vida para contratação e formação de 10 novos
colaboradores. Este colaboradores, especializados na área, irão integrar o processo a partir da fase
de engenharia do design e pré-validação;
- De acordo com [3], quanto maior o projeto, maior o risco de incumprimento dos prazos, de
mudança dos requisitos e de problemas de aceitação. Para reduzir estes riscos, a fase de engenharia
do design e pré-validação foi particionada em incrementos (módulos ou builds), ajustados à
dimensão do projeto. Cada um destes módulos é testado e validado individualmente, antes de
passar à fase seguinte;
- Na fase de validação, é testada a validação de todos os módulos integrados. Esta fase foi reduzida,
uma vez que ao chegar a esta fase todos os módulos foram já pré-validados na fase anterior;
- A fase de aceitação tem a duração de 2 meses (baseada no histórico da empresa), sendo utilizada
uma equipa já contratada pela empresa para outros projetos;
- A aplicação terá uma única release, tendo em conta a sua dimensão (cerca de 300 KLOC);
- Por fim, a fase de operações e manutenção não apresenta data de término, uma vez que o sistema
será utilizado pela própria empresa desenvolvedora, que dará suporte permanente à aplicação.

2.1. Fase de engenharia do sistema e dos requisitos – Ana Carolina Janeiro

Optou-se por juntar as fases de engenharia do sistema e dos requisitos e reduzir o seu tempo
para 1 mês, uma vez que os requisitos se encontravam bem definidos no caso de estudo.
Uma vez que o cliente do projeto é a própria empresa desenvolvedora, considera-se que o
critério de entrada consistirá, apenas, nas necessidades e requisitos do cliente, não sendo necessário
o statement of work (SoW), request for proposal (RFP) ou request for information (RFI). Nesta fase, o
milestone a ser atingido consiste no relatório preliminar de análise do design.
Nesta fase, será preparada uma especificação técnica, de forma a responder às necessidades do
cliente, incluindo uma definição das funções da aplicação, da user interface, da performance, custos,
planeamento e planos de implementação para todos os níveis do software a ser desenvolvido. É,
ainda, necessário verificar que estes requisitos estão completos e são viáveis. É importante verificar
que os requisitos são compreendidos da mesma forma pela equipa de desenvolvedores e pelo CEO
que requereu a aplicação, visto tratar-se de uma aplicação fundamental para a continuidade da
Titanic Books. Poderão ser utilizados mockups para ilustrar a visão da equipa de desenvolvimento e
verificar se esta se encontra alinhada com a visão do CEO ou descobrir requisitos desconhecidos.
Considera-se, ainda, necessário identificar o software previamente desenvolvido que pode ser
reutilizado no projeto, pesando as vantagens e desvantagens de incorporar componentes pré-
existentes.
Nesta fase participam, fundamentalmente, engenheiros de software/ arquitectos e designers de
interação com utilizadores, que trabalham em colaboração próxima com o representante dos
utilizadores, neste caso o CEO e os responsáveis das livrarias dos campus e privadas, de forma a
avaliar a usabilidade da aplicação.
Esta fase fica completa com o relatório preliminar de análise do design. Os inputs para este
relatório incluem, assim, a especificação dos requisitos de software, a arquitetura do sistema, o
documento preliminar de controlo da interface e pré-visualizações da solução (como mockups). No
projeto em causa, o CEO da empresa, de quem partiu a ideia para o desenvolvimento da aplicação,
deverá aprovar a especificação técnica de forma a verificar se esta se encontra de acordo com a sua
visão, uma vez que esta fase é extremamente importante para a construção do software.
É, também, importante medir o progresso do projeto de forma a verificar a eficácia da gestão.
Entre as medidas a avaliar nesta fase encontram-se: unidades identificadas/designed, requisitos a
ser determinados, alterações de requisitos, esclarecimentos de requisitos, horas do staff, estimativas
do tamanho do sistema, esforço, planeamento e reutilização de código.

2.2. Fase de engenharia do design e pré-validação – Ana Carolina Janeiro

Tendo em conta a dimensão do projeto, para reduzir o risco associado, a fase de engenharia do
design e pré-validação foi particionada em incrementos (módulos ou builds), ajustados à dimensão
do projeto. Cada um destes módulos será testado e validado individualmente, antes de passar à fase
seguinte. Esta fase tem a duração de 8 meses, tendo o tempo alocado sido baseado no histórico da
empresa. Contará, ainda, com 15 developers com experiência na empresa e 10 novos colaboradores
(estes últimos a partir de Janeiro), de forma a implementar os 300 KLOC previstos para a aplicação.
Esta fase tem como critério de entrada a especificação técnica definida na fase anterior e como
milestone o relatório de análise do design crítico.
Nesta fase é produzido o design detalhado do software, a especificação detalhada da user
interface, o código do software e os testes unitários de cada componente. São, ainda, preparadas as
especificações dos testes de usabilidade do sistema, a utilizar na fase seguinte. O facto de o design
detalhado ser produzido em simultâneo com o código fonte permite que o design seja gerado a
partir do código, com recurso a ferramentas de reengineering. Além disso, ao usar testes unitários
em paralelo com o código, torna-se possível identificar e corrigir erros com antecedência.
No design detalhado é, também, definido o plano de implementação que indica a sequência a
seguir para a programação e integração dos vários módulos. Alguns destes são implementados em
simultâneo.
Na implementação do software, todos os módulos são integrados no sistema e testados (testes
unitários e de integração) de forma a garantir que funcionam corretamente.
A implementação considera-se completa quando todo o código tenha sido sujeito a revisão por
parte dos pares, testado e integrado no sistema.
 Como métricas para esta fase utilizam-se: horas de CPU, unidades implementadas/código
certificado/código testado vs unidades identificadas, esclarecimentos de requisitos, requisitos a ser
determinados e alterações de requisitos, estimativas do tamanho do sistema, esforço, planeamento
e reutilização de código, horas de staff, SLOC (linhas de código fonte) em bibliotecas controladas
(acumulado) e alterações e erros (por categoria).

2.3. Fase de formação de novos colaboradores – Ana Carolina Janeiro

Introduziu-se esta fase no ciclo de vida, uma vez que se pressupôs que a empresa não tem
developers suficientes para desenvolver um sistema da dimensão pretendida (300 KLOC). O seu
histórico demonstra que, até à data, o maior sistema desenvolvido pela empresa havia sido de 80
KLOC, sendo metade do código reutilizado e tendo demorado 6 meses com 15 developers. Foram,
assim, ponderadas duas alternativas: outsourcing ou contratação de novos colaboradores. Uma vez
que o CEO considera que esta é uma oportunidade para a empresa para produzir um sistema deste
tipo, optou-se por incluir uma nova fase no ciclo de vida para contratação e formação de 10 novos
colaboradores. Estes colaboradores, especializados na área, irão integrar o processo a partir da fase
de engenharia do design e pré-validação, a partir de Janeiro. Irão, desta forma, auxiliar na
implementação do projeto, de forma a cumprir a deadline.

2.4. Fase de validação – Maria Inês Cruz

Segundo a norma ISO/IEC 12207:2008 [4] para o processo de validação ser corretamente
efetuado é necessário definir uma estratégia de validação, incluindo a definição de critérios de
validação.
A estratégia de validação definida passa então pela validação por partes, ou seja, sendo
definidos vários módulos, que são validados ainda na fase de engenharia do design, e depois a
validação da integração destes módulos, resultando no software final. Posto isto decidimos diminuir
o tempo atribuído a esta fase, tendo a duração de um mês.
Esta fase tem como critério de entrada o design efetuado na fase anterior e relatórios dos
resultados das atividades de validação de cada módulo, e tem como milestone uma revisão da
qualificação do software com os módulos integrados.
Nesta fase é necessário testar o script, fazer testes de integração dos vários módulos, relatórios
de não conformidade de software, relatórios com os testes efetuados e elaborar manuais de
instalação e utilização do software tanto para os funcionários das lojas físicas como para os clientes.
No final desta fase é necessário provar que o software desenvolvido é adequado ao uso
pretendido, realizando relatórios que contenham todos os resultados das atividades de validação
para serem apresentados ao cliente e a todas as partes envolvidas no projeto, neste caso as livrarias
privadas e de universidades.

2.5. Fase de aceitação – Maria Inês Cruz

Para realizar esta fase, como o cliente é a própria empresa desenvolvedora do software foi
decidido que seria escolhida uma equipa especializada já contratada para outros projetos da
empresa. Esta equipa deverá trabalhar em conjunto com a equipa de desenvolvedores, e esta fase
terá a duração de 2 meses.
Nesta fase os critérios de entrada serão o plano de validação da fase anterior ser executado com
sucesso e manuais de utilizador e de instalação do software concluídos. E os milestones serão os
testes de aceitação executados com sucesso, sistema aceite e entregue e um relatório com o
histórico do desenvolvimento do software. [3]
É importante que a equipa de aceitação trabalhe com a equipa de desenvolvimento pois caso
haja algum problema no sistema, pode ser facilmente resolvido de imediato pelos desenvolvedores.
A equipa de aceitação prepara um plano com os testes de aceitação, executa esses testes de
acordo com o planeado, analisa e reporta os resultados obtidos, avalia o manual de utilizador e por
fim aceita formalmente o sistema.
A equipa de desenvolvedores deve dar suporte à equipa de aceitação, corrigir os erros
encontrados à medida que são executados os testes, ajuda a equipa de aceitação a lidar com o
sistema, aperfeiçoa a documentação do sistema e entrega o sistema completo.
Devem por fim elaborar em conjunto o relatório final de aceitação, com o histórico de todos os
testes efetuados.

2.6. Fase de operações e manutenção – Maria Inês Cruz

Uma vez que o sistema será utilizado pela empresa desenvolvedora, esta fase não terá fim,
tendo suporte e manutenção sempre se seja necessário.
Nesta fase os critérios de entrada são o relatório de aceitação elaborado na fase anterior e
não terá critérios de saída visto que não existe um contrato de manutenção.
É importante que nesta fase que o sistema tenha sido entregue, que se faça um plano de
manutenção, um relatório com a análise de problemas encontrados e um relatório de não
conformidade. É necessário também obter um relatório com o controlo das mudanças
efetuadas.
Nesta fase deve ser entregue o código fonte, o pacote dos dados, o relatório de não
conformidade, os pedidos de mudança de software, o plano de operações e manutenção e o
relatório de lançamento do software.

3. Conclusões

Foi possível concluir que para colocar em prática e com sucesso qualquer projeto de software é
necessário seguir os processos da empresa, adaptando-os às necessidades de cada projeto. Para
cada projeto existe uma adaptação das fases do ciclo de vida do processo e é necessário tomar as
decisões acertadas no começo para que tudo corra bem ao longo do desenvolvimento do projeto.
4. Referências
[1] Software Development Process Analysis. Retrieved 19 November 2017, from Instituto
Superior de Engenharia de Coimbra:
https://moodle.isec.pt/moodle/pluginfile.php/144709/mod_resource/content/0/MDS1718-
Assign1-SWProcess.pdf
[2] Software Development Process. s.l. : Critical Software. CSW-QMS-2002-SDP-0909,
2016-09-29
[3] NASA-SEL. Recommended Approach to Software Development, Revision 3. Greenbelt,
Maryland : NASA Goddard Space Flight Center, June 1992. SEL-81-305
[4] ISO/IEC 12207. Systems and software engineering – Software Life Cycle Processes.
Geveva : ISO, 2008. ISO/IEC 12207:2008(E); IEEE Std 12207:2008