Shihong Huang shihong@fau - Universitetet i oslo...Shihong Huang 5 Florida Atlantic University...

Shihong Huang [email protected]

Dept. of Computer & Electrical Engineering and Computer Science Florida Atlantic University

Guest Lecture INF5120 Model Based System Development

February 27, 2012

Florida Atlantic University Shihong Huang 2


Florida Atlantic University


  Motivation of Semat – the Grant Vision   The basis for Semat   The concept of method, practices and kernel   Modeling and Kernel language (Arne and

Brian)

  Software community has developed software for over the past five decades

  Applications of software have generated enormous impact on both our society and our lives

  However, have we advanced our own discipline over these years?

  How have we been doing these years?

  improve the way we develop software


  OO development   Components, UML, Unified Process   RUP and CMMI   XP   Scrum   Kanban – now “the talk in town”   And more …



SOA

Coud Computering

Web Services

EDA

SPEM

CMMI

What will be the next silver bullet?

  Software engineering is gravely hampered today by immature practices

  Specific problems include:   The prevalence of fads more typical of fashion industry than

of an engineering discipline   The lack of a sound, widely accepted theoretical basis   The huge number of methods and method variants, with

differences little understood and artificially magnified   The lack of credible experimental evaluation and validation   The split between industry practice and academic research


Source: Semat Call for Action


“High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership”

-- Capers Jones et al, The Economics of Software Quality Addison-Wesley Longman, 2011


Ivar Jacobson Bertrand Meyer Richard Soley

Software Engineering Method and Theory

Jacobson, Meyer, & Soley “Call for Action: The Semat Initiative” Dr. Dobb’s Journal, December 10, 2009

  Semat supports a process to refound software engineering based on a solid theory, proven principles and best practices that:   Include a kernel of widely-agreed elements, extensible for

specific uses   Addresses both technology and people issues   Are supported by industry, academia, researchers and users   Support extension in the face of changing requirements and

technology


Source: Semat Vision Statement

At its heart is a kernel of widely agreed elements. The kernel would provide the common ground help practitioners to compare methods and make better decisions of their practices.

The goal is to create a kernel and a language that are scalable, extensible, and easy to use, and that allow people to describe the essentials of their existing and future methods and practices so that they can be composed, compared, evaluated, tailored, used, adapted, simulated and measured by practitioners as well as taught and researched by academics and researchers.


Being able to design a method from a set of relevant practices, all described using a kernel of essential elements are key requirements of Semat.

Industry

Academia

Practitioners (Engineers and

Managers) Software

engineering

Pragmatic, seeking available

methods that are easy to use

Concerned about getting

software better, faster cheaper &

happier

Teach and research Software Engineering

Shihong Huang 14 Florida Atlantic University

 Method  Practice  Kernel  Kernel language


  As being instantiated   The activities -- created from the definition -- are

executed by practitioners in some order to get result, specified by the definition

  This view – “the team is the computer, the process is the program” - is not suitable for creative work like software engineering   which requires support for work, which is agile, trial-and-

error based and collaboration intensive


  A method is a composition of practices   As opposed to an interconnection of process/method

components, disciplines, or similar   Methods are dynamic and used   Methods are not just descriptions for developers to

read, they are dynamic, supporting their day-to-day activities

  This changes the conventional definition of a method   A method is not just a description of what is expected

to be done, but a description of what is actually done


  A repeatable approach to doing something with a specific purpose in mind

  There are several kinds of practices   but the basic and most important kind of practices are

the concrete practices   A concrete practice is a complete end-to-end activity

with a clear beginning and end supporting software practitioners in getting their job done

  These practices give value one-by-one   They are what users want to make lean   They are what you want to measure and provide

metrics for


Source: OMG Proposal and Semat Three Year Vision

  Basically every software development team, with some exceptions, has its own method

  There to be probably over 100,000 methods in existence, with many of them never being described

  but the number of relevant separate practices in use should be much smaller


Being able to design a method from a set of relevant practices, all described using a kernel of essential elements are key requirements of Semat.

Technical Practices

Cross-Cutting

Practices

Use Case

Process Modeling

Product Architecture

$

Component Iteration

Team

up up

Unified Process Lifecycle

The Essentials

The Kernel

Many more practices: - Scrum

- User Stories - Test-Driven Design

- Continuous Integration

- Self-Organizing Teams

- Pair Programming

Source: EssWork


Existing Method

Your Own Best

Practices

Kernel

+

New Method

Change starts by harvesting your best practices from your own method

You get a method structured for the future

Source: EssWork


  The Kernel we harvested is very small, extracted from a large number of methods

  The Kernel is practice and method agnostic

Kernel

The Kernel includes the essence of software engineering


Your Own Best Practices

Kernel

+ + Other Practices

From Many Sources

Iterative

Component

Architecture

Use Case

Team

+++ PLA

Source: EssWork

OK, there is a kernel! Maybe there are many? But none is widely-accepted! That needs to be changed!


  The common ground   Identify and specify a kernel including the essential

elements in software engineering – key requirement   Irrespective of code, software system, solution,

methods, organization   A kernel of elements: pervasive concepts and qualities

– the common ground   Always prevalent in any software endeavors   Separate of concerns: separating kernel from specifics

of different methods


  Finding the constituents of the kernel is critical   Uncover universal, significant and relevant elements   Need to be widely agreed upon   The kernel is defined using a domain-specific

language

  The kernel and the language are small and light at their base

  But extensible to cover advanced uses (e.g., safety-critical systems)

