Johns Hopkins University Software Engineering Fall 2002

1
Johns Hopkins UniversitySoftware
EngineeringFall 2002

• 24 September 2002
• Bill Akin

2
Tonights Agenda

• Review the semester schedule
• Present project proposals
• Discuss chapter 1 6 details
• Relate material in the text to previous weeks
  slides.

3
Schedule

• Class Date Chapters Events and Deliveries
• 1 10-Sep Overview
• 2 17-Sep 1, 2, 3, 4 Project and team
  organization
• 3 24-Sep 5, 6 Present team project proposals
• 4 1-Oct 10, 11, 12, 13
• 5 8- Oct 14, 15, 16 Deliver proposal document
• 6 15-Oct 20, 21 Present requirements analysis
• 7 22-Oct Mid-Term Exam
• 8 29-Oct 22 Present analysis models
• 9 5-Nov Deliver requirements document
• 10 12-Nov 7, 8, 9, 19, 24 High Level Design
  Presentation
• 11 19-Nov 17, 18, 23 Deliver high level design
  document
• 12 26-Nov Part Five Topics
• 13 3-Dec Project Demonstrations - Deliver
  project
• 14 10-Dec Final Exam

4
Pressman Chapter 1 -- Myths

• Myth -- We have a book of standards containing
  everything our software development staff needs.
• Reality Is the book used? Does the staff know
  about it? Is it current? Is it easy to use? Is
  the staff trained to use it? Does management
  require its adherence?

5
Pressman Chapter 1 -- Myths

• Myth We have state of the art tools, after all,
  we buy the latest computers.
• Reality It takes more that hardware to develop
  software. Software engineering uses such things
  as case tools and structured processes to control
  development of quality software. In fact, I
  believe the processes are more important than the
  tools.

6
Pressman Chapter 1 -- Myths

• Myth If we get behind we can just add
  programmers.
• Reality This is a statement of the mythical
  man-month concept exposed by Fred Brooks.

7
Pressman Chapter 1 -- Myths

• Myth If we outsource, we can relax and await
  completion of the project.
• Reality Last week I mentioned that one of the
  CMM KPAs relates to subcontract management. It
  requires a lot of management, even with the best
  contractor and best subcontractor.

8
Pressman Chapter 1 -- Myths

• Myth A general statement of objectives is
  sufficient to begin writing programs.
• Reality This belief is one of the reasons we
  teach software engineering. Quoting Fred Brooks
  again, The hardest single part of building a
  software system is deciding what to build.No
  other part of the work so cripples the resulting
  system if done wrong. No other part is more
  difficult to rectify later.

9
Pressman Chapter 1 -- Myths

• Myth Project requirements continually change,
  but change is easy because software is flexible.
• Reality In the aerospace and defense industries
  and other multi-disciplined environments, people
  often jokingly say, Dont worry about that now
  we can fix it later with software.

10
Pressman Chapter 1 -- Myths

• Myth Once we write programs and get them to
  work, our job is done.
• Reality The sooner you begin to write code the
  longer it will take you to get done.
  Historically, 60 to 80 percent of software effort
  comes after the product is delivered.

11
Pressman Chapter 1 -- Myths

• Myth Until I get the software to run, I cant
  assess the quality.
• Reality Formal review is far more effective
  than testing to catch defects.

12
Pressman Chapter 1 -- Myths

• Myth The only necessary deliverable in a
  software project is the working program.
• Reality This one is dangerous. During the
  semester we will examine the utility of several
  documents and other artifacts that should be
  delivered with a software product.

13
Pressman Chapter 1 -- Myths

• Myth Software engineering will make us create
  voluminous and unnecessary documentation and will
  invariably slow us down..
• Reality This one is the mother of all myths.
  It is the most common misconception. For
  organizations that dont understand and control
  their software engineering process, this may
  actually be true. But, they are doomed to
  failure anyway for anything much more than the
  development of a simple, single use program.

14
Pressman Chapter 2

• Software Engineering is the establishment and
  use of sound engineering principles in order to
  obtain economically software that is reliable and
  works efficiently on real machines.

Circa 1969
Economical acquisition Reliable
software Efficient software
Sound engineering principles gt
15
Definition

• Software Engineering
• The application of a systematic, disciplined,
  quantifiable approach to the development,
  operation, and maintenance of software, that is,
  the application of engineering to software
• The study of approaches as in (1)

Circa 1993
IEEE
16
Engineering
Engineering is the analysis, design,
construction, verification, and management of
technical (or social) entities. Regardless of
the entities, the following questions must be
asked and answered.

• What is the problem to be solved?
• What characteristics of the entity are used to
  solve the problem?
• How will the entity (and the solution) be
  realized?
