update devspec.en_US/1.0.general.md.

[devspec.git] / devspec.en_US / 2.2.develop-step-diagrams.md

\r
\r
# dev-work-flow-diagram\r
=======================\r
\r
    the colored object in 'top usecase diagram' is the entrance launched by an \r
actor in developing. others show the steps in developing. and they are \r
described in other diagrams in detail. view the diagram of *-procedure.\r
    all those develop steps is described in section of 'develop step'.\r
\r
\r
\r
# compact design\r
=================\r
\r
  it brings design conception and work into a src-pkg, although it's simple,\r
easy and weakness, it helps developer to follow the regular procedure.\r
  the meaning of the design work is for auto-sync between design and src-code,\r
by the same processing method.\r
\r
SA(structured analysis)\r
@ list program or device operator and IO object in ExternalList.txt.\r
@ writing function feature list in TODO.\r
@ list the data processing procedure in program in file of DataProcessing.txt.\r
@ writing the function feature module invoking sequence in file \r
  ModuleInvoking.txt\r
\r
SD(structured design)\r
@ writing program module list in xxx.catalog accroding to file of 'TODO'.\r
@ writing module variable and function list in xxx.catalog, accroding to the \r
  file of 'DataProcessing.txt' and 'ModuleInvoking.txt'.\r
@ generate or sync xxx.catalog design file to dir of 'src'.\r
\r
    the rest thing is like normal, coding and testing until done.\r
\r
\r
\r
## develop step\r
==============\r
\r
\r
\r
## design files\r
==============\r
\r
\r
\r
# SE design\r
============\r
\r
  the meaning of this design work is providing a method how to generate design\r
files for code generation.\r
  SE, software engineering design, is similar with compact design. actually,\r
the procedure of compact design is referenced from this. but SE design use \r
graphical utilities for design, the content can be descripted in detail and \r
more humen readable.\r
\r
\r
\r
## develop step\r
==============\r
\r
\r
\r
analysis-procedure:\r
dev-initial-procedure:\r
design-procedure:\r
code-branch:\r
code-merge:\r
develop-procedure:\r
testing-procedure:\r
bug-report-task:\r
document-procedure:\r
publish-procedure:\r
\r
\r
@ new-idea-action: \r
@ new-demond-action: \r
@ analysis-action: \r
@ initial-dev-launch: \r
@ new-feature-dev-launch: \r
@ complete-estimate: \r
@ publish-estimate: \r
@ testing-estimate: \r
@ bugfix-estimate: \r
@ publish-launch: \r
@ usr-bug-report-action: \r
@ using-action: \r
@ works of bugfix, testing, document, translation: \r
@ tasks of analysis, design, coding, testing, document, translation: \r
\r
\r
\r
## design files\r
==============\r
\r
\r
\r
# develop step\r
==============\r
\r
    it's sourced from the behaviour-action list, then translated to the work \r
tasks.\r
    some of the work task can be combined in a procedure, it can be mentioned\r
repeatly in other place.\r
\r
actor ==> behaviour action ==> procedure ==> work task ==> dev-step\r
\r
        all the work translated to dev-step, any actor followed with the step,\r
src-pkg will be developed.\r
    those develop procedure below are used in developing under devspec, and it \r
is a note for usecase diagrams.\r
\r
@ new src-pkg creating\r
# download and install pkg-builder, \r
# check the develop environment works well.\r
# create a soft-pkg by templete.\r
# create web home pages by program or guide documents.\r
# first-version-dev-env-chk: create the start version of the soft-pkg, compile, \r
  and comit to code repo, and publist the initial blank version of soft pkg for\r
  testing.\r
\r
@ initial-dev-launch(for new project develop)\r
# tag-doc. record the function feature or idea for a soft-pkg.\r
# trimp the tag-doc, and output a feature list to be developed.\r
# catalog. writing function module for soft-pkg by using .catalog file.\r
# generate code framwork automatically by using codegen. compile and fix \r
  compile bug, output an executables.\r
# modulized design:\r
+ write unit test code, and coding for single function module, \r
+ unit test by using cunit or scripttest.\r
+ coding ... until the code of function module is tested ok.\r
# integrate testing by scripttest.\r
# performence testing accroding to the demand of design. memory leakage, code \r
  coverage, and code optimization.\r
# multi-lang support accroding to the demand of design.\r
# first version testing, and bug-report, bug-fix, re-testing.\r
# document: manual-helper-doc, dev-api-doc, tutorial/animation, example, and so\r
  on.\r
