Conference heron::euro_swas_ai

             <<< HERON::APPL:[NOTES$LIBRARY]EURO_SWAS_AI.NOTE;1 >>>
                    -< Europe-Swas-Artificial-Intelligence >-
================================================================================
Note 206.12                 AI SEMINAR:  OCTOBER 1990                   12 of 14
ZUDEV1::STUTZ                                        41 lines   9-JUL-1990 16:54
                         -< ONE message, ONE company >-
--------------------------------------------------------------------------------
    
    
    Looking at AI in a production environment really means integration is
    essential. Integrated solution projects with an AI or OO flavor 
    require a special kind of integrated methodology. While most
    project managers are happy to use the DPM bible, KEs and OO programers
    as well as 4th GLers have made extensive use of prototyping. In DPM,
    there is only one page about throw away prototypes (DEMOs). 
    
    Those of us in Europe who are trying to deliver intgrated solutions with 
    the new tech flare are in need of a consistant manageable PROJECT 
    methodology which is credible also to formal PMs. We need to communicate 
    this PM consistancy to our customers. And we may need to define actions 
    (ie...AI forum...*an active one...*workshop*)to define an acknowledged 
    "new tech" methodology in Europe which conforms to DPM. 
    
    Presently, Steve Hodge (UK) and I have been putting some ideas
    together hybridizing DPM and our ideas from experience and
    others(ie..Spiral, Walters, Scan) together so that we have one message
    to give customers which works for commercial contract situations.
    We are using this now for our projects and we have learned alot!
    
    When DEC consultants get invoved across country borders this is very
    important. 
    
    Feedback from a customer who attended from Switzerland last customer
    seminar, was quite critical when he found that in Valbonne yet ANOTHER 
    Dec methodology was presented. 
    
    "New tech" needs more credibility and a consistant methodology is just 
    the start.
    
    Let's get started EUROPE! 
    
    Caroline 
    
     
    
    
    
    

             <<< HERON::APPL:[NOTES$LIBRARY]EURO_SWAS_AI.NOTE;1 >>>
                    -< Europe-Swas-Artificial-Intelligence >-
================================================================================
Note 206.13                 AI SEMINAR:  OCTOBER 1990                   13 of 14
GYPSC::BADE                                          18 lines   9-JUL-1990 19:24
                       -< need DPM and matching tools ! >-
--------------------------------------------------------------------------------
    Completely agree with Caroline. We are sure that implementing
    our (successful) AI projects using the "classical" DPM would have killed
    them in the first stage. Fortunately we could work around using the
    guide to expert systems program management and telling customers
    that AI projects are so much different.
    
    On the other hand, DPM is what our internal project groups have to 
    adhere to. If we want emerging technologies to be accepted in larger
    projects, we have to make sure that DPM is adapted to those technologies
    and that ready-to-use SW becomes available (NOT Field Test SW). We all
    know well that emerging technologies don't care about DPM. However,
    we'll loose credibility if DPM and emerging technologies point into
    different directions.
    
    Let's stay credible !
    Dirk Bade
    
    

             <<< HERON::APPL:[NOTES$LIBRARY]EURO_SWAS_AI.NOTE;1 >>>
                    -< Europe-Swas-Artificial-Intelligence >-
================================================================================
Note 206.14                 AI SEMINAR:  OCTOBER 1990                   14 of 14
YIPPEE::SUTHERLAND "Simon - MIS (AI Center Europe)"  20 lines  10-JUL-1990 08:23
     -< Traditional Vs. ES methodologies... our experiences at merging t >-
--------------------------------------------------------------------------------
I don't want to sidetrack this Seminar note too much but Manufacturing I.S. are
working hard to understand and implement the DMR lifecycle methodology. This one
DOES have a section on prototyping but does not quite match the requirements
of Expert Systems development.

We pointed this out to Mfg I.S. and we have been asked to volunteer
to provide a way of integrating the two. Any ideas from other sources on their
experiences of linking ES methods to traditional lifecycles would improve the
chances of success.

If this seminar is for customers I wonder whether a workshop with them to
wade through the issues would necessarily help us to understand them. Perhaps
we need a session prior to this where we can brainstorm ideas and get them
agreed and down on paper. ( lets get ONE Message ourselves first )

Anyway, back to the seminar ...

