Professional Documents
Culture Documents
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
The Hierarchy
Application Engineering
a.k.a ... software engineering modeling applications/procedures that address (BAA) and constraints of ISP
manufacturing
QC acct distribution engring
sales
Data Model
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
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
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
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 problem
requirements elicitation
develop Specification
Review
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.
Data Model
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.
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
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
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
number of modules
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"