# publish for src-pkg, binary install pkg, relative resource file pkg, web \r
  pages, documents, by using utility programs in devutils.\r
\r
@ new-feature-dev-launch(part of code develop)\r
# get the develop task from task list, and clear what to be developed.\r
# create unit test code, coding for task.\r
# unit test, and fix-bug, re-test.\r
# inegerate test, or function feature loop-back test.\r
\r
@ new features\r
# send issue by email to the maintainer, maybe with the patch code. or ideas\r
  from the author of soft-pkg.\r
# view the issue by maintainer, append a feature in tag-doc if it is needed for\r
  soft-pkg.\r
\r
@ new feature branch marge\r
# fork a new branch from main version, modify code on it until it is done.\r
# check if the code of main version \r
# get the corresponding version of code forked from mainline. get the current\r
  newest version of code, and compare them.\r
# combine the compared modification code into new branch.\r
# loop-back testing\r
# commit if the ocde of main version is not updated since it is used for \r
  comparing. if new modification commited, compare and combine again.\r
\r
@ bug-report\r
# send mail to the maintainer. it's better to bring test environment \r
  description, even if the patch code.\r
# record the bug-report info, and append the bug re-testing task.\r
# tester or some one get the task of bug re-testing in current version, and \r
  test in various long time support version. \r
# record the bug-report and bug-testing info, append a bug-fix task, and \r
  specify the version code to be fixed, and record patch version publish \r
  demaond if the fixed-bug is need to be publish as a patch version.\r
\r
@ new feature develop\r
# get a intreast task from feature list by developer, or assign task to a \r
  developer by the maintainer.\r
# developer get the task, and the relative documents. do develop works \r
  accroding 'part of code develop'.\r
# check if all features developed in new version feature list, and publish \r
  soft-pkg if done.\r
\r
@ bug-fix\r
# create a task for bug-fixing.\r
# developer get the task, and the relative description text. do develop works \r
  accroding 'part of code develop'.\r
# fix and test in other versions listed in task.\r
# publish patch version if needed.\r
\r
@ publish\r
# check feature list that has been developed, check bug list that has been\r
  fixed.\r
# build soft-pkg, generate documents.\r
# function feature loop-back testing, documents checking, fix-bug if needed.\r
# output changelog and news automatically by tag-doc. delete task record and \r
  bug record that has been done. trimp documents in tag-doc.\r
# upload src-pkg and bin-pkg, update web pages by utility programs in devutils.\r
  view the web pages, and test downloading, build and running loop-back test.\r
\r
    the develop of soft-pkg is driven by task and develop step. the maintainer\r
put developer on a task, or a developer is intreasting in some feature, or \r
willing to fix some bug. it push the step for soft-pkg developing.\r
\r
    here impmort a conception of 'procedure'. it's the step serial for works\r
in developing.\r
\r
\r
\r
# design files\r
==============\r
\r
@ dev-design\r
# use-relationship\r
+ topÓÃÀýͼ£º°üº¬user¡¢softwareÖ®¼ä¹ØÁªµÄ´óÌå¿òͼ¡£²àÖØÓÚÓû§behaviour£¬¼°¶ÔÓ¦\r
  µÄ¹¦ÄÜÄ£¿é¡£¶ÔÓÚÒ»¸öÃüÁîÐгÌÐò£¬Í¨³£ÊÇÃüÁîÐвÎÊý¼°¶ÔÓ¦µÄ¹¦ÄÜ¡£ÔÚÓÃÀýͼÖаüº¬pkgÐÅÏ¢£¬²»ÁíÍâ»æÖÆpkgͼ¡£\r
+ pkgÓÃÀýͼ£º°üº¬Ò»¸öpkg»òһЩ¹¦ÄÜÏà½üµÄpkgµÄuserºÍoperationÖ®¼äµÄ¹Øϵͼ¡£Èç¹û\r
  ³ÌÐò½Ï¸´ÔÓ£¬°üº¬¶à¸ösub-pkg£¬»ò°üº¬¶à¸öexe³ÌÐòʱ£¬¶Ôpkg»òexeµÄÓÃÀýÃèÊö¡£\r
