Lecture 4

Software Engineering Body of Knowledge SWEBOK  Articulating a body of knowledge is an essential step toward developing a profession because it represents a broad consensus regarding the contents of the discipline.  Without such a consensus, there is no way to validate …  A licensing examination  set a curriculum to prepare individuals for the examination  formulate criteria for accrediting the curriculum.

Software Engineering Body of Knowledge  Since 1980's there is a need for a description and understanding about what knowledge makes up the field of software engineering  There have been recent efforts to organize and define a software engineering body of knowledge (SWEBOK)

 The IEEE-CS and the ACM have a long- term effort underway to develop a comprehensive body of knowledge for software engineering  A body of knowledge was developed to help define and assess the software competencies needed in a software- intensive organization

 The SWE-BOK is organized into four “knowledge areas:” 1. The Core Area 2. The Foundations Area 3. The Recurring Area 4. The Supporting Area

1-Core Area  The Core Area includes those components that define the essence of software engineering: 1. Software Requirements 2. Software Design 3. Software Construction 4. Software Project Management 5. Software Evolution

2-Foundations Area  The Foundations Area includes those components which undergrad the Core Area and Recurring Area  The Foundations Area consists of the following components: 1. Computing Fundamentals 2. Human Factors 3. Application Domains

3-Recurring Area  Components in the Recurring Area are threads that occur through all of the Core Area components.  The Recurring components include the following: 1. Ethics and Professionalism 2. Software Processes 3. Software Quality 4. Tools and Environments 5. Documentation

4-Supporting Area  The components in the Supporting Area include other fields of study which provide.. ◦ building blocks for rounding out the education of students in software engineering.  They include, but are not limited to, ◦ general education ◦ Mathematics ◦ Natural sciences ◦ social sciences ◦ business studies & ◦ engineering.

 In establishing a boundary for software engineering, it is also important to identify the other disciplines that share a boundary and often a common intersection with software engineering. Software engineers should know material from these fields There are seven related disciplines: 1. Basic sciences and human factors 2. Computer engineering 3. Computer science 4. Management and management science 5. Mathematics 6. Project management 7. Systems engineering

 Two general tracks ◦ Science/Engineering Graduates  as part of computer science/engineering masters program  in a specific software engineering masters program ◦ Software engineering graduates  as part of computer science/ engineering masters program  in a specific software engineering masters program

 "Toy" programs 100's of lines  Small programs10,000 lines  Medium programs 100,000 lines  Large programs1,000,000 lines  Very Large programs10,000,000 lines  Small programs are typically implemented by individuals. Medium and larger programs are implemented by teams.

COST EFFORT LINES Product ($million) (Person Year) (of code) Lotus Ver k NASA Space Shuttle k CitiBank ATM k

dBase II took two programmers and 50,000 lines of code s dBase IV took 100 people, 500,000 lines of code in 1986

 It became clear in the mid-60s that:  software systems were developed far too slowly  many software projects failed  most projects were delivered late and cost far more than was budgeted  delivered systems were often of very low quality  This collection of maladies/problems (which is still with us) was labeled the “software crisis”

 Experts tried to resolve such as : ◦ Why does software development take so long? ◦ Why does it cost so much? ◦ Why does software has bugs? ◦ Why do we have difficulty managing software development efforts?  The software crisis prompted the creation of “software engineering” as a discipline

 From a 1995 till 2007 American General Accounting Office reported: ◦ more than 50% of SW contracts had cost overruns ◦ more than 60% of SW contracts had schedule overruns ◦ more than 45% of delivered SW could not be used ◦ more than 28% of SW was never delivered

 A recent IEEE survey found that  30% of all software development projects are canceled.  50% are more than 150% over budget  On average, only 60% of desired functionality is achieved.

1. While the cost of hardware has come down dramatically, the cost of software is increasing 2. Most SW errors and cost of repair are traceable to failures in the initial requirements 3. 2/3 of lifetime SW cost comes after installation

 The true cost of software failures shows up in the form of lost business and reduced overall profitability.  A business that fails to recognize the need for a new software process to keep up with competitors (or lead competitors, for that matter) may find itself unprofitable and subject to acquisition or even failure.

 A significant part of the problem is caused by a chaotic (disorganized)software development process.  Occasional Success is dependent on individual skills and heroic/Bold efforts  Significant effort is wasted throughout the development project because of duplication, false starts, and lack of software reuse.  Learning curves are high for new employees (or existing employees just joining the team  As the project ramps up, experienced staff spend more and more time training new staff, or correcting errors caused by inadequately trained new staff.

CustomerAgentProduct Process Resource Project transforms aids interacts with uses applies to produces performs Source: SESC Business planning group, vision 2000 Strategy statement, SESC/BPG-002, 1995

 Among all the objects of software engineering, Process is receiving the most attention because of a multitude of reasons.

 Software development is often thought of as a series of discrete activities: ◦ First, you analyze the problem and write down the requirements ◦ then, you design the code ◦ next, you write the code ◦ and finally, you debug your creation.  Unfortunately, this view of software production is extremely outdated.  Today, software creation needs to be viewed as a series of discrete steps, plus many continuous processes that guide the software creation process and inject quality into the creation effort.

 Experience of decades tells improved Software process results in improved software product  Process improvement is seen as the key to reducing costs, schedule and risk and improving product quality  How to improve process?  More importantly ◦ what is improved or good product? ◦ what is improved or good process?

 Product goodness scale  Min end ◦ what to expect  Max end ◦ what to expect

 Product goodness scale  Min end ◦ Unsatisfied customer, late, over budget  Max end ◦ Satisfied customer, on time, within budget

 Process goodness scale  min end ◦ what to expect  max end ◦ what to expect

 Process goodness scale  min end ◦ Inconsistently produces good products ◦ sometimes with no profits ◦ and/or sometimes with budget overruns  max end ◦ consistently produces good products with a profit

 A software process can be defined as a set of ◦ activities ◦ methods ◦ practices ◦ transformations that people use to develop and maintain software and associated products