Johns Hopkins University Software Engineering Fall 2002

1
Johns Hopkins UniversitySoftware
EngineeringFall 2002

• 17 September 2002
• Bill Akin

2
Tonights Agenda

• Review the semester schedule
• Discuss the group project
• Identify teams
• Discuss possible project topics
• Discuss next weeks proposal presentations
• Discuss a general overview of topics from the
  text to be discussed over the next several weeks

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 Deliver proposal document
• 5 8- Oct 14, 15, 16 Present requirements
  analysis
• 6 15-Oct 20, 21
• 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
Deliverables and Grading

• The final class grade will be 30 mid-term exam,
  30 final exam, and 40 project.
• I reserve the option to drop one or both of the
  exams and let the grade be based on the project
  only or the project and remaining exam.
• The project grade will be based on the grade of
  the team project with some additional
  consideration for individual student
  contributions.

5
Group Project (1)

• There will be a group project described in a
  separate paper.
• You will work as teams of about three people.
  Each team is expected to have regular meetings
  outside of class. We will also set aside time
  during some classes to have team meetings and to
  discuss project issues with the instructor.
• All work on the project is to be done as a team.
  Each team is responsible for organizing and
  dividing the work among its members.

6
Group Project (2)

• Material will be presented at the second class
  meeting outlining the approach to the group
  projects and guidelines for project deliverables.
  
• The project will involve a full life cycle
  development for a small computer system. This
  includes everything from requirements gathering
  and specification to a live classroom
  demonstration of the final product.

7
Pressman Chapter 1

• First, Lets flip through the book.
• Software includes
• Programs
• Documentation
• Data
• Writing programs is not scalable
• Maintenance begins almost immediately
• Products live longer than expected

8
Pressman Chapter 1

• Software doesnt wear out but it does deteriorate
  as it evolves over time
• Consider Figure 1.2 on page 8
• We may be able to approach the idealized curve if
  we are very careful and make few mistakes
• The actual curve will diverge over time if we
• Revise the original product to correct it or
• Modify the product over time
• Our goal is to economically minimize the
  divergence

9
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
10
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)

IEEE
11
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?

12
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
13
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.

14
Level 2 KPAs -- Repeatable

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

15
Level 3 KPAs -- Defined

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

16
Level 4 KPAs -- Managed

• Software quality management
• Quantitative process management

17
Level 5 KPAs -- Optimizing

• Process change management
• Technology change management
• Defect prevention

18
KPA Characteristics

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

19
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.

20
Lifecycle Models in Text

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

21
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.

22
Next Week

• Present project proposals
• Discuss chapter 1 6 details
• Relate material in the text to this weeks slides.