\r
# analysis\r
+ £¡¹¦Äܵ÷Óùý³Ìͼ(function-invoking-procedure-diagram)¡£\r
    ´ÓÍⲿÊäÈëµ½¹¦ÄÜ´¦ÀíµÄÔËÐйý³Ìͼ¡£ÓëÊý¾ÝÁ÷ͼÏà¶ÔÓ¦µÄ¹¦ÄÜÔËÐйý³Ìͼ¡£ÀýÈç´Ó\r
  Óû§ÊäÈëÃüÁîÐеÄij¸ö²ÎÊýµ½¹¦ÄÜʵÏֵŦÄÜÄ£¿éµ÷Óá£Ò»¸ö¹¦ÄÜÄ£¿é¿ÉÒÔÊÇÒ»¸ö\r
  module£¬Ò²¿ÉÒÔÊǺ¯Êý¡£\r
+ ¹¦ÄÜÌØÐÔÁбíÎļþ(function-feature-list-file)\r
    ÓÃÓÚ¹¦ÄÜÌØÐÔÐèÇóµÄtracer¡£Í¬Ê±ÓÃÓÚÊä³öTODOÎļþ¡£TODOÎļþµÄ¹¦ÄÜʵÏÖºó£¬ÓÃÓÚ\r
  changelogºÍnewsÎļþµÄÊä³ö¡£\r
    ¶Ô¹¦ÄÜÐèÇó»ò¹¦ÄÜÌØÐÔµÄÃèÊö¡£¸ù¾ÝuserµÄ²Ù×÷£¬ÒÔ¼°¹¦ÄÜÄ£¿éµ÷Óùý³Ì£¬Êä³ö¹¦ÄÜ\r
  ÌØÐÔÁбíÎļþ£¬ÓÃÓڼǼ¹¦ÄÜÐèÇ󡣸ù¾Ý¡®¹¦Äܵ÷Óùý³Ìͼ¡¯ÖÐʹÓõŦÄÜÄ£¿é£¬ÂÞÁÐÒ»\r
  ¸ötable½á¹¹µÄÁбíÎļþ¡£²¢¸ù¾Ý¹¦ÄÜÄ£¿éÖ®¼äµÄ¹ØÁª¹Øϵ£¬ÒÔĿ¼½á¹¹±íʾ¹¦ÄÜÄ£¿éÁÐ\r
  񡭜\r
+ £¡Êý¾ÝÁ÷ͼ(DFD, data-flow-diagram)¡£\r
    ¸ù¾ÝÈí¼þÓëÍⲿÎïÀíʵÌåµÄÊý¾Ý½»»¥£¬·ÖÎö¼°»æÖÆÊý¾Ý´¦Àí¹ý³Ì¡£\r
\r
    ϸ»¯¹¦ÄÜÄ£¿éÖ®¼äµÄµ÷Óùý³Ì£¬\r
\r
+ Êý¾Ý×Öµä(data-dict)¡£DFDÖÐÿ¸öÊý¾ÝÌõÄ¿µÄ¼¯ºÏ¡£ÓÃÓÚE-RͼµÄÊý¾ÝÏî¡£E-RͼÊä³öÊý¾Ý±í¼°Êý¾ÝÄÚÈݵĶ¨Òå¡£\r
+ E-Rͼ(ER-diagram)£¬ÊµÌå¶ÔÏóͼ¡£ÓÃÓÚÊä³öÊý¾Ý¿â±í½á¹¹¶¨Òå¡£\r
\r
# deployment\r
+ °üͼ/×é¼þͼ/²¿Êðͼ£¬ÓÃÓÚ±íʾ²»Í¬level¹æÄ£µÄÈí¼þÄ£¿é¡£×é¼þͼÓÃÓÚ±íʾϵͳ¼¶³ÌÐò\r
  Ì×¼þ£¬²¿ÊðͼÓÃÓÚ±íʾ²»Í¬³ÌÐòÔÚ¶à»ú»·¾³µÄ°²×°²¿Ê𡣶ÔÓÚ°üͼµÄ¹¦ÄÜ£¬ÔÚc/cppÖеÄ\r
  Èí¼þ°üÓëjÖеIJ»ÍêÈ«Ïàͬ¡£\r
+ ʵ¼ÊÔÚc/cpp¿ª·¢ÖУ¬Êä³öbuild-destÁÐ±í£¬Êä³öinstall-pkgÁÐ±í£¬Êä³ösrc-pkgÁÐ±í£¬\r
  ÕâЩÁбíÓÃÓÚ¹¦ÄÜÄ£¿éÁбíÎļþµÄtop-levelÉè¼Æ£¬src-pkgµ½exec-pkgµ½build-dest¡£\r
  һЩsrc-pkgµÄexec-pkg½Ï¶àʱ£¬»ò½«exec-pkg¶ÔÓ¦µÄsrcת»»Îªsub-src-pkg¡£\r
