Relationship to Textbook

• This lecture is partially based on material in Chapter 1 of the Jalote textbook
• More info on Jalote
  • Ph.D. from the Univ. of Illinois at Urbana Champaign
  • Has worked as a faculty member at both University of Maryland, College Park and the Indian Institute of Technology at Kanpur
  • IEEE Fellow
  • Has also served as the Vice President (quality) at Infosys Technologies Ltd and as a Visiting Researcher at Microsoft Corporation
  • He is on the editorial board of the IEEE Transactions on Software Engineering journal

Comparison to other CS Disciplines

• Software Engineering is unlike other Computer Science topics in that it focuses on the development of software generically
  • Other disciplines, such as databases, operating systems, compilers, etc., focus on particular software products
• It is also different in that it has a strong focus on process and is an attempt to turn software development into an engineering discipline
  • Software Engineering is the systematic approach to the development, operation, maintenance, and retirement of software systems
• Basic Question of Software Engineering: How do we develop industrial-strength software?

Thought Experiment

• Say you are given a description of a software system and you estimate, based on prior experience, that such a system would be approximately 10,000 lines of Java code
• Assuming that the problem domain does not require specialized expertise, how long would it take you to build a 10,000 line program?

Discussion

• Jalote claims that most students would answer 1 to 3 months
• Assume a student finishes the project in 2 months, that would result in a productivity of 5,000 lines of code (LOC) per month.

• Jalote then points out that across industries, professional software development teams average somewhere on the order of 100 LOC per month to 1000 LOC per month
• Assuming the latter rate, a professional software development team would require 10 months to build a system that meets the same requirements that our hypothetical student did in two months

• The question we have to ask, of course, is what gives rise to this disparity?

The Answer

• Two different systems are being built: a student system and an industrial-strength software system (terms defined by Jalote)
• What are the differences?

Key Difference

• Quality!
• According to the international standard on software product quality, software quality is defined with respect to six main attributes (aka characteristics). These attributes are:

• Each of these characteristics is further broken down into other attributes that can be used to assess a system's level of quality for that attribute
  • Reliability is often ranked as the most important quality attribute. If a system is unreliable, users will stop using it and find ways to work around it.
• Defining quality to have multiple dimensions leads to two important consequences
  • First, software quality cannot be reduced to a single number... instead the quality of a software product needs to be assessed across these multiple characteristics. For instance, a system that meets all of its functional requirements but has a horrible interface may be judged as being of low quality.
  • Second, quality is project-specific. Each development context will place different weights with respect to each quality attribute: perhaps a client needs a particular feature fast no matter how horrible the interface is. In this case, a high quality system is one which delivers the feature by the time the client needs it.

Historical Background: 38 years

• First Software Engineering Conference
  • NATO-sponsored conference in 1968
• “Software Crisis”
  • Systems were designed by identifying the hardware first
    • Software was allocated about 1-2% of the budget
  • However, software was causing all the problems (!) and thus needed more attention
• Progression of SE: An evolution of the programming activity
  • Early stages of computing
    • User/Developer were the same person
    • Problems were well-understood
      • First programs calculated metrics about artillery shells!
  • High level languages began to appear in the 1950s
    • Along with the profession of “programmer”
  • Large Software Systems for Commercial Ventures in the 1960s
    • Teams of Programmers
    • Separate end-users
    • Complex Problems
• “Software Crisis” coined, as problems became apparent. The problem? Software is typically
  • late
  • over budget
  • faulty
  • costly to maintain
  • difficult to evolve
  • …
• Consider the following:
  • Loss of NASA’s Mars Climate Observer
    • due to conversion error of English and Metric units!
    • even worse: problem was known but politics between JPL and Houston prevented fix from being deployed
  • Leap-year bug
    • A supermarket was fined $1000 for having meat around 1 day too long on Feb. 29, 1988
  • Denver International Airport
    • Luggage system: 16 months late, 3.2 billion dollars over budget!
• Software Engineering formed as a discipline in 1968
  • Many “solutions” put forward
    • New approaches to Project Management
    • New Team Organizations
    • Better Languages and Tools
    • Organizational Standards
  • And here we are 38 years later! ☺

The Problem Domain (1 of 3)

