Johns Hopkins University Software Engineering Fall 2002

1
Johns Hopkins UniversitySoftware
EngineeringFall 2002

• 15 October 2002
• Bill Akin

2
Tonights Agenda

• Evaluate class schedule
• Review development models
• Introduce architectures
• Discuss use-cases
• Open discussion on requirements

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
• 6 15-Oct 20, 21 Deliver proposal document
• 7 22-Oct Present requirements analysis /
  models
• 8 29-Oct 22 Mid-Term Exam
• 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
Historical View

• Turning back the clock
• Code Fix
• Stagewise
• Transform This is
• valid today!

• Current Technology
• Waterfall
• Evolutionary (Incremental)
• Spiral
• Prototype
• COTS Integration Component -Based Development

5
Code and Fix

• Basic model used in the earliest days of software
  development
• Two steps write the code, fix problems in the
  code

• Problems
• Repeatedly fixing the same code leads to such
  poor structure that the code becomes
  unmaintainable
• Code typically does not meet user needs
• Code is hard to test because there is no
  preparation for testing

6
Stagewise

• Introduced in mid- 1950's
• Software developed in successive stages

• operational plan,
• operational specifications,
• coding specifications,
• coding,

• parameter testing,
• assembly testing,
• shakedown,
• system evaluation

7
Transform Model (1)

• Assumes the existence of a capability to
  automatically convert a specification of a
  software product into a program that satisfies
  the specification.
• Transform model eliminates the problem of
  "spaghetti code" because the code is regenerated
  to satisfy performance and user satisfaction
• Problems automatic transformation systems only
  available in a limited domain (some 4GL
  applications) reuse integration of COTS
  software is not supported

8
Transform Model (2)

• The model then follows five steps
• 1) Formally specify the desired product (initial
  understanding)
• 2) Automatically transform specification into
  code
• 3) Improve performance of code by input of
  optimization parameters to the transformation
  system (step 2)
• 4) Users exercise the resulting product
• 5) Adjust spec (and repeat steps) based on
  operational experience

9
Waterfall Model (1)

• Introduced as a refinement to the stagewise model
  in 1970
• Added feedback loops between steps (confined to
  successive steps)
• Added prototyping to support requirements
  analysis design
• The standard approach to SW development for 20
  years (has been the basis for most SW acquisition
  standards used in government and industry)

10
Waterfall Model (2)

• Criteria for selection
• System can be developed in less than 12 months
• Cannot practically break into builds (releases)
• The added cost of developing support SW
  (emulation, simulation, test) is more than 20 of
  total development cost
• The need for timely delivery of the entire system
  is the driver
• Problems
• Emphasis on elaborate documents as completion
  criteria does not work well for certain classes
  of SW (interactive, end-user applications)
• Doesn't work well for COTS SW integration

11
Evolutionary (Incremental Build)

• Subset of functionality developed and delivered
  (Build 0)
• Further functionality is added as subsequent
  builds
• Each build goes through a complete cycle of the
  tailored SW activities
• Development builds transition to maintenance
  builds
• Problems can create "spaghetti code" if
  components of early builds are continuously
  modified for later builds assumes that the
  user's operational system will be flexible enough
  to accommodate unplanned evolution paths (not
  always a valid assumption)

12
Spiral Model (1)

• Introduced in mid-1980's, based on experience
  with refinements to the Waterfall model
• Each cycle involves a progression that addresses
  the same sequence of steps for each portion of
  the product each level of elaboration
• Its range of options accommodates the good
  features of existing SW process models while its
  risk driven approach avoids many of their
  difficulties
• Focuses early attention on options involving SW
  reuse

13
Spiral Model (2)

• Focuses on eliminating errors and unattractive
  alternatives early
• Problems not applied extensively to contract
  software acquisition, relies heavily on
  risk-assessment expertise, not yet fully
  elaborated as the more established models

14
Prototyping (1)

• General characteristics
• Prototyping almost always part of a software
  development project
• Important for risk aversion and requirements
  analysis because it
• 1) helps customers identify what they want (they
  see the system)
• 2) helps make sure that potential problem areas
  have solutions
• 3) can provide the customer a quick, usable
  capability
• 4) provides checkpoints and demonstrates
  observable progress

15
Prototyping (2)

• Throwaway Prototype
• Used during early software engineering to
  pinpoint requirements
• Reduce risk by experimenting with different
  implementations
• Developed without respect to standards or future
  maintenance
• Discarded after preliminary design, requirements
  and algorithms survive

16
Software Process Models

• Software process models define the sequence of
  activities criteria for transitioning from one
  activity to the next
• A process model (evolutionary, prototype, spiral)
  differs from a methodology (structured analysis,
  object oriented design) in that methodologies
  define how to proceed through each step
  represent the products of each step