+ ¸ù¾ÝÕâЩÁÐ±í£¬top-levelµÄ¡®¹¦ÄÜÄ£¿éÁбíÎļþ¡¯¡£ÔÚcodegenʱ£¬Êä³ösrc-pkg£¬¼°ÆäÄ¿\r
  ¼·ÖÀ࣬ÒÔ¼°Ò»¸ösrc-pkgÖеÄinstall-pkgºÍbuild-dest¡£\r
\r
# design\r
+ top-level¹¦ÄÜÄ£¿éÁбíÎļþ\r
    ÓÃÓÚÈí¼þ´úÂ빤³Ì³õʼ»¯Ê±£¬Êä³ö²»Í¬µÄsrc-pkg¡£\r
+ ¹¦ÄÜÄ£¿éÁбíÎļþ(function-module-list-file)\r
    ¸ÃÎļþÓÃÓÚcodegenÊä³ö´úÂë¿ò¼Ü£¬ÒÔ¼°²âÊÔÓÃÀý¡£\r
    ²»Í¬ÓÚ¹¦ÄÜÌØÐÔÁбíµÄÊÇ£¬ÕâÊÇÒ»¸ö³ÌÐò´úÂëÄ£¿éµÄ»®·Ö¡£¶ø¹¦ÄÜÌØÐÔÁбíÊǶԹ¦ÄÜ\r
  ÐèÇ󣬹¦ÄÜÌØÐÔµÄÃèÊö¡£ÔÚ¡®¹¦ÄÜÌØÐÔÁбíÎļþ¡¯ÖУ¬½«Ä£¿éÃû³ÆÌí¼Óµ½¶ÔÓ¦µÄ¹¦ÄÜÌØÐÔÃèÊöÖУ¬Ê¹Á½¸öÁбíÄÚÈÝÉÏ¿Éͬ²½¼°¹ØÁª¡£\r
        ʹÓÃ.catalogÎļþ±àд£¬ÃèÊöÒ»¸öĿ¼½á¹¹µÄ¹¦ÄÜÄ£¿éÁÐ±í¡£ÔÚcpp³ÌÐòÉè¼Æʱ£¬»¹¿É\r
  ʹÓÃ.umlÀàͼ¡£¸ÃÎļþÓÃÓÚÊä³ö³ÌÐò´úÂë¿ò¼Ü¡£\r
    Èí¼þ½Ï¸´ÔÓʱ£¬°üº¬¶à¸ö¹¦ÄÜÄ£¿éÁбíÎļþ¡£\r
        topÎļþ°üº¬µÄÊÇÈí¼þdeploymentÏà¹ØµÄÉè¼ÆÐÅÏ¢¡£Ò»¸ösoftware¶ÔÓ¦Ò»¸ötopÉè¼ÆÎÄ\r
  ¼þ£¬Ò»¸ösoftwareÖаüº¬¶à¸ösrc-pkg£¬Ò»¸ösrc-pkgÖпɰüº¬¶à¸öinstall-pkg£¬Ò»¸ö\r
  install-pkgÖпɰüº¬¶à¸öbuild-dest¡£¸ù¾ÝÈí¼þµÄʵ¼ÊÇé¿ö£¬ÒÔ²»Í¬µÄ½á¹¹×éÖ¯¡£\r
    Ò»¸öbuild-dest¶ÔÓ¦×ÅÒ»¸ö¶þ½øÖƳÌÐò£¬ÒÔ¼°ÏàÓ¦µÄcatalogÎļþ¡£\r
    ÕâÀïµÄtop-catalogÎļþÔÚ³õʼ»¯Ô´Â빤³ÌÎļþʱʹÓã¬ÆäËücatalogÎļþcopyµ½¶ÔÓ¦\r
  src-pkgµÄÖС£\r
    ¸ù¾Ý¡®¹¦Äܵ÷Óùý³Ìͼ¡¯ÖеÄÄ£¿é£¬Êä³ö¹¦ÄÜÄ£¿éÁÐ±í¡£¸ù¾ÝͼÖеIJÙ×÷Á÷ºÍÊý¾ÝÁ÷£¬\r
  Êä³öÄ£¿éµÄ½Ó¿Úº¯Êý¼°²ÎÊý£¬Êä³öÄ£¿éÖ®¼äµÄ¹«ÓÃÊý¾Ý£¨Îļþ£¬db-tbl£¬global \r
  variable£©¡£ÕâЩÄÚÈÝÊä³öµ½Ò»¸öcatalogÎļþ£¬µÈͬÓÚÒ»¸ö´øĿ¼½á¹¹µÄÀàͼ¡£\r