Regards,

	Simon

    I agree, George, that it would not be worth while to just come up with 
    some variant of a methodology which is produced only by the "AI
    community." Let's do one that is an extention of DPM for customer
    projects with the "other guys."
    
    I think we gained alot of experiences in our projects with customers in
    the field across Europe and have applied a spectrum of methods from
    Merise to quick-scan which could be shared and analyzed to everyone's 
    benfit. What worked what didn't and why. 
    
    It is a prerequiste to working across the boundries of culture which
    exist in Europe externally and internally for us all to agree on
    some key requirements and the description of the support of a methodology.
    
    Then we could work together with experienced DPM project managers to
    define the interface for "AI." WE would for once be creditable. 
    I think we should do it!!!                 
    
    DPM
    stands for Digital PROGRAM Methodology that means it's set up for
    several projects at once in an account. The account managers decide
    which business to pursue in their accounts. If we don't fit into their
    process we are high risk.
    1.1.6 of the enviroment and process DPM manual states that EVERY
    deviation from DPM MUST be recorded.
    Let's show them WE make the process work in the right way. Ya, right
    into the account PLAN.
    
    There is not too much actual business generated on research area. Customers
    like those kinds of seminars, but there's more business in main - stream 
    computing. "AI" or whatever we decide to call it is mature enough in some 
    areas, decision support, for example. We really can open doors with it! 
    I did it every time. 
    
    If I tell account managers around here I'm selling a shushh...
    "research project" they'll ask me when are you "AI" people ever going to 
    be finished playing around. Hej, it wasn't easy getting respect.
    That's what they used to say before I got two strategic commercial
    projects under my belt. Estimated business from the two at 5 million.
    I sold both with a big emphasis on methodology. Result-oriented.
    
    Of course, it's not true for all countries, but here "research" is a bad 
    word. There's no way I can imagine to apply DPM there. Swiss don't take
    risks you know. 
     
    Alot of "AI" people also know alot about conventional systems in the field.
    (Integration is usally the largest part of the solution.) I don't think
    we'd have problems drawing enough links.
    
    Is there a big difference in the engineering methodologies? 
    They don't seem to fit with the DPM manuals I have. That means I can't
    sell them to project managers or account managers to use in our
    projects. This kind of variant does not help either.      
    
    Let's keep us this discussion....
    
    Caroline,
    ACT-AI group leader Switzerland

George Ristich is the EIS person responsible to assure that DPM is updated to
reflect the Methodology needs of the EIS community as a whole. I have spoken to
George (Ristich) about our concerns vis-a-vis ES methodology needs. 

He will attend the AI CC Forum in October in order to explain where we are at
with respecty to taking these concerns into account. 

The intention here is that we will all contribute our inputs to the new version
of DPM, these inputs will be controlled by George R. with the support of a small
task force of experts from the AI CC - no more than 2 volunteers please.

Meanwhile we can all help to clarify our perceived methodology needs by making 
positive contributions in this (i.e. note 212) topic.


	i.e. Let's Just Contribute - the time for complaints is past!