• How will the entity be constructed?
• What approach will be used to uncover errors that
  were made in the design and construction of the
  entity?
• How will the entity be supported over the long
  term, when corrections, adaptations, and
  enhancements are requested by users of the entity?

17
Process Maturity

• The SEI defines five levels of capability
  maturity for software development organizations
  and provides models for each. The levels are
  called
• Initial (often called Chaos)
• Repeatable
• Defined
• Managed
• Optimizing

SEI CMM Levels
18
Key Process Areas (KPAs)

• The SEI model defines a set of KPAs for each
  level, e.g., Project Planning.
• Each level includes all the KPAs from previous
  levels plus new ones added to achieve the current
  level.
• For each KPA there is a defined set of
  characteristics defined.

19
Level 2 KPAs -- Repeatable

• Software configuration management
• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management

20
Level 3 KPAs -- Defined

• Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process function

21
Level 4 KPAs -- Managed

• Software quality management
• Quantitative process management

22
Level 5 KPAs -- Optimizing

• Process change management
• Technology change management
• Defect prevention

23
KPA Characteristics

• Goals
• Commitments
• Abilities
• Activities
• Methods for monitoring implementation
• Methods for verifying implementation

24
Software Lifecycle

• A software lifecycle has three basic phases
• Definition phase focuses on What
• Development phase focuses on How
• Support phase focuses on Change
• The change phase addresses
• Correction Corrective maintenance
• Adaptation Adaptive maintenance
• Enhancement Perfective maintenance
• Prevention Preventative maintenance

25
Software Lifecycle Models

• All software lifecycle models must address, at a
  minimum, the following elements
• Software requirements analysis
• Design
• Code generation
• Testing
• Support
• Each model provides an approach to organizing
  and executing the elements.

26
Simple Linear Sequential (Waterfall) Model
Analysis
Design
Code
Test
27
Rapid Application Development aka component-based
development
RAD and CBD are both discussed in Chapter 1.
Take these discussions with a grain of salt.
Business Modeling
Data Modeling
Process Modeling
Application Generation
This cycle is repeated for each component of a
system to be developed.
Testing Turnover
28
The Incremental Model
Analysis
Design
Code
Test
Analysis
Design
Code
Test
Be careful with this one, too. It is a very
important modern approach requiring good systems
engineering.
Analysis
Design
Code
29
Spiral Model

• Each iteration of the spiral provides a more
  complete version of the system.
• Each delivered version is a replacement for the
  previous version, built on that previous version
  as a baseline.
• By comparison, the incremental model usually
  delivers additive elements to the previous
  version.
• These are often built in parallel.

30
Lifecycle Models in Text

• Prototyping
• Rapid application development (RAD)
• Evolutionary
• Incremental
• Spiral
• WINWIN Spiral
• Concurrent development
• Component-based development
• Formal methods

31
Pressman Chapter 3

• Ive visited dozens of commercial shops, both
  good and bad, and Ive observed scores of data
  processing managers, again, both good and bad.
  Too often, Ive watched in horror as these
  managers futilely struggled through nightmarish
  projects, squirmed under impossible deadlines, or
  delivered systems that outraged their users and
  went on to devour huge chunks of maintenance
  time.

Page-Jones
32
Project Management Concepts

• Management Spectrum
• People
• Product
• Process
• Project
• Boehms W5HH Principle (There he goes again!)
• Critical Practices

33
Management Spectrum

• The spectrum of management focuses on
• People Skilled and motivated software people
• Product A vision of scope, objectives, and
  alternate solutions
• Process A framework for a comprehensive
  software development plan can be established
• Project a planned and controlled software
  project
• Each of these is expanded in the chapter.

34
People

• Players (Project Stakeholders) membership
  includes senior managers, project managers,
  practitioners, customers, and end-users.
• Team leaders require motivation, organization,
  ideas or innovation, problem solving skills,
  managerial identity, achievement, and influence
  and team building skills.
• Software team may be democratic decentralized,
  controlled decentralized, or controlled
  centralized.
• Coordination and communication issues
  techniques include formal impersonal, formal
  interpersonal, and informal interpersonal
  approaches and procedures

35
Product

• Software scope
• Context
• Information objectives
• Function and performance
• Problem decomposition
• Systems engineering
• Problem partitioning
• Requirements allocation
• Divide and conquer strategy

36
Process

• Select and elaborate a software development
  process model
• Establish a framework to meld the product to the
  process. The framework must address customer
  communication, planning, risk analysis,
  engineering, construction and release, and
  customer evaluation.
• Decompose the process into small, well-defined,
  manageable and measurable pieces.

37
Project Bad Karma

• Software people dont understand their customers
  needs