• SE has to deal with the construction of Industrial Strength Software
• Software is Expensive
  • In contract development, development organizations will charge clients roughly $100K a person-year or $8.3K a person month
  • Average productivity for a person month ranges from 300 LOC to 1000 LOC so the lower and upper limits for the cost of a line of code is $8 to $28
  • Lets say you have a project that ends with 50,000 lines of code produced. How much would it cost?
  • Given a production rate of 1000 LOC per month, it would take 50 months to produce the system, and if you charge $8.3K per month, the total is approximately $417K!
  • The same project with a production rate of 300 LOC per month would take 166 months and cost $1.4M!

The Problem Domain (2 of 3)

• Software is Late and Unreliable
  • One study in the late 80s found that in a survey of 600 firms, more than 35% reported having a runaway development project. A runway project is one in which the budget and schedule are completely out of control.
  • CHAOS Report from Standish Group
    • Has studied over 40,000 industry software development projects over the course of 1994 to 2004.
    • Success rates (projects completed on-time, within budget) in 2004 was 34%, up from 16.2% in 1994
    • Failure rates (projects cancelled before completion) in 2004 was 15%, down from 31% in 1994.
    • In 2004, “challenged” projects made up 51% of the projects included in the survey.
      • A challenged project is one that was over time, over budget and/or missing critical functionality
    • Most challenged projects in 2004 had a cost overrun of under 20% of the budget, compared to 60% in 1994
    • The average cost overrun in 2004 was 43% versus an average cost overrun of 180% in 1994.
    • In 2004, total U.S. project waste was 55 billion dollars with 17 billion of that in cost overruns; Total project spending in 2004 was 255 billion
    • In 1994, total U.S. project waste was 140 billion (80 billion from failed projects) out of a total of 250 billion in project spending
  • So, things are getting better (attributed to better project management skills industry wide), but we've still got a long way to go!
    • 66% of projects in 2004 did not succeed!
  • With respect to unreliability, a "defense study" mentioned by the textbook, reported that 70% of all equipment failures were due to software within systems that contain electrical, hydraulic, and mechanical sub-systems.
  • Software failures are different from failures found in other engineering disciplines
    • In other disciplines, failures tend to come from a change in the physical or electrical properties of the system caused by aging.
    • Software components do not age... failures come from mistakes made during the design and development process or due to changes in the external environment
    • Since extensive testing is done on software systems, failures tend to come when code that is rarely executed is activated due to a unique set of circumstances in its operating environment
      • Indeed, as Fred Brooks notes, software systems have so many states, its impossible to test them all, and, as such, if the system encounters a situation not anticipated by its developers, it enters a state of execution that has not been tested at all!
    • As such, when a failure occurs in a system that has been running for some time, the root cause of the problem has been in the system since it was first deployed.

The Problem Domain (3 of 3)

• Software requires maintenance and rework
  • After software has been created and deployed, it enters a maintenance phase
    • This may seem odd given the previous slide: if software doesn't age, why does it need maintenance?

• Maintenance is different from new software development because it is work applied to an existing software system
• As such, the primary task associated with maintenance is software understanding and the primary cost associated with maintenance is the rework that occurs when a new requirement is given or an existing requirement is changed. Rework involves updating the requirements document and understanding the impact of that change on the design document. Then, you must change the design and understand the impact on the implementation, etc.
• Figure 1.1 of the Jalote textbook shows how software costs are increasing while hardware costs decrease. It also shows that the costs associated with maintenance are consuming a greater percentage of the total software costs. This is hardly surprising as large systems typically spend up to 75% of their lifetimes in maintenance.

SE Challenges (1 of 5)

• In general, software engineering has as its goal the creation of a software system that meets the needs of its users
• In meeting this goal, software engineering is [taking] software development closer to science and engineering and away from ad-hoc approaches for development whose outcomes are not predictable.
• In particular, we need to develop methods that make developing particular classes of software systems repeatable. That is, if the methods are used by different teams of developers, similar software is produced.
• Software engineers encounter several challenges to meeting this goal, including:
  • Scale
  • Quality and Productivity
  • Consistency and Repeatability
  • Change

SE Challenges: Scale (2 of 5)

• Developing large systems requires different techniques than developing small systems
  • Recall the chemist/chemical engineer distinction and the CFP for Ultra-Large Scale systems that I discussed on Tuesday
• In particular, as we scale up, developers require more formal development techniques and more formal project management techniques
• 
• As an analogy, Jalote asks you to consider the difference between counting the number of people in a room and taking the census of a country
• Consider some of the processes at "Level 4" organizations, such as Northrop Grumman

