Sobre este projeto
it-programming / web-development
Aberto
O joguinho é um simulador de processos de engenharia de software (Ver imagem anexada)
Basicamente o usuário é o dono de uma empresa e ele irá lidar com o desenvolvimento de um software.
O usuário deverá configurar os processos que irão ser feitos durante a construção do produto final (por exemplo: o modelo em cascata onde tem-se 1-Levantamento de requisitos, 2-Projeto, 3- Implementação, 4-Validação, 5- entrega) e definir qual é a dificuldade de cada tarefa dessa.
Após isso ele irá configurar seus funcionários, que serão os roles: desenvolvedor, analista, designer, etc. Todos os roles existentes na engenharia de software.
Ele irá dizer a habilidade desses funcionários em cada uma das tarefas que ele criou previamente. Por exemplo: um densevolvedor é muito bom em Desenvolvimento, mas ruim em Levantamento de requisitos.
Algumas regrinhas deverão ser seguidas durante o jogo, uma parte delas não se aplica pois talvez não haja como implementar, mas a grande maioria é possível. Vou coloca-las abaixo:
1. If you don’t do a system architectural design with well-defined interfaces,
integration will be a big mess [134].
2. Design before coding [134].
3. If a project is late and you add more people, the project will be even later [22].
4. Team members that are new to a project are less productive (1/3 to 2/3 less)
than the adequately trained people [18].
5. The average newly hired employee is about half as productive as an experienced
employee [2].
6. Two factors that affect productivity are work force experience level and level of
project familiarity due to learning-curve effects [2].
7. Developers’ productivity varies greatly depending on their individual skills
(experience concerning a development activity, knowledge of the tools,
methods, and notations used, etc.) [18, 26, 121].
8. Using better and fewer people is more productive than using more less qualified
people [18].
9. The greater the number of developers working on a task simultaneously, the
faster that task is finished, but more overall effort is required due to the growing
need for communication among developers. Thus, the productivity of the
individual developer decreases [22].
10.
The earlier problems are discovered, the less the overall cost will be [47].
262
11. The error detection effectiveness of reviews depends greatly on the
qualifications and preparations of the reviewers and the completeness and
correctness of the documents used as a reference [145].
12. Reviews of non-technical documents (e.g., Requirements specification, user
manual) are more effective if the customer is involved [111].
13. Develop tests before doing the coding [10].
14. Extreme time pressure leads to decreased productivity [47].
15.
Extreme time pressure leads to a faster rate at which errors are made, which
leads to a further delay in the completion date [91].
16. Error correction is most efficiently done by the document’s author(s) [47].
17. The more errors a document from a previous phase contains, the more errors
will be passed on to the next document [47].
18.
Always test everything [134].
19. Talk to users, not to customers to verify the prototype [134].
20. Inspection is the most cost-effective measure of finding problems in
software [134].
21.
Software inspections find a high percentage of errors early in the development
life cycle [141].
22. The use of inspections can lead to defect prevention, because developers get
early feedback with respect to the types of mistakes they are making [141].
23. Every group has one programmer that is 10 times more productive than
everyone else [121].
24.
If you disable Internet surfing, productivity will go down [141].
263
25. The structure of the software reflects the structure of the organization that
developed it [37].
26. Changing requirements are inevitable. Anticipating change with open
architectures, adaptable designs, and flexible planning can help to mediate some
of the ill effects of these changes [45].
27. Design for change/variability [45].
28.
Use defensive programming [31].
29. Configuration management is good [134].
30. Successful software is designed by people who understand the application of the
software (e.g., A well-designed missile control program was designed by
someone who understood missiles) [72].
31. Software development requires a substantial time commitment to learning the
application domain [42].
32. Broad application knowledge is acquired more through relevant experience than
through training [42].
33.
The more bugs you find, the more buggy the rest of your program will likely
be [95].
34. Tests reveal errors in the code.
The better a test is prepared for, the higher
amount of detected errors [134].
35. Sticking with a too-tight schedule increases cost due to a large work force [2].
36. Motivation is increased through monetary incentives (profit sharing, pay for
performance, merit pay, work measurement with incentives, and morale
measurement), creating a positive frame of mind at work (employee
264
involvement in wellness programs and creating fun at work), encouraging a
feeling of commitment and responsibility (worker participation in decisionmaking,
getting employees to think like owners, self-managing work teams,
commitment to productivity breakthroughs, and providing an environment with
more freedom and less restrictions), and increasing schedule pressure (using
visible milestones and setting individual goals.) Increased motivation leads to
increased productivity which reduces cycle time [141].
37. Improving the work environment is done by making ergonomic considerations,
giving employees enclosed offices to reduce background noise and
interruptions, and giving employees access to required resources, such as
computers, software tools, support staff, and information.
Improving the work
environment leads to increased productivity, which reduces cycle time [141].
38. Getting the most out of employees can be done by utilizing experts, employee
training, skills assessment and job matching, and reducing turnover.
Getting the
most out of employees leads to increased productivity, which leads to decreased
cycle time [141].
39. Improving the software development process can be done by formalizing the
process, controlling quality, and taking advantage of tools.
Improving the
software process increases employees’ motivation, which also increases their
productivity [141].
40. Rework is usually due to customer requirements, product flaws, and
communication breakdown between project members.
Improving the process to
reduce rework can be done by using prototyping and evolutionary development
265
and by using formal specification methods, modern programming practices, and
inspections. Reducing rework increases productivity [141].
41.
Design complexity can be reduced by using object-oriented design techniques.
Reducing design complexity reduces product complexity, which increases
productivity [141].
42.
Code complexity can be reduced by using modularization and object-oriented
programming techniques. Reducing code complexity reduces product
complexity, which increases productivity [141].
43.
Cognitive complexity can be reduced by modularization, multiple levels of
abstraction, simulation, and prototyping. Reducing cognitive complexity
reduces product complexity, which increases productivity [141].
44.
Test complexity can be reduced by using testing tools, building the product with
testing in mind, and testing for the type of environment a product will be used
in. Reducing test complexity reduces product complexity, which increases
productivity [141].
45.
Management complexity can be reduced by using project management planning
tools and methods. Reducing management complexity reduces product
complexity, which increases productivity [141].
46.
Tasks can be eliminated or simplified by using automation of tasks (e.g., Code
generators, automated testing) and eliminating non-value added activities and
low-priority tasks. This leads to increased productivity [141].
47.
Nine ways to reduce cycle time are: increase productivity, reduce rework,
maximize software reuse, reduce product complexity, eliminate or simplify
266
tasks, maximize task concurrency, reduce undiscovered work, reduce risk, and
use process models aimed at cycle time reduction [141].
48. Productivity is increased by increasing motivation, improving the work
environment, getting the best people for the job, improving the process, and
maximizing reuse [141].
49. Product complexity can be reduced by reducing code complexity, design
complexity, cognitive complexity, test complexity, and management
complexity [141].
50.
Decisions made in the upstream portion of the software development process
(requirements and design) impact productivity, quality, and costs throughout the
life cycle more than the other portions [42].
51. The thin spread of application domain knowledge is a major phenomenon that
greatly reduces software productivity and quality [42].
52. Specification mistakes often occur when designers do not have sufficient
application knowledge to interpret the customer’s intentions from the
requirements document [42].
53.
Requirements will appear to fluctuate when the development team lacks
application knowledge and performs an incomplete analysis of the
requirements [42].
54. Coordinating understanding of an application and its environment requires
constant communication between customers and developers [42].
55. Specifications are almost always incomplete and fraught with ambiguities.
Constant contact with the customer is required to obtain the correct
267
requirements.
Without this communication, the developers tend to make
incorrect assumptions about what the customer wants [45].
56. Fluctuating and conflicting requirements is a major phenomenon that greatly
reduces software productivity and quality [42].
57. Communication and coordination breakdown is a major phenomenon that
greatly reduces software productivity and quality [42].
58.
Truly exceptional designers that are extremely familiar with the application
domain, skilled at communicating their technical vision to other project
members, possess an exceptional ability to map between the behavior required
of the application system and the computational structures that implement the
behavior, and are recognized as the “intellectual core” of the project are a scarce
resource [42].
59. New requirements frequently emerge during development since they could not
be identified until portions of the system had been designed or
implemented [42].
60. Besides a developer’s ability to design and implement programs, his skills in
resolving conflicting requirements, negotiating with the customer, ensuring that
the development staff shares a consistent understanding of the design, and
providing communications between two contending groups are crucial to project
performance [42].
61.
Undiscovered work (work that was not considered in initial planning estimates)
can be reduced by using formal methods, analysis of PERT sizing metrics, the
268
Spiral life cycle model, and prototyping. Reducing undiscovered work leads to
increased productivity [141].
62.
Risk can be reduced by using risk management techniques. Reducing risk leads
to increased productivity [141].
63.
Inspections should be thought of as part of the development process, and time
must be set aside accordingly. Once this is done, inspections can have a
significant improvement in the development organization’s ability to meet
internal schedules [141].
64.
Proper use of inspections can even shorten life cycle [141].
65. Participants in the inspection team get a high degree of product knowledge,
which leads to higher productivity [141].
66. Slower programmers show a great deal of improvement when using
inspections [141].
67.
A new project assignee does not become productive until six months to a year
into the project [42].
68. Collaborators use hand gestures to uniquely communicate significant
information [139].
69. Employers often limit the number of hours employees can work, resulting in
further pressure to finish a project as quickly as possible [45].
70.
The customer often changes deadlines to be earlier than originally agreed-upon,
requiring negotiation with the customer for either allowing some deliverables to
be delivered at the earlier date, with the rest being delivered later, or dropping
some deliverables or requirements altogether [45].
269
71. Code comments and documentation are often produced at the end of a project,
creating major problems when a team member is lost at short notice, leaving
others to continue their work.
This can be alleviated by having quality auditors
require inspections at very short notice [45].
72. Teams often change during projects (members are added and/or removed.)
[45].
73. Sometimes the software used for development is upgraded to a new version
during development, and despite claims that it is fully backward-compatible and
won’t affect their work, it usually introduces new problems [45].
74. Hardware crashes, and customers are often unsympathetic to this kind of
delay [45].
75.
When a project is in its later stages of development, the development hardware
and software tend to be under the greatest demand, and performance starts to
suffer with lengthy compilations, builds, and test runs [45].
76. Matching the tasks to the skills and motivation of the people available increases
productivity [18].
77. Employee motivation is the strongest influence of productivity [18].
78.
Above a certain threshold, work conditions are not a powerful motivator, but
below that threshold, they are a powerful de-motivator [18].
79. The training of new employees is usually done by the “old-timers,” which
results in a reduced level of productivity on the “old-timer’s” part.
Specifically,
on the average, each new employee consumes in training overhead 20% of an
experienced employee’s time for the duration of the training or assimilation
period [2].
270
80. The average assimilation delay, the period of time it takes for a new employee
to become fully productive, is 80 days [2].
81. As schedule pressure increases, quality assurance activities (especially walkthroughs
and inspections) are often relaxed or suspended altogether [2].
82.
In the absence of schedule pressure, a full-time employee allocates, on average,
60% of his working hours to the project (the rest is slack time: reading mail,
personal activities, non-project related company business, etc.) [2].
83. Under schedule pressure, people tend to increase their percentage of working
hours spent on the project by as much as 100%, due to spending less time on
off-project activities, such as personal business and non-project communication,
and/or working overtime [2].
84. The three “resource-type” variables that have the greatest impact on
programmer productivity are the availability of programming tools, the
availability of programming practices, and programmer experience [2].
85.
The two “task-type” variables that have the greatest impact on programmer
productivity are the programming language and the quality of external
documentation [2].
86. The average full-time employee misses 13 – 15 days of work per year (not
counting vacation time).
Reasons are broken down in Table A.1.
Qualquer dúvida ou negociação, mande mensagem e conversaremos.
Basicamente o usuário é o dono de uma empresa e ele irá lidar com o desenvolvimento de um software.
O usuário deverá configurar os processos que irão ser feitos durante a construção do produto final (por exemplo: o modelo em cascata onde tem-se 1-Levantamento de requisitos, 2-Projeto, 3- Implementação, 4-Validação, 5- entrega) e definir qual é a dificuldade de cada tarefa dessa.
Após isso ele irá configurar seus funcionários, que serão os roles: desenvolvedor, analista, designer, etc. Todos os roles existentes na engenharia de software.
Ele irá dizer a habilidade desses funcionários em cada uma das tarefas que ele criou previamente. Por exemplo: um densevolvedor é muito bom em Desenvolvimento, mas ruim em Levantamento de requisitos.
Algumas regrinhas deverão ser seguidas durante o jogo, uma parte delas não se aplica pois talvez não haja como implementar, mas a grande maioria é possível. Vou coloca-las abaixo:
1. If you don’t do a system architectural design with well-defined interfaces,
integration will be a big mess [134].
2. Design before coding [134].
3. If a project is late and you add more people, the project will be even later [22].
4. Team members that are new to a project are less productive (1/3 to 2/3 less)
than the adequately trained people [18].
5. The average newly hired employee is about half as productive as an experienced
employee [2].
6. Two factors that affect productivity are work force experience level and level of
project familiarity due to learning-curve effects [2].
7. Developers’ productivity varies greatly depending on their individual skills
(experience concerning a development activity, knowledge of the tools,
methods, and notations used, etc.) [18, 26, 121].
8. Using better and fewer people is more productive than using more less qualified
people [18].
9. The greater the number of developers working on a task simultaneously, the
faster that task is finished, but more overall effort is required due to the growing
need for communication among developers. Thus, the productivity of the
individual developer decreases [22].
10.
The earlier problems are discovered, the less the overall cost will be [47].
262
11. The error detection effectiveness of reviews depends greatly on the
qualifications and preparations of the reviewers and the completeness and
correctness of the documents used as a reference [145].
12. Reviews of non-technical documents (e.g., Requirements specification, user
manual) are more effective if the customer is involved [111].
13. Develop tests before doing the coding [10].
14. Extreme time pressure leads to decreased productivity [47].
15.
Extreme time pressure leads to a faster rate at which errors are made, which
leads to a further delay in the completion date [91].
16. Error correction is most efficiently done by the document’s author(s) [47].
17. The more errors a document from a previous phase contains, the more errors
will be passed on to the next document [47].
18.
Always test everything [134].
19. Talk to users, not to customers to verify the prototype [134].
20. Inspection is the most cost-effective measure of finding problems in
software [134].
21.
Software inspections find a high percentage of errors early in the development
life cycle [141].
22. The use of inspections can lead to defect prevention, because developers get
early feedback with respect to the types of mistakes they are making [141].
23. Every group has one programmer that is 10 times more productive than
everyone else [121].
24.
If you disable Internet surfing, productivity will go down [141].
263
25. The structure of the software reflects the structure of the organization that
developed it [37].
26. Changing requirements are inevitable. Anticipating change with open
architectures, adaptable designs, and flexible planning can help to mediate some
of the ill effects of these changes [45].
27. Design for change/variability [45].
28.
Use defensive programming [31].
29. Configuration management is good [134].
30. Successful software is designed by people who understand the application of the
software (e.g., A well-designed missile control program was designed by
someone who understood missiles) [72].
31. Software development requires a substantial time commitment to learning the
application domain [42].
32. Broad application knowledge is acquired more through relevant experience than
through training [42].
33.
The more bugs you find, the more buggy the rest of your program will likely
be [95].
34. Tests reveal errors in the code.
The better a test is prepared for, the higher
amount of detected errors [134].
35. Sticking with a too-tight schedule increases cost due to a large work force [2].
36. Motivation is increased through monetary incentives (profit sharing, pay for
performance, merit pay, work measurement with incentives, and morale
measurement), creating a positive frame of mind at work (employee
264
involvement in wellness programs and creating fun at work), encouraging a
feeling of commitment and responsibility (worker participation in decisionmaking,
getting employees to think like owners, self-managing work teams,
commitment to productivity breakthroughs, and providing an environment with
more freedom and less restrictions), and increasing schedule pressure (using
visible milestones and setting individual goals.) Increased motivation leads to
increased productivity which reduces cycle time [141].
37. Improving the work environment is done by making ergonomic considerations,
giving employees enclosed offices to reduce background noise and
interruptions, and giving employees access to required resources, such as
computers, software tools, support staff, and information.
Improving the work
environment leads to increased productivity, which reduces cycle time [141].
38. Getting the most out of employees can be done by utilizing experts, employee
training, skills assessment and job matching, and reducing turnover.
Getting the
most out of employees leads to increased productivity, which leads to decreased
cycle time [141].
39. Improving the software development process can be done by formalizing the
process, controlling quality, and taking advantage of tools.
Improving the
software process increases employees’ motivation, which also increases their
productivity [141].
40. Rework is usually due to customer requirements, product flaws, and
communication breakdown between project members.
Improving the process to
reduce rework can be done by using prototyping and evolutionary development
265
and by using formal specification methods, modern programming practices, and
inspections. Reducing rework increases productivity [141].
41.
Design complexity can be reduced by using object-oriented design techniques.
Reducing design complexity reduces product complexity, which increases
productivity [141].
42.
Code complexity can be reduced by using modularization and object-oriented
programming techniques. Reducing code complexity reduces product
complexity, which increases productivity [141].
43.
Cognitive complexity can be reduced by modularization, multiple levels of
abstraction, simulation, and prototyping. Reducing cognitive complexity
reduces product complexity, which increases productivity [141].
44.
Test complexity can be reduced by using testing tools, building the product with
testing in mind, and testing for the type of environment a product will be used
in. Reducing test complexity reduces product complexity, which increases
productivity [141].
45.
Management complexity can be reduced by using project management planning
tools and methods. Reducing management complexity reduces product
complexity, which increases productivity [141].
46.
Tasks can be eliminated or simplified by using automation of tasks (e.g., Code
generators, automated testing) and eliminating non-value added activities and
low-priority tasks. This leads to increased productivity [141].
47.
Nine ways to reduce cycle time are: increase productivity, reduce rework,
maximize software reuse, reduce product complexity, eliminate or simplify
266
tasks, maximize task concurrency, reduce undiscovered work, reduce risk, and
use process models aimed at cycle time reduction [141].
48. Productivity is increased by increasing motivation, improving the work
environment, getting the best people for the job, improving the process, and
maximizing reuse [141].
49. Product complexity can be reduced by reducing code complexity, design
complexity, cognitive complexity, test complexity, and management
complexity [141].
50.
Decisions made in the upstream portion of the software development process
(requirements and design) impact productivity, quality, and costs throughout the
life cycle more than the other portions [42].
51. The thin spread of application domain knowledge is a major phenomenon that
greatly reduces software productivity and quality [42].
52. Specification mistakes often occur when designers do not have sufficient
application knowledge to interpret the customer’s intentions from the
requirements document [42].
53.
Requirements will appear to fluctuate when the development team lacks
application knowledge and performs an incomplete analysis of the
requirements [42].
54. Coordinating understanding of an application and its environment requires
constant communication between customers and developers [42].
55. Specifications are almost always incomplete and fraught with ambiguities.
Constant contact with the customer is required to obtain the correct
267
requirements.
Without this communication, the developers tend to make
incorrect assumptions about what the customer wants [45].
56. Fluctuating and conflicting requirements is a major phenomenon that greatly
reduces software productivity and quality [42].
57. Communication and coordination breakdown is a major phenomenon that
greatly reduces software productivity and quality [42].
58.
Truly exceptional designers that are extremely familiar with the application
domain, skilled at communicating their technical vision to other project
members, possess an exceptional ability to map between the behavior required
of the application system and the computational structures that implement the
behavior, and are recognized as the “intellectual core” of the project are a scarce
resource [42].
59. New requirements frequently emerge during development since they could not
be identified until portions of the system had been designed or
implemented [42].
60. Besides a developer’s ability to design and implement programs, his skills in
resolving conflicting requirements, negotiating with the customer, ensuring that
the development staff shares a consistent understanding of the design, and
providing communications between two contending groups are crucial to project
performance [42].
61.
Undiscovered work (work that was not considered in initial planning estimates)
can be reduced by using formal methods, analysis of PERT sizing metrics, the
268
Spiral life cycle model, and prototyping. Reducing undiscovered work leads to
increased productivity [141].
62.
Risk can be reduced by using risk management techniques. Reducing risk leads
to increased productivity [141].
63.
Inspections should be thought of as part of the development process, and time
must be set aside accordingly. Once this is done, inspections can have a
significant improvement in the development organization’s ability to meet
internal schedules [141].
64.
Proper use of inspections can even shorten life cycle [141].
65. Participants in the inspection team get a high degree of product knowledge,
which leads to higher productivity [141].
66. Slower programmers show a great deal of improvement when using
inspections [141].
67.
A new project assignee does not become productive until six months to a year
into the project [42].
68. Collaborators use hand gestures to uniquely communicate significant
information [139].
69. Employers often limit the number of hours employees can work, resulting in
further pressure to finish a project as quickly as possible [45].
70.
The customer often changes deadlines to be earlier than originally agreed-upon,
requiring negotiation with the customer for either allowing some deliverables to
be delivered at the earlier date, with the rest being delivered later, or dropping
some deliverables or requirements altogether [45].
269
71. Code comments and documentation are often produced at the end of a project,
creating major problems when a team member is lost at short notice, leaving
others to continue their work.
This can be alleviated by having quality auditors
require inspections at very short notice [45].
72. Teams often change during projects (members are added and/or removed.)
[45].
73. Sometimes the software used for development is upgraded to a new version
during development, and despite claims that it is fully backward-compatible and
won’t affect their work, it usually introduces new problems [45].
74. Hardware crashes, and customers are often unsympathetic to this kind of
delay [45].
75.
When a project is in its later stages of development, the development hardware
and software tend to be under the greatest demand, and performance starts to
suffer with lengthy compilations, builds, and test runs [45].
76. Matching the tasks to the skills and motivation of the people available increases
productivity [18].
77. Employee motivation is the strongest influence of productivity [18].
78.
Above a certain threshold, work conditions are not a powerful motivator, but
below that threshold, they are a powerful de-motivator [18].
79. The training of new employees is usually done by the “old-timers,” which
results in a reduced level of productivity on the “old-timer’s” part.
Specifically,
on the average, each new employee consumes in training overhead 20% of an
experienced employee’s time for the duration of the training or assimilation
period [2].
270
80. The average assimilation delay, the period of time it takes for a new employee
to become fully productive, is 80 days [2].
81. As schedule pressure increases, quality assurance activities (especially walkthroughs
and inspections) are often relaxed or suspended altogether [2].
82.
In the absence of schedule pressure, a full-time employee allocates, on average,
60% of his working hours to the project (the rest is slack time: reading mail,
personal activities, non-project related company business, etc.) [2].
83. Under schedule pressure, people tend to increase their percentage of working
hours spent on the project by as much as 100%, due to spending less time on
off-project activities, such as personal business and non-project communication,
and/or working overtime [2].
84. The three “resource-type” variables that have the greatest impact on
programmer productivity are the availability of programming tools, the
availability of programming practices, and programmer experience [2].
85.
The two “task-type” variables that have the greatest impact on programmer
productivity are the programming language and the quality of external
documentation [2].
86. The average full-time employee misses 13 – 15 days of work per year (not
counting vacation time).
Reasons are broken down in Table A.1.
Qualquer dúvida ou negociação, mande mensagem e conversaremos.
Categoria TI e Programação
Subcategoria Programação
Qual é o alcance do projeto? Alteração média
Isso é um projeto ou uma posição de trabalho? Um projeto
Tenho, atualmente Eu tenho especificações
Disponibilidade requerida Conforme necessário
Funções necessárias Desenvolvedor, Designer
Prazo de Entrega: 27 de Julho de 2019
Habilidades necessárias