• Product scope is poorly defined
• Changes are managed poorly
• Chosen technology changes
• Business needs change or are ill-defined

• Deadlines are unrealistic
• Users are resistant
• Sponsorship is lost or was never properly
  obtained
• Project team lacks people with appropriate skills
• Managers and practitioners avoid best practices
  and lessons learned

38
Project Commonsense Approach

• Start on the right foot
• Maintain momentum
• Track progress
• Make smart decisions
• Conduct a postmortem analysis

39
Boehms W5HH Principle

• Why is the system being developed establish the
  need, the concept, and justification with a
  cost-benefits analysis.
• What will be done, by when develop a work
  breakdown structure and a schedule.
• Who is responsible for a function establish
  staff structure and assign tasks

40
Boehms W5HH Principle

• Where are they organizationally located
  identify authority, roll, and organization for
  all responsible players
• How will the job be done technically and
  managerially develop a project plan and a
  project management plan
• How much of each resource is needed conduct a
  cost estimate analysis

41
Critical Practices

• The author provides a list of critical practices
• Formal risk management
• Empirical cost and schedule estimation
• Metric-based project management
• Earned value tracking
• Defect tracking against quality targets
• People-aware program management

42
Measures and Metrics

• Measure (n) the dimensions, capacity, or amount
  of something ascertained by measuring.
• Metric (n) A standard of measurement, e.g., No
  metric exists that can be applied directly to
  happiness.
• In general, a measure is a value you compare
  against a metric.

43
Product Measures and Metrics

• Measure How many comments per 100 lines of code
  are in this module? Someone counts the lines of
  code and the number of comments and derives the
  measure of 27.4 comments per 100 lines.
• Metric The number of comments per 100 lines of
  code should be between 4 and 10.
• Our measure is out of range.

44
Metric Derivation Indicators

• Take measurements over many similar projects.
• Correlate the measures to some quality goal or
  objective.
• Determine a value or set of values in the
  measures that tend to indicate good quality goals
  or objectives.
• From these values establish a metric.
• Beware of false conclusions.

45
Process Metrics Measures

• Measure How many errors per hour are found
  during code reviews? The scribe in a code review
  polls all reviewers and asks how many errors were
  found by each and how long each reviewer spent in
  the review. The numbers are recorded.
• Metrics are established using many reviews and
  compared to the measures for each review.
• This metric has at least one obvious flaw.

46
Project Metrics

• The number should be limited.
• The value must be maximized.
• The selection must be relevant.
• Be sure the metrics continue to be good
  indicators. Some metrics will change depending
  on people, approaches, etc.
• Do not be bogged down or misled by your own
  measures.

47
Indications from Measures

• Each kind of metric can be applied toward a given
  set of goals or objectives. Examples
• Comments per 100 lines of code may indicate a
  level of maintainability.
• The McCabe complexity is considered to be a good
  indicator of module maintainability, especially
  if maintenance is to be performed by someone
  besides the developer.

48
Estimating Using Metrics

• Cost, resources, schedule, and other quantities
  must be predicted for most projects before
  approval is given to begin.
• Estimation variables are measures fed to models
  to scope projects. They include lines of code
  (LOC), function points (FP), and object points
  (OP).
• Derived metric values drive the model.

49
Proposal document

• I encourage you to get this out of the way as
  soon as you can. We need to allow another week
  because of the delays getting started.
• All documents should have at least the following
  main components
• Cover sheet
• Front matter
• Body
• Support documentation (if any)

50
Cover sheet

• Cover sheet should name the document, its target,
  its environment or organization, and its
  author(s)
• It should be dated and have a version number if
  there are revisions.
• A cover sheet should not have printed page
  numbering or header and footer sections

51
Front matter

• Front matter can include an abstract, a table of
  contents and other tables such as a table of
  figures or list of tables. It may also include a
  document revision history.
• The front matter section should be numbered with
  lower-case Roman numerals
• The cover page is page I even though it is not
  printed

52
Body

• The body begins with an introductory section that
  usually begins with a summary and includes a
  purpose, scope, background, approach, etc.
• Numbering begins with page 1 using Arabic
  numerals.
• Major sections follow the introduction broken
  into logical and manageable chunks.

53
Support Documentation

• The support documentation is kept in appendices
  out of the main body
• Items include such things as a list of
  abbreviations or acronyms, references, and any
  other items placed here for the convenience of
  the reader, for example a document that discusses
  software capability maturity might have an
  attached description of the SEI CMM levels and a
  discussion of the KPAs.

54
Next Week

• Complete project proposals
• Delay proposal delivery another week
• Continue with chapters in the text
• 5, 6 will be covered next week
• As much of 10, 11, 12, and 13 as we can
• We may introduce all these chapters and finish
  some of the details the following week.