Regards,
	Joe. 

    
    re. 214.4 
    
    I lost the thread with the "research" projects stuff. We're not at all
    in that line of business, and therefore the methodology doesn't need to
    address this kind of work. 
    
    Lets stay on track, and clarify the message we want to give the DPM
    people at the forum.
    
    G. 

    In Ayr we have adapted the customer DPM for internal use.
    Avril Hughes and I also added a separate AI&DPM guidelines document
    to help our MIS people use DPM with expert system components. I can
    sent the postscript file if anyone wants it.

    I have to beg ignorance on DPM, having never had it imposed upon me.
    However, can someone tell me if DPM is so rigid a methodology that the
    general guidelines presented in Digital's Guide To Expert Systems
    Program Management cannot be followed without violating DPM?
    
    Let me explain why I ask. During the year that I spent with McDonnell
    Douglas's Space Station proposal team, we were given special permission
    to do our work outside of the US Department of Defense Standard 2167
    mandated for system development because we were working in AI. However,
    our team was engineering oriented and we were particularly interested
    in the real world consequences of introducing KB technologies into the
    evolving Space Station computing architecture. As a result, we decided
    to do our development in strict accordance with 2167, which is the
    strictest standard that I am aware of. We set out to document where ES
    development was outside the scope of 2167 and we intended that document
    to be an extra deliverable on our project.
    
    As it turned out, there was almost nothing to write about. Now, there
    was things that we would like to have added to 2167 to aid in the
    documentation/tracking of rules/objects, but the methodology was
    flexible enough to handle rapid prototyping, incremental development,
    etc.
    
    Many years ago, I have taken training in DPM and can remember only one
    area that could be at issue with KB technologies. I remember that
    immediately after the functional specification stage, a formal test
    suite was generated. This was done to facilitate the final acceptance
    of the finished product by the customer; i.e., s/he agreed with the
    test suite when generated and the delivered code works according to the
    test suite. There was a lot of work spent on the test suite because of
    the legal implications of our delivering turnkey software to customers.
    
    This is one issue that I can identifty on my own. Could the
    participants please briefly bring up other types of major issues that
    seems to make this such a hot topic so that we all are aware of them
    prior to our CC meeting?
    

    
             I have been looking at the CASE world for the last 6 months and
    obviously the issue about methodology came accross. Here are some inputs
    that I can bring to the table:
    
        1. Large companies such as banks, insurances, etc. work with methods
    and are reluctant to use AI if there is no methodology associated to it.
    It is clear that we gain respect  if  we present a clear  method for our
    project development ( we are no more hackers!)
    
        2. I have presented to Roger Pressman,  who is  a recognized expert
    in s/w engineering our ESPM methodology. He was very impressed. He said
    that he had been looking for such a  methodology for  a long time,  and
    specially the customers  that he met.
    
       3. In fact, CASE methodologies have evolved from the WaterFall model
    in order to incorporate things which are clearly spell out in ESPM,i.e.:
    
              - room for prototyping 
              - emphasizing the business and human/organisation aspect
     In CASE there is a new and popular model called the SPIRAL model which 
    incorporates those features.
    
       4. Our problem inside Digital seems that there is no clear  relation  
    between our DPM and our ESPM. It  is clear that  project  methodologies 
    have to evolve with new coming  technologies.  For  instance,  standard 
    methodologies don't work if we want to use O-O languages.
    
       As a conclusion I shall say that we should strongly emphasize to our 
    customers the fact that we have a methodology (ESPM).  We  should  also
    emphasize that for us, AI (or rather  rules based systems )  represents
    just another programming paradigm (vs procedural, or OOP)  and as such,
    fits nicely in our s/w engineeering approach.
    
    Daniel
                                                                   

                                
    Alot of the discussion going on in EIS for sevices today is very
    relavant for us. Let's not be left out because we have a "funny" name and
    a methodology nobody trusts.
              
    After all, WE want to be part of the account plans. Professional
    Sevices for EIS is now a topic. If we could position ourselves in
    SIB we will do alot of buisness. New technology special services has a
    sellable tang - if we are part of the standard process ie...DPM.
    
    By including controlled evolutionary development for new technologies in 
    DPM we become main-stream ie...credible and accepted. And I bet they'll 
    even use it for some kinds of "conventional" development.  
    
    There are really two different kinds of animals that an "AI"
    technology/business consultant has to deal with:
    
    1. Account consultants/managers - who have to allow contact with
    2. Customers
    
    Both have a different set of issues here. 
    
    I agree with Daniel that customers accept us. They want to see that
    there is a methodology. The main thing here is just that all of the DEC
    AI people speak the same language. 
    In bringing in resouces from across Europe and the US this is an issue.  
    
    Internally we have a much harder job. The account manager is the guy
    who feels responsible for protecting the customer against all evils.
    The more strategic the account the worse this gets.
    They want to manage risks. Of course, our methodology in the grey book 
    is supposed to do that. But why is it not part of DPM ? 
    It's percieved that there is something shady about non-DPMers. Or as one 
    account consultant put it, "don't push some guru methodology on me, 
    DPM is the standard at corporate level." 
                                                             
    The feasibility study done in some methodologies is one way to package
    a service. This kind of strategy might be valuable in DPM. 
    But this has to include alot of business management.(Tools + techniques) 
    WE need to define how we should fit into the account plans.
    
    An AI study done here actually reorganized an entire customer development
    department. ***Thanks to Steve Hodge.*** They are now asking Digital to
    define their entire business process. They perfered us to a leading
    consulting company. The project is also in the bag.
     
    Yah, Daniel, we can't be just hackers anymore!
    
    Regards...Caroline