[continued from previous message]
that are Normal distribution and inverse normal distribution functions,
please look at my demo inside my zip file to understand better how i am
doing it:
You can download and read about my PERT++ from my website here:
https://sites.google.com/site/scalable68/pert-an-enhanced-edition-of-the-program-or-project-evaluation-and-review-technique-that-includes-statistical-pert-in-delphi-and-freepascal
More of my philosophy about Cleanroom and about Evolutionary Design
methodology and more..
I am a white arab from Morocco, and i think i am smart since i have also invented many scalable algorithms and algorithms..
I think i am smart, and as you have just noticed i have just said that
"trust" is about "reliability", and i also think that Cleanroom(Read
about it here:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124.9525&rep=rep1&type=pdf)
is a developer practice involving comprehensive documentation, careful
flow analysis, and extensive code review. No proofs, no formal
verification, not even any unit testing. But i think that done properly, Cleanroom reduces the defect density to less than 1 bug/kLoC in
production. And Cleanroom itself is just one of many high-assurance
techniques that sit between mainstream software practices and code verification. But i have also just talked about Evolutionary Design
methodology such as agile, and read my following thoughts about it:
More of my philosophy about trust and about evolutionary algorithms and
more..
I think i am smart and i say that even Evolutionary Design methodology
or evolutionary algorithms have to be based on "trust", it is like i am
talking below about the straight man, i mean that look at how we have to
ensure the global convergence of the evolutionary algorithm, so this
kind of trust is like scientific, and notice that we are using in
Evolutionary Design methodology the Unit Testing, Test Driven
Development, Design Patterns, Continuous Integration, Domain Driven
Design, and we have to grow "nicely" and "balanced" the complex software projects by using standards, and we have to optimize growth of the
complex software projects by balancing between the criteria of the easy
to change the complex software projects and the performance of the
complex software projects, and we have to maximize the growth of the
complex software projects by making the most out of each optimization,
so as you notice that even Evolutionary Design methodology is based on
trust and it is like scientific since read my following proverb about
trust so that you notice:
"There is an important difference between the appearance of a reality
and the truth of a reality, this is why in science you have not to be
confident with the appearances, since in science you have to understand
the truth, so, to be able to understand the truth you have to know how
to be patience before understanding the truth and not to rush in like a
fool by lack of wisdom "
And i invite you to read my following thoughts about evolutionary
algorithms and artificial intelligence so that to understand more:
https://groups.google.com/g/alt.culture.morocco/c/P9OTDTiCZ44
And read my following thoughts about Evolutionary Design methodology
that is also based on "trust" and that is so important so that to
understand:
And I invite you to look at step 4 of my below thoughts of software Evolutionary Design methodology with agile, here it is:
4- When in agile a team breaks a project into phases, it’s called
incremental development. An incremental process is one in which
software is built and delivered in pieces. Each piece, or increment,
represents a complete subset of functionality. The increment may be
either small or large, perhaps ranging from just a system’s login
screen on the small end to a highly flexible set of data management
screens. Each increment is fully coded Sprints, Planning, and
Retrospectives.
And you will notice that it has to be done by "prioritizing" the pieces
of the software to be delivered to the customers, and here again in
agile you are noticing that we are also delivering prototypes of the
software, since we often associate prototypes with nearly completed or just-before launch versions of products. However, designers create
prototypes at all phases of the design process at various resolutions.
In engineering, students are taught to and practitioners think deeply
before setting out to build. However, as the product or system becomes increasingly complex, it becomes increasingly difficult to consider all
factors while designing. Facing this reality, designers are no longer
just "thinking to build" but also "building to think." By getting hands
on and trying to create prototypes, unforeseen issues are highlighted
early, saving costs related with late stage design changes. This rapid iterative cycle of thinking and building is what allows designers to
learn rapidly from doing. Creating interfaces often benefit from the
"build to think" approach. For example, in trying to layout the
automotive cockpit, one can simply list all the features, buttons, and
knobs that must be incorporated. However, by prototyping the cabin does
one really start to think about how the layout should be to the driver
in order to avoid confusion while maximizing comfort. This then allows
the designer iterate on their initial concept to develop something that
is more intuitive and refined. Also prototypes and there demonstrations
are designed to get potential customers interested and excited.
More of my philosophy about the Evolutionary Design methodology and more..
Here are some important steps of software Evolutionary Design methodology:
1- Taking a little extra time during the project to write solid code and
fix problems today, they create a codebase that’s easy to maintain
tomorrow.
2- And the most destructive thing you can do to your project is to build
new code, and then build more code that depends on it, and then still
more code that depends on that, leading to that painfully familiar
domino effect of cascading changes...and eventually leaving you with
an unmaintainable mess of spaghetti code. So when teams write code,
they can keep their software designs simple by creating software
designs based on small, self-contained units (like classes, modules,
services, etc.) that do only one thing; this helps avoid the domino
effect.
3- Instead of creating one big design at the beginning of the project
that covers all of the requirements, agile architects use incremental
design, which involves techniques that allow them to design a system
that is not just complete, but also easy for the team to modify as
the project changes.
4- When in agile a team breaks a project into phases, it’s called
incremental development. An incremental process is one in which
software is built and delivered in pieces. Each piece, or increment,
represents a complete subset of functionality. The increment may be
either small or large, perhaps ranging from just a system’s login
screen on the small end to a highly flexible set of data management
screens. Each increment is fully coded Sprints, Planning, and
Retrospectives.
5- And an iterative process in agile is one that makes progress through
successive refinement. A development team takes a first cut
at a system, knowing it is incomplete or weak in some (perhaps many)
areas. They then iteratively refine those areas until the product is
satisfactory. With each iteration the software is improved through
the addition of greater detail.
More of philosophy about Democracy and the Evolutionary Design methodology..
I will make a logical analogy between software projects and Democracy,
first i will say that because of the today big complexity of software
projects, so the "requirements" of those complex software projects are
not clear and a lot could change in them, so this is
why we are using an Evolutionary Design methodology with different tools
such as Unit Testing, Test Driven Development, Design Patterns,
Continuous Integration, Domain Driven Design, but we have to notice
carefully that an important thing in Evolutionary Design methodology is
that when those complex software projects grow, we have first to
normalize there growth by ensuring that the complex software projects
grow "nicely" and "balanced" by using standards, and second we have to
optimize growth of the complex software projects by balancing between
the criteria of the easy to change the complex software projects and the performance of the complex software projects, and third you have to
maximize the growth of the complex software projects by making the most
out of each optimization, and i think that by logical analogy we can
notice that in Democracy we have also to normalize the growth by not
allowing "extremism" or extremist ideologies that hurt Democracy, and we
have also to optimize Democracy by for example well balancing between "performance" of the society and in the Democracy and the "reliability"
of helping others like the weakest members of the society among the
people that of course respect the laws, and so that to understand more
my thoughts of my philosophy about Democracy, i invite you to read them
here:
https://groups.google.com/g/alt.culture.morocco/c/vlDWhmf-MIM
Thank you,
Amine Moulay Ramdane.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)