2023-08-10
# Product Development Cycle
#
# This is an adjusted example with ABCDE process
# applied with Abc on quite a few products.
# ( And it works as intended from years. )
#
# It may be useful to preview the capabilities of Abc:
# * How much Time is saved.
# * How much the Quality increases over time.
# * What can be controlled and automatized.
# * It allows the humans to focus on product development,
# because the used tools (and how are used) are unforgiving like a compiler,
# and this alone shrinks the daily/weekly to-consider list.
# * Because of the same tools and notifications from them,
# the learning curve for beginners is smaller.
# Learn as you go.
# Now, to feel the real benefits - one have to try.
# ----------
# The development cycle with Abc briefly looks like this (for a developer):
abc # once
# do
# # Edit, make changes in sub-projects ... fix errors ...
make
# Note: the build system uses parallel jobs that are updated when necessary.
# while (not-done)
# ----------
# The development cycle with Abc might look broadly like this:
abc # once
# do
# # Edit, make changes in sub-projects ... fix errors ...
# # * edit source files
# # * edit UIT in-place test code
# # * fix errors/warnings from tools and tests introduced in defined steps
# # * add a new executable-project
# # * add a new library-project & reference it
# # * move a project
# # * rename a project & rename the library reference as usual
# # * intentionally the library reference is not updated automatically
# # to keep the projects under control
make
# Note: the build system uses parallel jobs that are updated when necessary.
# # ( when Abc Main Config and bin-hooks are already properly prepared )
# # * check code conventions
# # * prettify code
# # * run UIT tests
# # * run coverage tests
# # * build documentation
# # * check documentation
# # * postponed checks, time consuming but still important
# # * send events to other test-machines to flash hardware & launch tests
# # * check code & interdependencies across projects
# # * run suite integration tests
# # * run suite verification tests
# # * run performance tests
# # * check requirements coverage
# # * collect results
# # * make reports
# # * publish the reports at the chosen location
# # * last chance to advance to Deploy and/or Export steps
# # * start Deploy-phase
# # * collect results from the other machines
# # * make reports for management
# # * publish the reports at the chosen location
# # * send events when the whole project group is marked ready
# # * send emails
# # * start Export-phase
# while (not-done)
# Note that if a step fails for a project:
# * next steps are not done
# * projects that depend on this project will not be made
# * cannot advance to Deploy/Export phases
# Note that steps can be customized on/off per machine role.
# * on developer's computer:
# * some steps can be skipped to allow for a fast development cycle
# * some steps are mandatory, to enforce quality early
# * requirement coverage can be switched on/off
# * reports can be switched on/off
# * on product-control machines:
# * build is not desired, to keep the user test environment clean
# * automated hardware tests are active
# * on overall-product machines:
# * requirement coverage is always on
# * reports are always on
# Human reviews are an important part of the development process.
# These are inserted at the right points.
# e.g.
# * Developers can still make reviews on branches.
# When review passes, a switch can mark the new changes ready for the product.
# * Deployment-phase can send an event for review.
# When review passes, a switch will allow to continue.
--