+ ¹¦ÄÜÄ£¿é½á¹¹Í¼(function-module-struct-diagram)/¼Ü¹¹Í¼£¨architech-diagram£©\r
    ²ã´Î»¯Éè¼ÆµÄ¿òͼ¡£¸ù¾Ý¹¦Äܹý³Ìµ÷ÓÃͼºÍÊý¾ÝÁ÷ͼ¶øµÃ¡£\r
    ʹÓÃcatalogÎļþÒ²¿É±íʾ¹¦ÄÜÄ£¿éµÄ²ã´Î»¯½á¹¹¡£\r
+ Ààͼ(class-diagram)\r
    ¸ù¾Ý¹¦Äܹý³Ìµ÷ÓÃͼºÍÊý¾ÝÁ÷ͼÖеÄÄ£¿é£¬Êä³ö¹¦ÄÜÄ£¿éµÄÀàͼ¡£ÒÔ¼°Êý¾ÝºÍ¹¦Äܵ÷\r
  ÓùØϵ£¬Êä³ö±äÁ¿ºÍº¯ÊýµÄ¶¨Òå¡£cÓïÑÔ³ÌÐòÉè¼Æʱ£¬Ò²¿ÉʹÓÃcatalogÎļþ´úÌæÀàͼ¡£\r
\r
    Óë³ÌÐò¿âÖÐÒÑÓÐÈí¼þÉè¼Æ½á¹¹µÄmatching£¬ÓÃÓÚÊä³öÏàͬµÄÉè¼Æ½á¹¹µÄÉè¼Æ´úÂë¡£\r
\r
# design£¨opt£©\r
+ ³ÌÐòÃüÁîÐвÎÊýÉè¼ÆÎļþ(cmd-args-design)¡£\r
+ ³ÌÐòÔËÐвÎÊýÉè¼ÆÎļþ(running-param-design)¡£\r
+ txtÎı¾Êý¾ÝµÄ´Ê·¨/Óï·¨¸ñʽ¶¨ÒåÎļþ(.lex/.gmr)£¬ÓÃÓÚÎļþ»òͨÐÅЭÒé¸ñʽÃèÊö¡£\r
+ hex¶þ½øÖÆÊý¾ÝµÄ½á¹¹»¯¸ñʽ¶¨ÒåÎļþ¡£Ê¹ÓÃhexfmt(.type)£¬ÓÃÓÚÎļþ»òͨÐÅЭÒé¸ñʽ\r
  ÃèÊö¡£\r
+ ͨÐÅЭÒéµÄtime-sequenceͼ¡£\r
+ UIÈË»ú½»»¥½çÃæµÄÉè¼ÆÎļþ(.ui)¡£Ê¹ÓÃscript»òRAD¿ª·¢Èí¼þ½øÐнçÃæÉè¼ÆºÍÏÔʾ¡£\r
+ ÊäÈëÊä³öÐźÅ/Êý¾ÝµÄtime-sequenceͼ¡£\r
+ Óû§Êý¾ÝÊý¾ÝÎļþ¡£E-Rͼ£¬tbl½á¹¹¡£\r
\r
# implement\r
+ Èí¼þ°ü¹¤³ÌĿ¼´´½¨£¬²¢±àдGNUÈí¼þ°üÏà¹ØµÄÎļþ¡£\r
+ code-gen¸ù¾Ý.catalog»ò.umlÀàͼ´´½¨´úÂë¿ò¼Ü¡£\r
+ ¸ù¾Ý¿ª·¢Ï°¹ßºÍÐèÒª£¬Ê¹ÓÃRADÈí¼þ¿ª·¢demo¡£\r
+ ¹¦ÄÜÄ£¿éunitµÄ²âÊÔÓÃÀý¡¢±àÂë¡¢²âÊÔ¿ª·¢¡£\r
+ ¹¦ÄÜÄ£¿é¼¯³ÉµÄ±àÂë¡¢²âÊÔ¡£\r
+ Èí¼þÄڲ⡢¹«²â¡£\r
+ doc£¬tutorial£¬webdoc¡£\r
+ °æ±¾ÉèÖã¬src-pkgºÍexe-pkgµÄÖÆ×÷¡£\r
\r
# publish\r
+ pkgÔÚrepoµÄsync¡£\r
+ ÏÂÔØ£¬±àÒ룬loop-back²âÊÔ¡£\r
+ webdocµÄpublish¡£\r
\r
\r
\r
# different scale of developing\r
================================\r
\r
    most of the src-pkg is developed by one developer, and others provide\r
