Software Engineering Activities

1. Software Engineering Activities Requirements Activities Design Activities Coding Activities Testing Activities Integration and Release Maintenance Activities Project Management Activities (time)

2. Some Current Problems in Software Engineering (although improving) • No satisfactory way (imprecise and incomplete) to describe the software • Too many different Notations • Lack of Discipline in Process • Imprecise Process Description • Integration of multiple parts • Lack of precise Measurements • Quality continues to plague the industry • Insatiable demand for more software (development speed) A little more than the author’s list on page 7 of text.

3. Formal Methods • Use of Mathematical tools to help perform the tasks in software engineering: • Requirements elicitation, analysis, specifications • Design analysis and specifications • Test case analysis, design, and specifications • Programming • Unit Testing • Functional testing • Integration • System testing • Maintenance What if we can formally describe the software development process---- would we be able to develop software with a lot more automation than today?

4. Formal Method in Software Engineering is Still “Relatively New” - ~40 years • Automatic Proof of Program Correctness (1970’s – CMU, Stanford, MIT, etc.) • Vienna Definition Language:(VDL) IBM Vienna Labs. A language for formal, algebraic definition via operational semantics. Used to specify the semantics of PL/I. (Early 1970’s) • Vienna Definition Method: (VDM) A program development method based on formal specification using the Vienna Development Method Specification Language (VDM-SL). (late 1970’s through early 1990’s) • Cleanroom Method: Started by H. Mills of IBM in the 1980’s and picked up by others. • Systematic Approach to Creating Software: ‘Software Processes are Software Too” --- Leon Osterweil in the late 1980’s and creating Formal ProcessDefinitions in the 1990’s

5. But - - - • Realize that we have a lot of hurdles - • e.g. Agile Development • X-treme Programming • Crystal clear • RUP • SCRUM • How do we merge formalism with “wild” creativity and “speedy” coding

6. Some “Myth” about Formal Methods • Formal Methods eliminate Testing • Validation of requirements always need demonstration of some testing results (especially by the customers) • Formal Methods eliminate the need of all other notations and need of natural language • Formal methods have not captured every aspect of software engineering (in fact very little) • Formal Methods will change the process • Notational change and rigor only clarifies, not force a change in, a process or methodology • You need a PhD in math to practice formal methods • Applying mathematics requires one to be more careful and perhaps learn some more logic and math, but does not require one to become a math genius. It is, however, “difficult” for some people --- including me (lack of patience).

7. A Key Software Engineering Task • Entry Point for software engineering • REQUIREMENTS: • Represents user/customer needs & desires (important) • Begins with users’/customers’ own articulation of their needs in natural language. (imprecise and incomplete) • Formal Methods may be able to help: • In representing requirements through formal notations and “well-defined” concepts • Validating requirements through “proofs” • Verification of transformations of requirements to design

8. Types of Requirements Specifications • Functional : what is the system to do? • Data : what information is processed? • Non-Functional: what are the constraints? • User Interface: what should the interface to users look like? • Business Flow: what is the environment in which the system operates? • System Interface: What are the necessary interfaces to other systems? Which of These Have Formal Notations? How Well and Often Are They Recognized and Utilized ?

9. Requirements Statements Shortcomings • Vagueness and Ambiguity: difficult to be precise over a voluminous amount of information. • “ -------- should be easy to use ------” • Contradiction & mixed-Requirements: different types of requirements may be at variance with each other. • “-----all pay checks should have both federal and state tax deducted --------- some people will not have state tax ----” • Incompleteness: difficult to include all the information (especially with natural language) • “ ----- length of password should be at least 6 characters---” Which ones do you think has a chance of getting helped by formal methods.

10. Can We Improve Upon These Shortcomings? • Use Formal (Math) Methods: • More precise and less vague • “easy to use ?” • Less contradiction and mixed-requirements • “all” vs “some” • More Complete • “ length password >= 6 char” what about the other end? • “ 6=< length password =< 12 “ but would you have thought of this just because it is more formal?

11. Shortcomings of Formal Methods • Difficult to expect the users/customers to converse in formal notations. (They are retailers, nurses, managers, engineers, etc.) • Not all software engineers are familiar or comfortable with formal mathematical notations. • It is not “easy” for most of the people & may be “deceiving” to some

12. “Danger of Formalism?” You may be “lulled” into Invalid Conclusions • Proof of 2=1: • Let: a = b • Then multiple both sides by a: a x a = a x b or a**2 = ab • Add (a**2 - 2ab) to both sides; a**2 + (a**2 -2ab) = ab + (a**2 -2ab) a**2 + a**2 – 2ab = a**2 – 2ab + ab 2(a**2) – 2ab = a**2 – ab • Simplifying, we have : 2 (a**2 – ab) = (a**2 – ab) • Dividing both sides by (a**2 – ab): we have 2 = 1 !!!!! What’s wrong with this ?! The syntactical operations are ok --- what about semantics?