COSC 4406 Software Engineering

1
COSC 4406Software Engineering
Haibin Zhu, Ph.D. Dept. of Computer Science and
mathematics, Nipissing University, 100 College
Dr., North Bay, ON P1B 8L7, Canada,
haibinz_at_nipissingu.ca, http//www.nipissingu.ca/fa
culty/haibinz
2
Lecture 4Practice and System EngineeringRef.
Chapter 5-6
3
What is Practice?

• Practice is a broad array of concepts,
  principles, methods, and tools that you must
  consider as software is planned and developed.
• It represents the detailsthe technical
  considerations and how tosthat are below the
  surface of the software processthe things that
  youll need to actually build high-quality
  computer software.

4
The Essence of Practice

• George Polya, in a book written in 1945 (!),
  describes the essence of software engineering
  practice
• Understand the problem (communication and
  analysis).
• Plan a solution (modeling and software design).
• Carry out the plan (code generation).
• Examine the result for accuracy (testing and
  quality assurance).
• At its core, good practice is common-sense
  problem solving

5
Core Software Engineering Principles

• Provide value to the customer and the user
• KISkeep it simple!
• Maintain the product and project vision
• What you produce, others will consume
• Be open to the future
• Plan ahead for reuse
• Think!

6
Software Engineering Practices

• Consider the generic process framework
• Communication
• Planning
• Modeling
• Construction
• Deployment
• Here, well identify
• Underlying principles
• How to initiate the practice
• An abbreviated task set

7
Communication Practices

• Principles
• Listen
• Prepare before you communicate
• Facilitate the communication
• Face-to-face is best
• Take notes and document decisions
• Collaborate with the customer
• Stay focused
• Draw pictures when things are unclear
• Move on
• Negotiation works best when both parties win.

8
Communication Practices

• Initiation
• The parties should be physically close to one
  another
• Make sure communication is interactive
• Create solid team ecosystems
• Use the right team structure
• An abbreviated task set
• Identify who it is you need to speak with
• Define the best mechanism for communication
• Establish overall goals and objectives and define
  the scope
• Get more detailed
• Have stakeholders define scenarios for usage
• Extract major functions/features
• Review the results with all stakeholders

9
Planning Practices

• Principles
• Understand the project scope
• Involve the customer (and other stakeholders)
• Recognize that planning is iterative
• Estimate based on what you know
• Consider risk
• Be realistic
• Adjust granularity as you plan
• Define how quality will be achieved
• Define how youll accommodate changes
• Track what youve planned

10
Planning Practices

• Initiation
• Ask Boehms questions
• Why is the system begin developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they located (organizationally)?
• How will the job be done technically and
  managerially?
• How much of each resource is needed?

11
Planning Practices

• An abbreviated task set
• Re-assess project scope
• Assess risks
• Evaluate functions/features
• Consider infrastructure functions/features
• Create a coarse granularity plan
• Number of software increments
• Overall schedule
• Delivery dates for increments
• Create fine granularity plan for first increment
• Track progress

12
Modeling Practices

• We create models to gain a better understanding
  of the actual entity to be built
• Analysis models represent the customer
  requirements by depicting the software in three
  different domains the information domain, the
  functional domain, and the behavioral domain.
• Design models represent characteristics of the
  software that help practitioners to construct it
  effectively the architecture, the user
  interface, and component-level detail.

13
Analysis Modeling Practices

• Analysis modeling principles
• Represent the information domain
• Represent software functions
• Represent software behavior
• Partition these representations
• Move from essence toward implementation
• Elements of the analysis model (Chapter 8)
• Data model
• Flow model
• Class model
• Behavior model

14
Design Modeling Practices

• Principles
• Design must be traceable to the analysis model
• Always consider architecture
• Focus on the design of data
• Interfaces (both user and internal) must be
  designed
• Components should exhibit functional independence
• Components should be loosely coupled
• Design representation should be easily understood
• The design model should be developed iteratively
• Elements of the design model
• Data design
• Architectural design
• Component design
• Interface design

15
Construction Practices

• Preparation principles Before you write one line
  of code, be sure you
• Understand of the problem youre trying to solve
  (see communication and modeling)
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs
  of the software to be built and the environment
  in which it will operate.
• Select a programming environment that provides
  tools that will make your work easier.
• Create a set of unit tests that will be applied
  once the component you code is completed.

16
Construction Practices

• Coding principles As you begin writing code, be
  sure you
• Constrain your algorithms by following structured
  programming BOH00 practice.
