Software Engineering (8SR2

)
Unit IV Project Scheduling: Concepts. Peoples Efforts. Task set, Task network. Scheduling. EV analysis, Project Plan. Software quality concepts. SQ Assurance, Software reviews, technical reviews, software reliability, ISO 900 L, SQA Plan. SCM process. Version control. SCM standard
Book Recommended
U1-1,2,3 Software Engineering, A Practitioner’s Approach U2-4,5,6 - Pressman Roger. S. TMH. (Strictly 5th Ed) U3-7,8,9

Reference Books R1 Software Engineering Somerville R2 Software Engineering Fairly R R3 Principles of Software Development R4 Software Engineering Shooman, M.L

U4-10,11,13 Addison-Wesley (5/e) U5-14,15,16 McGraw Hill U6-17,18,19 Davis A McGraw Hill McGraw Hill

Chapter 10 System Engineering

The Hierarchy

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

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 acct distribution eng‟ring

sales

Process Flow Models

Data Model

Process Decomp. Diagram

Matrices e.g., entity/process matrix

Product Engineering

Requirements Engineering
Elicitation — determining what the customer requires Analysis & negotiation — understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result Requirements specification — building a tangible model of requirements

Requirements Engineering
System Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistency Validation — reviewing the model Management — identify, control and track requirements and the changes that will be made to them

Product Architecture Template

Architecture Flow Diagram

Chapter 11 Analysis Concepts and Principles

What Are the Real Problems?
the customer has only a vague idea of what is required

the developer is willing to proceed with the "vague idea" on the assumption that "we'll fill in the details as we go" the customer keeps changing requirements
the developer is "racheted" by these changes, making errors in specifications and development

and so it goes ...

Software Requirements Analysis
identify the “customer” and work together to negotiate “product-level” requirements build an analysis model focus on data define function represent behavior prototype areas of uncertainty develop a specification that will guide design conduct formal technical reviews

Requirements Gathering
Facilitated Application Specification Techniques
Software Engineering Group

Customer Group

FAST Guidelines
participants must attend entire meeting all participants are equal preparation is as important as meeting all pre-meeting documents are to be viewed as “proposed” off-site meeting location is preferred set an agenda and maintain it don’t get mired in technical detail J. Wood & D. Silver

Quality Function Deployment
Function deployment determines the “value” (as perceived by the customer) of each function required of the system Information deployment identifies data objects and events Task deployment examines the behavior of the system Value analysis determines the relative priority of requirements

Use-Cases
A collection of scenarios that describe the thread of usage of a system Each scenario is described from the point-ofview of an “actor”—a person or device that interacts with the software in some way Each scenario answers the following questions:
 What are the main tasks of functions performed by the actor?  What system information will the actor acquire, produce or change?  Will the actor inform the system about environmental changes?  What information does the actor require of the system?  Does the actor wish to be informed about unexpected changes

The Analysis Process
build a prototype

the problem

requirements elicitation

develop Specification

Review

create analysis models

Analysis Principle I Model the Data Domain
define data objects describe data attributes establish data relationships

Analysis Principle II Model Function
identify functions that transform data objects indicate how data flow through the system represent producers and consumers of data

Analysis Principle III Model Behavior
indicate different states of the system specify events that cause the system to change state

Analysis Principle IV Partition the Models
refine each model to represent lower levels of abstraction
 refine data objects  create a functional hierarchy  represent behavior at different levels of detail

Analysis Principle V Essence
begin by focusing on the essence of the problem without regard to implementation details

Davis’ Principles
 Understand the problem before you begin to create the analysis model.  Develop prototypes that enable a user to understand how human-machine interaction will occur.  Record the origin of and the reason for every requirement.  Use multiple views of requirements.  Prioritize requirements.  Work to eliminate ambiguity.

The Analysis Model

Data Model

Functional Model Behavioral Model

Chapter 13 Design Concepts and Principles

Analysis to Design

Where Do We Begin?

modeling

Prototype
Spec

Design

Design Principles
          The design process should not suffer from „tunnel vision.‟ The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors.

From Davis [DAV95]

Fundamental Concepts
abstraction—data, procedure, control refinement—elaboration of detail for all abstractions modularity—compartmentalization of data and function architecture—overall structure of the software
 Structural properties  Extra-structural properties  Styles and patterns

procedure—the algorithms that achieve function hiding—controlled interfaces

Data Abstraction
door
manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure

Procedural Abstraction
open
details of enter algorithm

implemented with a "knowledge" of the object that is associated with enter

Stepwise Refinement
open
walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

Modular Design
easier to build, easier to change, easier to fix ...

Modularity: Trade-offs
What is the "right" number of modules for a specific software design?
module development cost
cost of software module integration cost

optimal number of modules

number of modules

Sizing Modules: Two Views
What's inside?? How big is it??

MODULE

Functional Independence
COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

Architecture
“The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]
Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods . Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability
to reuse architectural building blocks.

Information Hiding
module
controlled interface • algorithm • data structure • details of external interface • resource allocation policy

clients

"secret"

a specific design decision

Why Information Hiding?
reduces the likelihood of “side effects” limits the global impact of local design decisions emphasizes communication through controlled interfaces discourages the use of global data leads to encapsulation—an attribute of high quality design results in higher quality software

Sign up to vote on this title
UsefulNot useful