• Five process models are identified (as well as
  three models no longer used in the software
  industry

17
Prototyping (3)

• Evolutionary Prototype
• Becomes part of the delivered system
• Tailored development practices do apply
• Working Model Prototype
• Normally does not lead to a larger SW development
  effort
• Used to examine performance characteristics, HMI
  response, ...

18
COTS Integration

• Two decades ago...
• The only commercial software included in the
  typical software system was the operating system
  and even the OS was often modified to meet the
  needs of a specific project .
• Today...
• Customers expect the use of COTS software
  products whenever possible. Operating Systems,
  DBMS products, communications packages, graphical
  user interface products are typically an integral
  part of developed software systems. Integrators
  build systems with as much as 80 COTS. This
  reduces the cost of software development but
  increases the amount of integration required.
  Traditional software size cost estimation
  techniques do not adequately address this issue.

19
Definition from the SEI

• Software architecture
• the structure of the components of a
  program/system, their interrelationships, and
  principles and guidelines governing their design
  and evolution over time.

20
Operational Architecture (DoD)

• The operational architecture (OA) view is a
  description of the tasks and activities,
  operational elements,and information flows
  required to accomplish or support a military
  operation.
• It contains descriptions (often graphical) of the
  operational elements, assigned tasks and
  activities, and information flows required to
  support the warfighter. It defines the types of
  information exchanged, the frequency of exchange,
  which tasks and activities are supported by the
  information exchanges, and the nature of
  information exchanges in detail sufficient to
  ascertain specific interoperability requirements.

21
Technical Architecture (DoD)

• The technical architecture (TA) view is the
  minimal set of rules governing the arrangement,
  interaction, and interdependence of system parts
  or elements, whose purpose is to ensure that a
  conformant system satisfies a specified set of
  requirements.
• The technical architecture view provides the
  technical systems implementation guidelines upon
  which engineering specifications are based,
  common building blocks are established, and
  product lines are developed. The technical
  architecture view includes a collection of the
  technical standards, conventions, rules, and
  criteria organized into profile(s) that govern
  system services, interfaces, and relationships
  for particular systems-architecture views and
  that relate to particular operational views.

22
Systems Architecture (DoD)

• The systems architecture (SA) view is a
  description, including graphics, of systems and
  interconnections providing for, or supporting,
  warfighting functions. For a domain, the systems
  architecture view shows how multiple systems link
  and interoperate, and may describe the internal
  construction and operations of particular systems
  within the architecture. For the individual
  system, the systems architecture view includes
  the physical connection, location, and
  identification of key nodes (including
  materiel-item nodes), circuits, networks,
  warfighting platforms, etc., and it specifies
  system and component performance parameters
  (e.g., mean time between failure,
  maintainability, availability).
• The systems architecture view associates physical
  resources and their performance attributes to the
  operational view and its requirements following
  standards defined in the technical architecture.

23
Relationships Among the DoD Views
24
Brief Discussion and Reference
Use Cases

• The following slides are extracted from a larger
  set I found on the web. The slides are freely
  shared by the site.
• These slides give us a brief introduction to the
  concept of USE-CASES.
• For further information, the web address is
  www.Object-Ideas.com

25
Use Cases
26
Use Cases
27
Use Cases
28
Use Cases
29
Use Cases
30
Use Cases
31
Use Cases
32
Use Cases
33
Use Cases
34
Use Cases
35
Use Cases
36
Use Cases
37
Use Cases
38
Use Cases
39
Use Cases
40
Use Cases
41
Use Cases
42
Use Cases
43
Use Cases
44
Use Cases
45
Use Cases
46
Use Cases
47
Use Cases
48
Use Cases
49
Use Cases
50
Use Cases
51
Use Cases
52
Use Cases
53
Use Cases
54
Use Cases
55
Use Cases
56
Use Cases
57
Use Cases
58
Use Cases
59
Use Cases
60
Use Cases
61
Use Cases
62
Use Cases
63
Use Cases
64
Use Cases
65
Use Cases
66
Use Cases
67
Use Cases
68
Use Cases
69
Use Cases
70
Use Cases
71
Use Cases
72
Use Cases
73
Use Cases
74
Use Cases
75
Use Cases
76
Use Cases
77
Use Cases
78
Use Cases
79
Use Cases
80
Use Cases
81
Use Cases
82
Use Cases
83
Use Cases
84
Use Cases
85
Use Cases
86
Use Cases
87
Use Cases
88
Use Cases
89
Use Cases
90
Use Cases
91
Use Cases
92
Use Cases
93
Use Cases
94
Use Cases
95
Open Discussion on Requirements