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 Practitioners 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

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

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 engring

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 dont 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 actora 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
abstractiondata, procedure, control refinementelaboration of detail for all abstractions modularitycompartmentalization of data and function architectureoverall structure of the software
Structural properties Extra-structural properties Styles and patterns

procedurethe algorithms that achieve function hidingcontrolled 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 encapsulationan attribute of high quality design results in higher quality software