Mallinnusmenetelmien kytt ja sovittaminen Method Engineering ITK T51, kevt 2004, 3 ov

1
Mallinnusmenetelmien käyttö ja sovittaminenMetho
d Engineering ITK T51, kevät 2004, 3 ov

• Juha-Pekka Tolvanen
• Department of Computer Science and Information
  Systems
• University of Jyväskylä

2
Teaching aspects

• Juha-Pekka Tolvanen, docent
• E-mail jpt_at_cs.jyu.fi
• Office hours by appointment, phone [phone]
• Class hours, week 9-18
• mondays 14-16
• weds 25.2 16-18, weds 3.3 16-18
• some changes to the program are possible
• Place Ag Alfa
• Student profile
• graduate students with a basic understanding of
  systems development
• prerequisites, ITK 150 Oliokeskeinen
  tietojärjestelmien kehittäminen
• Lecture slides and change notifications
• www.cs.jyu.fi/jpt/mallinnus

3
Course contents

• 4 major modules
• Part 1. Systems development, development
  strategies, modeling and metamodeling (6 hours)
• Part 2. Method engineering (14 hours)
• Part 3. MetaCASE tools and method engineering
  support (6 hours)
• Part 4. Method implementation tasks

4
Lecture texts

• Kieburtz, R. et al., A Software Engineering
  Experiment in Software Component Generation
• Proceedings of 18th International Conference on
  Software Engineering, Berlin, IEEE, Computer
  Society Press, March, 1996ftp//cse.ogi.edu/pub/p
  acsoft/papers/icse18.ps
• Pohjonen, R., Boosting Embedded Systems
  Development with Domain-Specific Modeling
• RTC Magazine, 2003 http//www.metacase.com/papers/
  RTC04_Pohjonen.pdf
• Tolvanen, J.-P., Incremental Method Engineering,
• diss. 1998. Chapter 2, Chapter 3, Section 4.4,
  1998. http//www.cs.jyu.fi/jpt/doc/thesis/ime.htm
  l

5
Evaluation

• 3 study weeks (3 ov.)
• Examination (50 )
• Method engineering task (50)
• Participation in the lectures (10 extra bonus)
• Excellent performance - is always prepared when
  asks demonstrates insight into the assigned
  material, adds broad value or a good insight to
  the discussion when volunteering to respond.
• Good performance - generally prepared when asked
  volunteers responses, which are mostly on the
  mark and/or add some value to the discussion.
• Fair performance - infrequently prepared and/or
  volunteering answers when asked able to respond
  to questions without too much prompting.
• Poor performance - frequently unprepared and/or
  absent.

6
Method engineering task

• A method engineering task
• Implementation and/or extending of a
  domain-specific language
• Implementation of some generation functionality -
  extension
• Written analysis of the language definition
  (metamodeling) process
• 2-3 pages in length of pure text
• Explaining the rationale of method definition and
  implementation
• Generated examples of the method use
• The format of the written report will be
  discussed in the class. NO CREDIT WILL BE GIVEN
  FOR COPIED WORK.

7
Course objectives

• Manage method development and understand key
  contingencies that affect the choice and
  adaptation of method knowledge
• Understand the role of models in code generation
• Be able to apply and follow Method Engineering
  principles
• Be able to specify modeling languages (using
  metamodels)
• Be able to efficiently use a metaCASE tool
  (MetaEdit) in modeling and implementing a chosen
  methodology part.

8
Motivation and background

• Trends in software development
• Software everywhere!
• Number of software (IS/ICT) development companies
  grow
• (one of ) the largest industries in USA
• Technology becomes more complex and applications
  larger!
• Productivity and quality are the key concerns of
  any company developing software!
• Newer programming languages have had minor
  influence to productivity and quality
• Software development faces many problems, e.g
• low productivity Standish Group 16 on time and
  within budget
• relatively high failure rate
• lack of experienced people
• continuous evolution and migration needs with new
  technologies
• increasing complexity and size of software
  products

9
About the maturity of software development

• Classification (Humphrey 1988) based on, e.g
• identification of ISD phases and steps
• use of methods and tools
• use of project planning
• managers understanding
• measurement of results

10
About the maturity of software development
11
How to change and improve software development?

• Plenty of solutions possible and also needed!
• quality assurance programs
• development and use of components
• application-package based ISD
• better methods, tools, and languages
• ...
• One solution
• Better development methods and tools are required
• noted already when first systems were build in
  50s
• like in other engineering disciplines
• Models should not be isolated from later stages
  of the development life-cycle
• Model-based development instead of pure coding

12
Motivation Model and generate software
13
About method(olog)ical solution

• Hundreds of different methodologies are developed
• Agile Data, www.agiledata.org
• Incremental and iterative database development
• Agile Modeling, www.agilemodeling.com
• For effective modeling and documentation of
  systems
• Dynamic System Development Method, www.dsdm.org
• ISO 9001 certified formalization of Rapid
  Application Development
• Feature Driven Development, www.featuredrivendevel
  opment.com
• Short iterations that includes explicit modeling
• Rational Unified Process, www.rational.com
• A rigorous process that is iterative and
  incremental

14
About modeling solution

• Hundreds of different modeling languages and
  methods are developed
• ER and its various extensions of datamodels
• EXPRESS-G
• SA/RT
• UML
• Various workflow models (xml-based like BPML,
  xBML etc.)
• Various domain/application-specific methods

15
Method evolution
16
Method-tool companionship
17
Universal versus application-specific methods

• Have methods solved the problems in ISD?
• Not as expected/hoped methods are surprisingly
  little used
• Organizations tend to adapt/build own
  methodologies
• Can ISD be supported by a single method?
• Contingency approach No!
• Experiences from standardization efforts No big
  success!
• Tried already in 70s with IDEF (DoD), 80s with
  SSADM (UK) and Merise (France), and in 90s with
  Euromethod
• Now tried again with UML
• Why not?
• Software development tend to be
  situation-specific
• technology evolves, systems evolves, huge
  differences in systems, organizations, cultures,
  tools in use etc.

18
Methodology adoption

• Typically not a rational process
• Process initiated often by
• actual crisis
• new technology / opportunity (OO/WWW/Web services
  etc)
• change in development scope and scale (large
  change in systems development)
• changes in management
• Choice
• consultant hiring / bring in knowledge
• own method development organization together with
  external consultants
• own method engineers/method engineering project

19
How to change system development?

• This course is about how to change modeling
  languages, code generators and associated
  resources that support their use!
• This course is about how to use also computer
  support in doing so!