Agendas — A concept to guide software development activities

  • M. Heisel
Part of the IFIP Advances in Information and Communication Technology book series (IFIPAICT)


We present the concept of an agenda. This concept represents process knowledge in the area of software development. An agenda consists of a list of steps to be performed when developing a software artifact. Each activity may have associated a schematic expression of the language in which the artifact is expressed and some validation conditions that help detect errors. Agendas provide methodological support to their users, make development knowledge explicit and thus comprehensible, and contribute to a standardization of software development activities and products.


Software engineering methodology process modeling formal methods 


  1. [1]
    Y. Chemack. A statistical approach to the inspection checklist formal synthesis and improvement. IEEE TSE, 22 (12): 866–874, Dec. 1996.Google Scholar
  2. [2]
    D. Coleman, P. Arnold, St. Bodoff, Ch. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes. Object-Oriented Development: The Fusion Method. Prentice Hall, 1994.Google Scholar
  3. [3]
    J. Davies. Specification and Proof in Real-Time CSP. Cambridge Univ. Press, 1993.CrossRefzbMATHGoogle Scholar
  4. [4]
    ESPRESS. Engineering of safety-critical embedded systems. Project description: http: //www. first.gmd. de/espress.Google Scholar
  5. [5]
    E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns — Elements of Reusable Object-Oriented Software. Addison Wesley, Reading, 1995.Google Scholar
  6. [6]
    P. Garg and M. Jazayeri. Process-centered software engineering environments: A grand tour. In A. Fuggetta and A. Wolf, editors, Software Process, number 4 in Trends in Software, chapter 2, pp. 25–52. Wiley, 1996.Google Scholar
  7. [7]
    D. Gries. The Science of Programming. Springer-Verlag, 1981.CrossRefzbMATHGoogle Scholar
  8. [8]
    M. Heisel. Methodology and Machine Support for the Application of Formal Techniques in Software Engineering. Habilitation Thesis, TU Berlin, 1997.Google Scholar
  9. [9]
    M. Heisel and N. Lévy. Using LOTOS patterns to characterize architectural styles. In M. Bidoit and M. Dauchet, editors, Proceedings TAPSOFT’97, LNCS 1214, pp. 818832. Springer-Verlag, 1997.Google Scholar
  10. [10]
    M. Heisel, T. Santen, and D. Zimmermann. Tool support for formal software development: A generic architecture. In W. Schäfer and P. Botella, editors, Proc. 5th ESEC, LNCS 989, pp. 272–293. Springer-Verlag, 1995.Google Scholar
  11. [11]
    M. Heisel and C. Sill. Formal specification of safety-critical software with Z and real-time CSP. In E. Schoitsch, editor, Proceedings 15th SAFECOMP, pp. 31–45. Springer-Verlag London, 1996.Google Scholar
  12. [12]
    C. Heitmeyer, R. Jeffords, and B. Lebaw. Automated consistency checking of requirements specifications. ACM TOSEM, 5(3): 231–261, July 1996.Google Scholar
  13. [13]
    K. Huff. Software process modelling. In A. Fuggetta and A. Wolf, editors, Software Process, Trends in Software 4, chapter 2, pp. 1–24. Wiley, 1996.Google Scholar
  14. [14]
    L. Osterweil. Software processes are software too. In 9th ICSE, pp. 2–13. IEEE Computer Society Press, 1987.Google Scholar
  15. [15]
    C. Rich and R. C. Waters. The programmer’s apprentice: A research overview. IEEE Computer, pp. 1025, Nov. 1988.Google Scholar
  16. [16]
    M. Shaw and D. Garlan. Software Architecture. IEEE Press, 1996.Google Scholar
  17. [17]
    T. Shepard, S. Sibbald, and C. Wortley. A visual software process language. CACM, 35(4): 37–44, Apr. 1992.Google Scholar
  18. [18]
    D. R. Smith. KIDS: A semi-automatic program development system. IEEE TSE, 16(9): 1024–1043, Sept. 1990.Google Scholar
  19. [19]
    J. Souquières and M. Heisel. Expression of style in formal specification. In W. B. Samson, editor, Proc. Software Quality Conf. pp. 56–65, ISBN 1 899796 02 9, 1996. Univ. of Abertay Dundee.Google Scholar
  20. [20]
    J. Souquières and N. Lévy. Description of specification developments. In Proc. of Requirements Engineering ’83, pp. 216–223, 1993.Google Scholar
  21. [21]
    J. M. Spivey. The Z Notation -A Reference Manual. Prentice Hall, 1992.Google Scholar
  22. [22]
    D. S. Wile. Program developments: Formal explanations of implementations. CACM, 26(11): 902–911, Nov. 1983.Google Scholar

Copyright information

© IFIP 1998

Authors and Affiliations

  • M. Heisel
    • 1
  1. 1.Fakultät für InformatikOtto-von-Guericke-Universität MagdeburgMagdeburgDeutschland

Personalised recommendations