Johns Hopkins University Software Engineering Fall 2002

1
Johns Hopkins UniversitySoftware
EngineeringFall 2002

• 1 October 2002
• Bill Akin

2
Tonights Agenda

• Material taken from chapters 5, 6, 10, 11, 12,
  and 13 with some additional information on topics
  covered
• Fourth Team Presentation
• Proposal Document Discussion
• Documentation and Microsoft Word

3
Schedule

• Class Date Chapters Events and Deliveries
• 1 10-Sep Overview
• 2 17-Sep Project and team organization
• 3 24-Sep 1, 2, 3, 4 Present team project
  proposals
• 4 1-Oct 5, 10, 11
• 5 8- Oct 12, 13, 14, 15 Deliver proposal
  document
• 6 15-Oct 16, 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 6, 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
Overview

• Chapter 5 Software Project Planning
• Chapter 6 Risk Analysis and Management
• Chapter 10 System Engineering
• Chapter 11 Analysis Concepts and Principles
• Chapter 12 Analysis Modeling
• Chapter 13 Design Concepts and Principles

5
Chapter 5 -- Software Project Planning

• Observations on estimating
• Project planning objectives
• Software scope
• Resources
• Software project estimation
• Decomposition techniques
• Empirical estimation models
• Make or buy decision
• Automated estimation tools

6
Project Scheduling Tracking

• Microsoft sells a product called Project.
• It provides the facility to produce, track, and
  modify a project schedule.
• Microsoft Project does not produce or modify a
  project plan. This is a little understood fact
  among most Project users.
• A project schedule begins with an initial set of
  interrelated tasks.
• Project lets one to place the tasks into a
  schedule.
• This is important to those who do project
  scheduling and tracking as well as those who use
  Project.

7
Observations on estimating

• Define and scope the problem
• Provide initial tasking and estimates
• Manage customer and staff expectations
• Continuously improve estimates
• Continuously update project plan
• Continuously evaluate and reduce uncertainty

8
Project planning objectives

• Provide a framework to make reasonable estimates
  of
• Resources,
• Cost, and
• Schedule
• Estimates are made at beginning of project
• Estimates are updated regularly

9
Software scope

• Bound the project get your arms around it
• Determine what function and performance are
  allocated to software through system engineering
  (Chapter 10)
• First cut should address data, control, function,
  performance, constraints, interfaces, and
  reliability
• Initial project analysis

10
Software scope

• Identify stakeholders
• Identify users
• Establish benefits
• Examine alternative solutions
• Identify solution environment
• Establish and maintain continuous and iterative
  discussion with appropriate stakeholder
  representatives

11
Software scope

• Determine feasibility
• Can we build this
• Is the project feasible
• Four feasibility dimensions
• Technology
• Finance
• Time
• Resources

12
Resources

• Do we have the tools
• Facilities and hardware
• Software
• Environment
• Do we have components
• Reusable components and subsystems including
  COTS
• Class and subroutine libraries
• Do we have the people
• Skill
• Availability

13
Software project estimation

• Yesterday Huge, expensive computers with a few
  programs
• Today Variety of reasonably priced hardware
  components and complex software elements
• Emerging -- Variety of reasonably priced hardware
  components and vast repositories of reusable
  software elements

14
Software project estimation

• Wait until later to get better estimates some
  of this must be done how much can we tolerate
• Make estimates based on prior performance on
  similar projects note bottom of page 123 is
  misleading experience is needed for next two
  options
• Use decomposition techniques to generate project
  cost and effort estimates
• Use empirical models d f(vi), where d is
  element to be estimated, vi is a set of
  independent parameters and f is a function

15
Decomposition techniques

• Divide and conquer technique
• Large problems are too hard to solve
• Break them into a collection of smaller problems
  repeat until solvable
• How can we tell how much work, time, people, etc.
  will be needed to solve the little problems we
  have solved little problems before and we took
  measurements

16
Empirical estimation models

• CoCoMo E B x (ev)C
• CoCoMo II E A B x (ev)C
• E is the thing being estimated e.g, cost,
  duration, manpower
• A, B, and C are constants derived from previous
  experience on similar work
• ev is the estimation value e. g., function
  points, source lines of code, object points

17
Make or buy decision

• Purchase system, subsystem, components, or
  libraries
• Incorporate with tailoring current system,
  subsystem, components, or libraries
• Build from whole cloth
• What will tailoring cost
• What requirements wont be met
• What control will be lost

18
Automated estimation tools

• Automated tools are available to
• Size project deliverables
• Select project activities
• Predict staffing levels
• Predict software effort
• Predict software cost
• Predict software schedules

19
Chapter 10 -- Systems Engineering

• The role of a systems engineer is to define the
  elements for a specific computer-based system in
  the context of the overall hierarchy of systems
  (macro elements).
• Systems engineers define the elements of a system
  to be developed from a specific set of
  requirements and within the confines of a
  particular architecture.
• They define the interfaces between the system
  elements and define the processes they perform.

20
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?

21
Engineering

• System -- A set or arrangement of elements that
  are organized to accomplish some predefined goal
  by processing information