Florida Atlantic University Shihong Huang

27

The domain being practices for software development

  A new unified methodology   A new software process meta-model   A new body of knowledge   A new modeling language   A trick to get people to build or buy more tools


The kernel should be as simple as a map of when we develop software:   what we already have (e.g. teams and projects)   what we already do (e.g. specify and implement)   what we already produce (e.g. software systems)

  Irrespective of   the way we work   whether we write documentation, or   even if the result is good or bad

  The kernel should be concrete, focused and light


A kernel is a set of elements used to form a common ground for describing a software engineering endeavor


Example of essential elements:   Work   Team   Requirements   Software system   Opportunity   Stakeholder

“You have achieved perfection not when there is nothing left to add, but when there is nothing left to take away”

-- Antoine de Saint-Exupéry


Contains everything to do with the actual use and exploitation of the software system to be produced

Contains everything to do with the team, and the way that they approach their work.

Contains everything to do the specification and development of the software system.

Are

a of

con

cern

s

Source: Essence Proposal to OMG RFP ad/2011-06-26


  Representations of the essential things to work with   The Alphas provide descriptions of the kind of things

that a team will manage, produce, and use in the process of developing, maintaining and supporting good software

  They also act as the anchor for any additional sub-alphas and work products required by the software engineering practices



  Representations of the essential things to do.   The Activity Spaces provide descriptions of the

challenges a team faces when developing, maintaining and supporting software systems, and the kinds of things that the team will do to meet them

Activity   An activity defines one or more kinds of work items

and gives guidance on how to perform these



Alpha

Area of concern


Activity space

Area of concern

Shihong Huang 35 Florida Atlantic University Source: Essence Proposal to OMG RFP ad/2011-06-26


  The people, groups, or organizations who affect or are affected by a software system

  The stakeholders provide the opportunity and are the source of the requirements and funding for the software system

  They must be involved throughout the software engineering endeavor to support the team and ensure that an acceptable software system is produced


Florida Atlantic University Shihong Huang 37 Source: Essence Proposal to OMG RFP ad/2011-06-26


  The set of circumstances that makes it appropriate to develop or change a software system

  The opportunity articulates the reason for the creation of the new, or changed, software system

  It represents the team’s shared understanding of the stakeholders’ needs, and helps shape the requirements for the new software system by providing justification for its development



  What the software system must do to address the opportunity and satisfy the stakeholders

  It is important to discover what is needed from the software system, share this understanding among the stakeholders and the team members, and use it to drive the development and testing of the new system



  A system made up of software, hardware, and data that provides its primary value by the execution of the software.

  A software system can be part of a larger software, hardware, business or social solution



  The group of people actively engaged in the development, maintenance, delivery and support of a specific software system

  The team plans and performs the work needed to create, update and/or change the software system



  Activity involving mental or physical effort done in order to achieve a result

  In the context of software engineering, work is everything that the team does to meet the goals of producing a software system matching the requirement and addressing the opportunity presented by the stakeholders

  The work is guided by the practices that make up the team’s way-of-working



  The tailored set of practices and tools used by a team to guide and support their work

  The team evolves their way of working alongside their understanding of their mission and their working environment

  As their work proceeds they continually reflect on their way of working and adapt it to their current context, if necessary



 Method  Practice  Kernel  Kernel language and Modeling (Arne and

Brian)


Source: Semat Three Year Vision

  The Kernel and the Language   Tools (including open source)   The Practice Market Place   Curricula   Text Books and Papers   Research


1. Ivar Jacobson and Bertrand Meyer: “Methods need theory” Dr. Dobb's Journal, August 06, 2009. Online at http://www.drdobbs.com/architecture-and-design/219100242

2. Ivar Jacobson and Ian Spence: “Why we need a theory for software engineering” Dr. Dobb's Journal, October 02, 2009. Online at http://www.drdobbs.com/architecture-and-design/220300840

3. Ivar Jacobson, Bertrand Meyer, and Richard Soley: “Call for Action: The Semat Initiative” Dr. Dobb's Journal December 10, 2009. Online at http://www.drdobbs.com/architecture-and-design/222001342

4. Ivar Jacobson, Bertrand Meyer, and Richard Soley: “The Semat Vision Statement” online at http://www.semat.org/pub/Main/WebHome/SEMAT-vision.pdf

5. Shihong Huang, the 1st Semat Workshop report, online at: http://www.semat.org/pub/Main/SematZurichMarch2010/Zurich_meeting_report.pdf

6. Shihong Huang, the 2nd Semat Workshop Report, online at: http://www.semat.org/pub/Main/WebHome/2nd_Semat_Workshop_Report.pdf

7 Shihong Huang and Paul McMahon, the 3rd Semat Workshop Report, online at: http://www.semat.org/pub/Main/WebHome/3rd_Semat_Workshop_Report.pdf 8.  Ivar Jacobson, Shihong Huang, Mira Kajko-Mattsson, Paul McMahon, Ed Seymour. “Semat -

Three Year Vision” Programming and Computer Software 38(1): 1-12 (2012), Springer 2012. DOI: 10.1134/S0361768812010021.

9.  “ Essence – Kernel and Language for Software Engineering” A proposal submitted to OMG RFP (OMG Document ad/2011-06-26)


Shihong Huang shihong@fau - Universitetet i oslo...Shihong Huang 5 Florida Atlantic University...

Documents

Transcript of Shihong Huang shihong@fau - Universitetet i oslo...Shihong Huang 5 Florida Atlantic University...