370 likes | 495 Views
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, haibinz@nipissingu.ca , http://www.nipissingu.ca/faculty/haibinz. Lecture 4 Practice and System Engineering Ref. Chapter 5-6.
E N D
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@nipissingu.ca, http://www.nipissingu.ca/faculty/haibinz
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 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.
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
Core Software Engineering Principles • Provide value to the customer and the user • KIS—keep it simple! • Maintain the product and project “vision” • What you produce, others will consume • Be open to the future • Plan ahead for reuse • Think!
Software Engineering Practices • Consider the generic process framework • Communication • Planning • Modeling • Construction • Deployment • Here, we’ll identify • Underlying principles • How to initiate the practice • An abbreviated task set
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.
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
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 you’ll accommodate changes • Track what you’ve planned
Planning Practices • Initiation • Ask Boehm’s 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?
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
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.
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
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
Construction Practices • 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 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.
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.
Construction Practices • Validation Principles: After you’ve completed your first coding pass, be sure you: • Conduct a code walkthrough when appropriate. • Perform unit tests and correct errors you’ve uncovered. • Refactor the code.
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
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
System Engineering • Elements of a computer-based system • Software • Hardware • People • Database • Documentation • Procedures • Systems • A hierarchy of macro-elements
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.
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
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
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
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
Defining Objectives and Goals • Objective—general statement of direction • 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
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
The BAA Process admin. manufacturing QC distribution sales acct eng’ring Process Decomposition Diagram Matrices e.g., entity/process matrix Process Flow Models Data Model
Product Architecture Template Hartley-Pirbhai Model
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
Summary • Practices • Communication • Planning • Modeling • Construction • Deployment • System Engineering • Computer-based systems • System Engineering Hierarchy • Business Process engineering • Product engineering • System modeling