• Computer-based systems comprise
• Software
• Hardware
• People
• Data stores
• Documentation
• Procedures

22
Systems Engineering

• Systems engineers must provide a mapping from a
  specific problem space to a selected solution
  space.
• The problem space is the collection of
  requirements that defines the desired system.
• The solution space is the collection of elements,
  interfaces, and processes that define a system to
  be built that completely and correctly satisfies
  all the requirements in the problem space.

23
Systems Engineering

• Defining a system in the solution space is called
  system modeling.
• The engineer creates models that
• Define the processes that serve the needs of the
  view under construction
• Represent the behavior of the processes and the
  assumptions on which the assumptions are based
• Explicitly define both exogenous and endogenous
  input to the model and
• Represent all linkages (including output) that
  will enable the engineer to better understand the
  view

24
Systems Engineering

• DoD architecture approach
• Capture the operational view
• Identify the technical environment
• Map the operational onto the technical to form
  the system view
• Business process engineering ? product
  engineering
• Implement within environmental constraints

25
Systems Engineering

• The outcome of the system engineering process is
  the specification of a computer-based system or
  product at different levels.
• In other words, systems engineering is applied
  hierarchically and recursively to produce a model
  and specification for each hierarchical level.

26
Systems Engineering

• 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.
• This understated quote from Fred Brooks is the
  reason systems engineering is needed.

Fred Brooks
27
Systems Engineering

• From this point discussions in the text (and
  among folks everywhere who define or are involved
  in the practice of software engineering) begin to
  define elements of the process and sub-elements,
  placing them under various headings. There are,
  of course, standards. Unfortunately there are
  many of them. We will play along.

An aside comment
28
Systems Engineering

• In Chapter 10 Systems Engineering there are two
  major process areas defined in sections 10.5 and
  10.6. These sections discuss Requirements
  Engineering and System Modeling.
• Many people dont consider requirements
  engineering to be part of systems engineering.
  Others define systems engineering to include that
  and much more.

29
Requirements Engineering

• Requirements engineering can be described in
  distinct steps
• Requirements elicitation,
• Requirements analysis and negotiation,
• Requirements specification,
• System modeling (in the problem space),
• Requirements validation, and
• Requirements management.

30
Requirements Engineering

• Elicitation
• Find out from customer what is to be accomplished
• Determine how the product will fit the needs of
  the business
• Figure out how the product will be used each day

31
Requirements Engineering

• Requirements analysis and negotiation
• Categorize and organize requirements
• Relate each requirement to the rest
• Check for consistency, omissions, and ambiguity
• Rank based on customer needs

32
Requirements Engineering

• Requirements specification
• Beware of the first paragraph in section 10.5.3
  of the text these may not all be specifications
• Also notice two terms are used Requirements
  Specification and System Specification
• A specification is an unambiguous, objective
  statement
• A specification is also a collection of
  specification statements

33
Requirements Engineering

• Requirements validation
• Its not a requirement until the customer says
  its a requirement
• Validation is the stamp of approval on a
  requirements specification
• A successful validation is achieved when
• The customer completely understands each
  requirement in the specification
• The customer knows of no unspecified requirement
• The analyst and customer have the same
  understanding

34
Requirements Engineering

• Requirements management
• The initial requirements specification is a
  baseline
• Minds get changed new ideas arise
• Requirements nearly always change
• Change must be controlled
• Proposed changes to requirements must be stated
  as changes to requirements specifications they
  must be analyzed for correctness and consistency
• Each approved version is a new baseline

35
System Modeling

• Create a model of system capabilities (Were
  still in the problem space.)
• Model should represent
• Input,
• Processing,
• Output,
• User interface, and
• Maintenance.

36
System Modeling

• Modeling should be recursive and hierarchical.
• For most models the top level view is called the
  context view.
• The context view depicts the system in the
  context of its environment, including external
  entities that directly interface and interact
  with the system.

37
System Model Template

• The model in Figure 10.5 can be viewed as a
  schematic for models.
• Models take different forms but generally address
  the same basic features.
• Most classic models do not separate the user
  interface and maintenance views. These can be
  viewed as input, output, and/or process functions.

38
System Context Diagram

• The context diagram in Figure 10.6 depicts a
  particular instance.
• It shows the system needed in the processing
  pane, the barcode reader and conveyor line in the
  input pane the sorting station operator in the
  user interface pane, the sorting mechanism and
  mainframe in the output pane, and repeats the
  sorting station operator in the maintenance pane.

39
System Flow Diagram (SFD)

• Pressman calls the the drawing in Figure 10.7 the
  system flow diagram.
• This figure expands the context diagram by
  decomposing the single system in the processing
  pane into all its constituent subsystems.
• The flows between elements are expanded only as
  necessary to include all the major interfaces at
  this level.

40
SFD Hierarchy

• Figure 10.8 indicates how the process of
  decomposition can be applied for each processing
  block in the next higher level view.
• At this point it is easy to fall into the trap of
  assuming the blocks will become subsystems.
  Remember, were still in the problem space.

41
Data Flow Diagram Example

• Suppose E-Bay had pockets that were not as deep
  and couldnt afford such great computer systems.
  Build a system to archive less active buyers and
  sellers.