• Select data structures that will meet the needs
  of the design.
• Understand the software architecture and create
  interfaces that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them
  easily testable.
• Select meaningful variable names and follow other
  local coding standards.
• Write code that is self-documenting.
• Create a visual layout (e.g., indentation and
  blank lines) that aids understanding.

17
Construction Practices

• Validation Principles After youve completed
  your first coding pass, be sure you
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors youve
  uncovered.
• Refactor the code.

18
Construction Practices

• Testing Principles
• All tests should be traceable to requirements
• Tests should be planned
• The Pareto Principle applies to testing
• Testing begins in the small and moves toward
  in the large
• Exhaustive testing is not possible

19
Deployment Practices

• Principles
• Manage customer expectations for each increment
• A complete delivery package should be assembled
  and tested
• A support regime should be established
• Instructional materials must be provided to
  end-users
• Buggy software should be fixed first, delivered
  later

20
System Engineering

• Elements of a computer-based system
• Software
• Hardware
• People
• Database
• Documentation
• Procedures
• Systems
• A hierarchy of macro-elements

21
The Hierarchy
22
System Modeling

• define the processes that serve the needs of the
  view under consideration.
• represent the behavior of the processes and the
  assumptions on which the behavior is based.
• explicitly define both exogenous and endogenous
  input to the model.
• exogenous inputs link one constituent of a given
  view with other constituents at the same level of
  other levels endogenous input links individual
  components of a constituent at a particular view.
• represent all linkages (including output) that
  will enable the engineer to better understand the
  view.

23
Business Process Engineering

• uses an integrated set of procedures, methods,
  and tools to identify how information systems can
  best meet the strategic goals of an enterprise
• focuses first on the enterprise and then on the
  business area
• creates enterprise models, data models and
  process models
• creates a framework for better information
  management distribution, and control

24
System Architectures

• Three different architectures must be analyzed
  and designed within the context of business
  objectives and goals
• data architecture
• applications architecture
• technology infrastructure
• data architecture provides a framework for the
  information needs of a business or business
  function
• application architecture encompasses those
  elements of a system that transform objects
  within the data architecture for some business
  purpose
• technology infrastructure provides the foundation
  for the data and application architectures

25
The BPE Hierarchy

• Information strategy planning (ISP)
• strategic goals defined
• success factors/business rules identified
• enterprise model created
• Business area analysis (BAA)
• processes/services modeled
• interrelationships of processes and data
• Application Engineering
• a.k.a ... software engineering
• modeling applications/procedures that address
  (BAA) and constraints of ISP
• Construction and delivery
• using CASE and 4GTs, testing

26
Information Strategy Planning

• Management issues
• define strategic business goals/objectives
• isolate critical success factors
• conduct analysis of technology impact
• perform analysis of strategic systems
• Technical issues
• create a top-level data model
• cluster by business/organizational area
• refine model and clustering

27
Defining Objectives and Goals

• Objectivegeneral statement of direction
• Goaldefines measurable objective reduce
  manufactured cost of our product
• Subgoals
• decrease reject rate by 20 in first 6 months
• gain 10 price concessions from suppliers
• re-engineer 30 of components for ease of
  manufacture during first year
• Objectives tend to be strategic while goals tend
  to be tactical

28
Business Area Analysis

• define naturally cohesive groupings of business
  functions and data (Martin)
• perform many of the same activities as ISP, but
  narrow scope to individual business area
• identify existing (old) information systems /
  determine compatibility with new ISP model
• define systems that are problematic
• defining systems that are incompatible with new
  information model
• begin to establish re-engineering priorities

29
The BAA Process
admin.
manufacturing
QC
distribution
sales
acct
engring
Process Decomposition Diagram
Matrices e.g., entity/process matrix
Process Flow Models
Data Model
30
Product Engineering
31
Product Architecture Template
Hartley-Pirbhai Model
32
Architecture Flow Diagram
33
System Modeling with UML

• Deployment diagrams
• Each 3-D box depicts a hardware element that is
  part of the physical architecture of the system
• Activity diagrams
• Represent procedural aspects of a system element
• Class diagrams
• Represent system level elements in terms of the
  data that describe the element and the operations
  that manipulate the data
• These and other UML models will be discussed
  later

34
Deployment Diagram
35
Activity Diagram
36
Class Diagram
37
Summary

• Practices
• Communication
• Planning
• Modeling
• Construction
• Deployment
• System Engineering
• Computer-based systems
• System Engineering Hierarchy
• Business Process engineering
• Product engineering
• System modeling