SE Challenges: Quality and Productivity (3 of 5)

• Engineering disciplines are driven by the practical parameters of cost, schedule, and quality
  • A solution that takes enormous resources and many years to complete may not be acceptable
  • A poor quality solution may not be much use, even if its low costs or completed quickly
  • In software engineering, productivity (measured in KLOC per person-month) can encapsulate both cost and schedule concerns
    • As productivity goes up, the cost per person-month goes down. (The same work can be done in fewer person-months)
    • In addition, as productivity goes up, the amount of time it takes to finish a project goes down
  • We already discussed the notion of software quality above on slide 7

SE Challenges: Consistency and Repeatability (4 of 5)

• An organization involved in software development not only wants high quality and productivity, it also wants these things consistently
• Consistency of performance is an important factor for any organization; it allows an organization to make predictions and estimates for future projects
• The SE community has looked at these issues and developed standards for organizations to follow to help them achieve consistency
  • ISO 9001
  • Capability Maturity Model
• We will discuss this type of work in more detail next week

SE Challenges: Change (5 of 5)

• A big problem in software development is that "things change" all the time: requirements change or new requirements are added
• And, these changes occur rapidly, challenging our ability to deal with the changes
• Fred Brooks cites changeability as one of the four "essential difficulties" that faces software development
  • The other three are complexity, conformity, and invisibility
• Software is under constant pressure to change, because our clients tend to think that all software change requests are equal
  • This does not occur in most other engineering disciplines because their products are tangible, unlike software
  • Consider the phases of building a house. Homeowners understand that making changes during the "blueprints" stage is easy. They know that their architect can make the change at relatively low cost
  • Likewise, homeowners understand that if they want to make a change after the foundation has been poured, that it gets much more expensive. Concrete has to be removed, and then new concrete has to be poured at great cost!
  • Software doesn't provide such affordances, a user can ask a developer to change the color of a UI element and ask that the software support multiple users in the same sentence without batting an eye!
    • As such, developers must work with clients to make them understand the severity of particular change requests
• Agile Design methods arose out of the needs to be able to handle rapid change in software development. Over the course of the semester, we'll look at how change impacts traditional software development and how Agile Methods attempts to mitigate those impacts

The Software Engineering Approach

• Our basic objective in software development is to achieve high quality and productivity
  • Our means for doing this is via people, processes, and technology, sometimes called the Iron Triangle
• So, for high quality and productivity, good tools need to be used, good processes and methods have to be used, and the people doing the job have to be properly trained
• Software Engineering tends to put a lot of focus on process (while also working on the other two)
  • We separate the process from the product it produces
  • An argument is made that a high quality process will help to produce a high quality product
  • As mentioned at the beginning of the lecture, its this focus on process that distinguishes software engineering from other computing disciplines

Phased Development Process

• All software development methods consists of multiple phases
• Each phase has a clear task and typically works to produce some sort of artifact (documents and/or code)
• The standard phases are:
  • Requirements Analysis: Understanding the Problem
    • Identifying WHAT is needed from the system, not HOW it will achieve its goals
  • Software Design: Finding a Solution to the Problem
    • Consists of architecture design, high-level design, and detailed design
  • Coding: Implementing the Solution to the Problem
    • The biggest challenge is fighting the impedance mismatch between design and implementation
  • Testing: Testing the Solution to the Problem
    • Thinking of testing as being confined to one phase is now antiquated
    • Modern life cycles encourage the use of testing throughout the process
  • Deployment: Delivering the Solution to the Customer
  • Maintenance: Dealing with the Operation and Evolution of the Software System

Managing the Process

• Project management plays a critical role in software development
  • Many a team of superstar developers have seen their projects fail due to poor management
• To aid in managing software development projects, software engineering has developed software metrics
• Software metrics are quantifiable measures that can be used to assess different characteristics of a software system or software process
  • There are two types of metrics, product and process, and both types provide information to managers about the state of a development process and the product that it is producing
  • These measures can be useful as they provide a source of objective data that can be used to assess the subjective reports being provided by developers and lower management
• We will take a look at some of the metrics that have been designed by the software engineering community, later in the semester

Summary

• Student Systems vs. Software Systems
• History of Software Engineering
• The Problem Domain
• Software Engineering Challenges
• The Software Engineering Approach

Coming Up Next

• Lecture 3: Overview of Concurrency
• Lecture 4: Software Process