On Mon, 2003-08-18 at 17:00, Finkbine, Ronald B. wrote: I am sorry if this seems like a flame but emails such as this set me off.
<flame> > First, languages can be complex but programs should be simplified > according to the Chomsky hierarchy of languages. The systems analyst > (SA) should deconstruct programs that are of DFA (or FSM) complexity. > DO NOT assign programs to programmers that are complex, you are just > asking for trouble. You need to have programs that are provable or > near-provable. A DFA can arguably be accepted as a proof depending > upon results from continuing research in the field of diagrammatics > (pictures accepted as proofs). It is almost certainly the case that there are software developments that use 1960s views of development organizations but is there really any need to further enshrine such outdated views of development by researching such systems. System development organization theory has gone beyond the systems analyst / programmer combative dichotomy implied by your comments. Whilst provably correct programs are a bonus the constructivist view of formal development has yet to show that it is workable in real development environments. Systems such as B are showing a new resurgence of specification driven development but test-driven development is still the primary development paradigm of quality. > Second, a SA should have automated control over a programmer. There > should be a test-case-control-system (TCCA) that the SA will input the > test suite (set of test cases). The programmer will write a program > and execute the test suite (each case as appropriate for continued > development). The SA would only get notified when the program passes > ALL test cases. I really do not believe your traditional hierarchy management model of systems development is either workable or worthy of research. Systems analyst as intelligent controlling boss, programmers as workers who are controlled animals incapable of being allowed flexibility is not a good start point for a sensible view of development. Models such as self-directing teams lead to far greater productivity as well as job satisfaction. Roles are needed certainly but equality, mutual respect and leadership works far better than stratification, hierarchy and dictatorship. Success in a project is more easily obtained when everyone takes ownership of the problem directly. Test-driven development is about programmers using tests as the driver for development. An external team then provide a second level of testing and as bugs are found filter the tests into the development team to add to the regression test suite. Any stratified, "I write the test you work to" philosphy leads to confrontation not cooperation. Cooperation leads to success, confrontation leads to anger, anger leads to hate, hate leads to suffering and suffering leads to red and black faced beings getting killed in star wars films :-) > Third, normally there is a data dictionary (DD) in a large program, the > set of variables/data structures that are of major importance to the > program. Not locals, loop indices, temps, or little ones, but useful > variables with some form of global scope in the program/system. This > DD should be of prime interest to the SA and changes to the DD (i.e. > usually done in one program) should be done in DFA-level programs > interacting with a database to preserve the DD. This would allow the > SA to have a history of the DD (because of the database) and each > program that changes the database would be provable (near-provable). > If there are parts of the program that are CFL or CSL (more complex > than DFA), they must be small and hence provable by some form of > cleanroom engineering (book by Stavely). Forgive me but this is a very 1970s view of database-centered application development and therefore not a good start point since the world has moved on. To progress this you really need to explain why global data at the program is important to the extent implied by your comment. These days, with the hegemony of SQL and/or object-oriented approaches people have control. Moreover data dictionaries per se are replaced by manual documentation generation from source code, cf. JavaDoc, Doxygen, etc. I am not sure "Cleanroom" approaches can work in these days of SQL, C++, Java, etc. since there is no sensible mathematics to describe exactly the semantics for the size of program most systems are these days. By the time the analysis is complete the opposition have taken a monopoly in the market. > The idea is to extend what is the correct/provable output of one person > for one day. If the SA can assign and get back only programs that are > proven, and the SA has more that one programmer working for them, then > the correct/provable output of one SA would be greater than the output > of the programmer. This smacks of Tayloristic management philosophies which, at least in software development, if not in Ford production lines, leads to sabotage. Software development is a human inspirational activity not a mechanistic physical activity. Anyone studying software development must, must, must lose the connection between software development and production engineering. For too long people have tried to use techniques associated with production engineering for software development. It does not work. Think Skunkworks. Think flexibility. Think trust. Think cooperation. Formal methods have a role as support for the programmer and the systems analyst not as a management tool but as a thinking support / reasoning tool. The use of specification as analysis tool to tell programmers what they have to do has long failed to get anywhere. The use of specification tools as programming tools is beginning to see some proper use not to mention serious benefits. At the end of the day, systems will be developed by programmers. Programmers will program. Big systems will need analysis before design -- to some extent. Iteration is good, cooperation leads to success. Waterfall and Taylorism is past, the 1970s were 30 years ago. Research looks to the future. </flame> -- Russel. ==================================================================== Dr Russel Winder, Chief Technology Officer Tel: +44 20 8680 8712 OneEighty Software Ltd Fax: +44 20 8680 8453 Cygnet House, 12-14 Sydenham Road [EMAIL PROTECTED] Croydon, Surrey CR9 2ET, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act
signature.asc
Description: This is a digitally signed message part