• Dream up some archiving functions, depict the
  context level diagram and at least one further
  decomposed diagrams.

42
Context DFD (Level 0)
Auction System
E-Bay Archive System
Seller System
Buyer System
Rating System
43
E-Bay Archive System (Level 1)
1
Sales Archiving
3
Customer Archiving
Ratings Archiving
5
4
6
7
2
Archives
44
Problem Space Models

• The models capture the view of the functions to
  be performed by the system.
• It is more likely that solution space groupings
  lie along common computer functions than along
  common user functions.
• For example, user interface activities or data
  management functions may be grouped.

45
Chapter 11 -- Analysis Concepts and Principles

• Notice that Pressman Chapter 11 begins with
  analysts studying systems specifications.
• In the previous chapter he said requirements
  engineers, sometimes called analysts, completed
  their work by delivering systems specifications.
• This is not really a contradiction. He simply
  distinguishes between requirements analysts and
  systems analysts. I usually dont.

46
Software Requirements Analysis

• Software requirements analysis bridges the gap
  between system requirements engineering and
  software design.
• Software requirements analysis is divided into
• Problem recognition,
• Evaluation and synthesis,
• Modeling,
• Specification, and
• Review

47
Requirements Engineering

• The problem space provides a living definition of
  the problem a system is required to solve.
• The process of requirements engineering defines
  and maintains the problem space and provides
  consistent views of it to a well defined
  community of stakeholders with diverse needs.

48
Requirements Engineering

• Stakeholders who must view and understand the
  problem definition (i.e., the system
  requirements) include those who must
• Acquire the system,
• Build the system,
• Maintain the system,
• Test the system, and
• Many others we could list

49
Requirements Engineering

• The requirements engineering process must gather,
  specify, validate, and maintain requirements.
• The entire collection of requirements must remain
  consistent, correct, and valid throughout the
  life of the defined problem space.
• There may be multiple versions of the problem
  space at any point in time.

50
Requirements Elicitation

• Learn from the stakeholders about the problem the
  system is to solve.
• Listen carefully and capture every idea from each
  person who will share his or her vision.
• Record everything even though some inputs may
  conflict with others.
• Get only enough to help you understand what is
  required. Youll be back for details and
  clarification later.

51
Elicitation Steps

• Assess feasibility
• Identify contributors
• Define environment
• Identify domain constraints
• Define elicitation methods
• Solicit participation
• Identify requirements prototyping candidates
• Create usage scenarios

52
Elicitation Products

• Statement of need and feasibility
• Bounded statement of system scope
• List of customers, users, and other stakeholders
• Description of systems technical environment
• List of requirements and domain constraints
• Set of usage scenarios
• Any prototypes developed

53
Requirements Analysis and Negotiation

• Systems engineers take possession of emerging and
  evolving artifacts.
• The systems engineering process becomes the
  customer of the requirements engineering process.
• Systems analysts still perform refinement of the
  products they have delivered.
• Systems analysts deliver a validated, living
  requirements specification.

54
Analysts Must Determine

• Are requirements consistent with objectives?
• Are specifications at the appropriate level?
• Is each requirement necessary or enhancement?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution?
• Are there conflicts between any requirements?
• Is each requirement achievable in environment?
• Is each requirement testable, once implemented?

55
Requirements Specification

• Pressman System Specification is the final work
  product of the system and requirements engineer.
• In almost all descriptions of the systems
  engineering process, systems engineers define the
  high level design of the system and allocate
  requirements to the various subsystems for
  further development.

56
Requirements Specification

• I would agree that the final work product of the
  requirements engineers, usually called analysts,
  is the requirements specification.
• The requirements specification, in whatever form,
  completely captures the problem space including
  functional capabilities, performance
  requirements, and operational and developmental
  constraints.
• It is a living document, subject to change.

57
Requirements Specification

• A requirements specification defines a view of
  the problem space. It does not always define a
  particular system to be built.
• A given system, version of a system, or release
  of a version of a system should satisfy a subset
  of the problem space defined by the requirements
  specification.
• The subset that specifies a certain system is
  called a requirements baseline.

58
Requirements Validation

• In addition to the ultimate system user, others
  have a stake in the requirements specification.
• All stakeholders should validate the requirements
  specification to be sure the requirements are
  unambiguous, consistent, complete, correct, and
  compliant.
• Important stakeholders include testers,
  developers, managers, etc.

59
Requirements Management

• Every version of the requirements specification
  must be submitted to software configuration
  management (SCM) -- often just called CM.
• Additions, changes, and deletions to requirements
  must be done through a controlled process and
  submitted to CM.
• Requirements baselines must be identified.

60
Use-Cases

• Scenarios that describe the use of a system to
  solve the problem notice that we are still in
  the problem space
• Actors are people or identifiable entities that
  use the system or one of its elements
• Roles are activities in which an actor may engage
  during a scenario
• By next week, find some resources on use-cases
  and be prepared to discuss them in class and use
  them on your project.

61
Next Week

• Deliver proposal documents
• Continue with Chapters 12, 13, 14, and 15
• Discuss requirements analysis presentation