ideas, suggestion, bug-report, bug-fix-patch, maybe write a part of code. all actor is the same peron, the author/maintainer of the src-pkg.\r
    if the soft-pkg is complex, it need many developer work together for \r
developing. the actor fills with an actual person. all developer cooperate to\r
develop the soft-pkg.\r
    if the software is an system, such as operating system, the software is \r
consisted by various src-pkgs.\r
\r
    the example of different scale software.\r
\r
@ linux operating system. not the linux kernel, it is consisted by lots of pkgs\r
  with different function feature.\r
@ linux kernel. it's a complex software, but all it is in one src-pkg.\r
@ putty terminal program. it's an example of general application programs with\r
  GUI. it consisted by some of src-pkg.\r
@ libxml2. it's a src-pkg with lib and executables. libc is a well known lib \r
  for this type of src-pkg.\r
@ sed. it's a classic program, and only one utility program with docs.\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
## first, writing note\r
======================\r
    writing note for function feature description, for the operation user would\r
do, for anything author want to record about the src-pkg, and tag the doc with\r
a tag-name, which is used for category and index.\r
\r
\r
## second, \r
======================\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
# tasks\r
=======\r
\r
**TBD** it's the behaviour and action description of different actors. task is \r
  the work to do.\r
\r
+ maintainer, \r
 - new-idea-action, new-demand-action.\r
 - initial-dev-launch: create a src-pkg, and develop for it's first version.\r
 - analysis-action. analysis idea doc, and translate them into feature \r
   list file(todo).\r
 - new-feature-dev-launch. get the task in file of 'todo' in a version,\r
   put them into task list(todolist) of this src-pkg, and add other tasks like\r
   document writing, translation, testing, publish, and so on. 'devtask launch\r
   <task-id>' will do this work automatically with version id. the task \r
   generated in todolist can be modify manually.\r
 - complete-estimate: check if the task launched is done.\r
 - publish-launch: decide to publish one version of code.\r
 - publish-estimate: decide if the src-pkg should be published.\r
 - publish-task: loop-back testing, put src-pkg and install-pkg on web, update\r
   homepages.\r
 - but not do other the actual develop work.\r
+ tech-leader, \r
 - same as the maintainer if willing to do some of that.\r
 - design-task: do work of the design task in new feature develop procedure. \r
   writing or modifying program module list file. append module, ethod/function \r
   and variable to .catalog file, develop task dispatching, and so on. design \r
   work is the important work for developing. \r
 - bugfix-estimate. check if the bug should not be fixed juest now. by default,\r
   the bug reported will be fixed, and put bugfix info into 'todolist' from \r
   'bugs'.\r
 - testing-estimate: after testing bug-report, estimate the bugs, and decided\r
   if it will be fix or not. end task or do next task.\r
 - get task from task list (todolist), do the actual develop or other works.\r
 - same work as a normal developer.\r
+ developer, \r
  - task-work: get coding tasks in src-pkg task list(todolist). maybe it is a \r
    new feature job, or a bug-fix job.\r
  - writing unit test code, or test script for bug testing.\r
  - document and tutorial writing, especially for design document. any thing\r
    a documentor will do.\r
+ tester, \r
  - task-work: test schem write with script for tool of 'scripttest'.\r
  - white box testing.\r
  - black box testing.\r
  - bug-report-task: put bug description string into 'bugs', put bug detail \r
    info into .tagdoc file, or pkg-record file under doc/testing/<version-id>/.\r
+ user, \r
  - use-action: download, build, install, and use.\r
  - usr-bug-report-action: send bug-report by email, or on the webpages, \r
    sometimes with code patch file.\r
  - new-demand-action: \r
+ translator, \r
  - task-work: translation of documents by getting translation task in \r
    'todolist'.\r
+ documentor, \r
  - task-work: getting task from task list about document.\r
  - design document.\r
  - user manual in different file format.\r
  - man or info helper file.\r
  - generate and check webpages.\r
  - cmdline tutorial if needed.\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
# analysis and design\r
=====================\r
\r
\r
\r
## classical app feature design\r
===============================\r
\r
    it's a topic of program style in charpter of 'prog-style'.\r
        classical app design helps developer to develop programs rapidly.\r
\r