1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada,

2 Lecture 4 Practice and System Engineering Ref. 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. Practice is a broad array of concepts, principles, methods, and tools that you must consider as software is planned and developed. It represents the details—the technical considerations and how to’s—that are below the surface of the software process—the things that you’ll need to actually build high-quality computer software. It represents the details—the technical considerations and how to’s—that are below the surface of the software process—the things that you’ll 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 … George Polya, in a book written in 1945 (!), describes the essence of software engineering practice … Understand the problem (communication and analysis). Understand the problem (communication and analysis). Plan a solution (modeling and software design). Plan a solution (modeling and software design). Carry out the plan (code generation). Carry out the plan (code generation). Examine the result for accuracy (testing and quality assurance). Examine the result for accuracy (testing and quality assurance). At its core, good practice is common-sense problem solving At its core, good practice is common-sense problem solving

5 Core Software Engineering Principles Provide value to the customer and the user Provide value to the customer and the user KIS—keep it simple! KIS—keep it simple! Maintain the product and project “vision” Maintain the product and project “vision” What you produce, others will consume What you produce, others will consume Be open to the future Be open to the future Plan ahead for reuse Plan ahead for reuse Think! Think!

6 Software Engineering Practices Consider the generic process framework Consider the generic process framework Communication Communication Planning Planning Modeling Modeling Construction Construction Deployment Deployment Here, we’ll identify Here, we’ll identify Underlying principles Underlying principles How to initiate the practice How to initiate the practice An abbreviated task set An abbreviated task set

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

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

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

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

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

12 Modeling Practices We create models to gain a better understanding of the actual entity to be built 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. 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. 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 Analysis modeling principles Represent the information domain Represent the information domain Represent software functions Represent software functions Represent software behavior Represent software behavior Partition these representations Partition these representations Move from essence toward implementation Move from essence toward implementation Elements of the analysis model (Chapter 8) Elements of the analysis model (Chapter 8) Data model Data model Flow model Flow model Class model Class model Behavior model Behavior model

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

15 Construction Practices Preparation principles: Before you write one line of code, be sure you: Preparation principles: Before you write one line of code, be sure you: Understand of the problem you’re trying to solve (see communication and modeling) Understand of the problem you’re trying to solve (see communication and modeling) Understand basic design principles and concepts. 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. 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. 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 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: Coding principles: As you begin writing code, be sure you: Constrain your algorithms by following structured programming [BOH00] practice. Constrain your algorithms by following structured programming [BOH00] practice. Select data structures that will meet the needs of the design. Select data structures that will meet the needs of the design. Understand the software architecture and create interfaces that are consistent with it. Understand the software architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible. Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable. Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting. Write code that is self-documenting. Create a visual layout (e.g., indentation and blank lines) that aids understanding. Create a visual layout (e.g., indentation and blank lines) that aids understanding.

17 Construction Practices Validation Principles: After you’ve completed your first coding pass, be sure you: Validation Principles: After you’ve completed your first coding pass, be sure you: Conduct a code walkthrough when appropriate. Conduct a code walkthrough when appropriate. Perform unit tests and correct errors you’ve uncovered. Perform unit tests and correct errors you’ve uncovered. Refactor the code. Refactor the code.

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

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

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

21 The Hierarchy

22 System Modeling define the processes that serve the needs of the view under consideration. 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. 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. 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. 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. 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: Three different architectures must be analyzed and designed within the context of business objectives and goals: data architecture data architecture applications architecture applications architecture technology infrastructure technology infrastructure data architecture provides a framework for the information needs of a business or business function 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 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 technology infrastructure provides the foundation for the data and application architectures

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

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

27 Defining Objectives and Goals Objective—general statement of direction Objective—general statement of direction Goal—defines measurable objective: “reduce manufactured cost of our product” Goal—defines 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 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) 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 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 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 sales acct manufacturing QC eng’ring distribution admin. Data Model Process Decomposition Diagram Matrices e.g., entity/process matrix Process Flow Models

30 Product Engineering

31 Product Architecture Template Hartley-Pirbhai Model

32 Architecture Flow Diagram

33 System Modeling with UML Deployment diagrams Deployment diagrams Each 3-D box depicts a hardware element that is part of the physical architecture of the system Each 3-D box depicts a hardware element that is part of the physical architecture of the system Activity diagrams Activity diagrams Represent procedural aspects of a system element Represent procedural aspects of a system element Class diagrams Class diagrams Represent system level elements in terms of the data that describe the element and the operations that manipulate the data 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 Practices Communication Communication Planning Planning Modeling Modeling Construction Construction Deployment Deployment System Engineering System Engineering Computer-based systems Computer-based systems System Engineering Hierarchy System Engineering Hierarchy Business Process engineering Business Process engineering Product engineering Product engineering System modeling System modeling