1.

INTRODUCTION TO SOFTWARE ENGINEERING

What is Software? Computer Software is the product that software professional design and built. It includes Programs Content Documents What is software engineering? Your thoughts here Related to the process: a systematic procedure used for the analysis, design, implementation, test and maintenance of software. Related to the product: the software should be efficient, reliable, usable, modifiable, portable, testable, reusable, maintainable, interoperable, and correct. The definition in IEEE Standard: he application of a systematic, disciplined, !uantifiable approach to the de"elopment, operation, and maintenance of software, that is, the application of engineering to software. he study of approaches as in #$$%: he &oint I''' Computer Society and (C) Steering Committee for the establishment of software engineering as a profession. What is im ortant an! what are the ste s? decision ma-ing. Software ser"es as the basis for modern scientific in"estigation and engineering problem sol"ing. # Software affects nearly e"ery aspect of our li"es. *data+. ,ou build software li-e you build any successful product, by applying a process that leads to a high.!uality result. ,ou apply a software engineering approach. What is the wor" #ro!$%t? /rom the point of "iew of a software engineer, the wor- product is the programs, documents, and content. /rom the user0s "iewpoint, the wor- product is the resultant information that somehow ma-es the user0s world better. The Product Is the engine that dri"es business

It is embedded in systems of all -inds: transportation, medical, telecommunications, military, industrial processes, entertainment, office products1 Software)s D$a* Ro*e

1.1 T&E E'O('ING RO(E OF SOFTWARE

Software is a product Deli"ers computing potential Produces, manages, ac!uires, modifies, displays, or transmits information. Software is a vehicle for delivering a product Supports or directly pro"ides system functionality Controls other programs *e.g., an operating system+ 'ffects communications *e.g., networ-ing software+ 2elps build other software *e.g., software tools+ he 3aw of Continuing Change *#$45+: '.type systems must be continually adapted else they become progressi"ely less satisfactory. he 3aw of Increasing Comple6ity *#$45+: (s an '.type system e"ol"es its comple6ity increases unless wor- is done to maintain or reduce it. he 3aw of Self Regulation *#$45+: he '.type system e"olution process is self. regulating with distribution of product and process measures close to normal. he 3aw of Conser"ation of 7rgani8ational Stability *#$9:+: he a"erage effecti"e global acti"ity rate in an e"ol"ing '.type system is in"ariant o"er product lifetime. he 3aw of Conser"ation of /amiliarity *#$9:+: (s an '.type system e"ol"es all associated with it, de"elopers, sales personnel, users, for e6ample, must maintain mastery of its content and beha"ior to achie"e satisfactory e"olution. he 3aw of Continuing ;rowth *#$9:+: he functional content of '.type systems must be continually increased to maintain user satisfaction o"er their lifetime. he 3aw of Declining <uality *#$$=+: he !uality of '.type systems will appear to be declining unless they are rigorously maintained and adapted to operational en"ironment changes. he /eedbac- System 3aw *#$$=+: '.type e"olution processes constitute multi.le"el, multi.loop, multi.agent feedbac- systems and must be treated as such to achie"e significant impro"ement o"er any reasonable base.

>

1.+ SOFTWARE C&ARACTERISTICS

sense. Software does not wear out.
i n c r e a s e d f a i l u r e r a t e d u e t o s i d e e f f e c t s

Software is developed or engineered; it is not manufactured in the classical

F a i l u r e r a t e

c h a n g e a c t u a lc u r v e

i d e a l i z e d c u r v e T i m e

Failure curve for software (idealized and actual curves !ost software is custom"#uilt$ rather than #eing assem#led from e%isting components. Software Com onents In the hardware world, component reuse is a natural part of the engineering process. In the software world, it is something that has yet to be achie"ed on a broad scale. Reusability is an important characteristic of a high.!uality software component. ( software component should be designed and implemented so that it can be reused in many different programs. In the #$=:s, we built scientific subroutine libraries that wear reusable in a broad array of engineering and scientific application. hese subroutine libraries reused well defined algorithms in an effecti"e manner, but had a limited domain of application. oday, we ha"e e6tended our "iew of reuse to encompass not only algorithms, but also data structures.

1., T&E C&ANGING NATURE OF SOFTWARE

Software A *i%ations System software: system software is collection of programs written to ser"ice other programs. '.g. Compilers, editors, file management utilities, operating systems, dri"ers, networ-ing etc. (pplication software: (pplication software consists of standalone programs that sol"e a specific business need. '.g. Point of sole transaction processing, real time manufacturing control etc. 'ngineering?scientific software: Computer.aided design, system simulation, and other interacti"e applications ha"e begun to ta-e on real.time and e"en system software characteristics. %

'mbedded software: 'mbedded software resides within a product or system and is used to implement and control features and functions for the end.user and for the system itself. 'mbedded software can perform limited and esoteric functions. e.g. digital functions in an automobile such as fuel control, dashboard displays, bra-ing systems, etc. Product.line software: Designed to pro"ide a specific capability for use by many different customers product.line software can focus on a limited and esoteric mar-etplace or address mass consumer mar-ets. e.g. in"entory control, word processing, spreadsheets, computer graphics, multimedia etc. @eb(pps *@eb applications+: A@eb(pps,B span a wide array of applications. In their simplest form, web(pps can be little more than a set of lin-ed hyperte6t files that present information using te6t and limited graphics. (I software: (l software ma-es use of non numerical algorithms to sol"e comple6 problems that are not amenable to computation or straight forward analysis. e.g. robotics. Software-New Categories Cbi!uitous computing: wireless networ-s Det sourcing: the @eb as a computing engine 7pen source: BfreeB source code open to the computing community *a blessing, but also a potential curseE+ (lso 1 Data mining ;rid computing Cogniti"e machines Software for nanotechnologies

1.. SOFTWARE /0T&S

Cnli-e ancient myths, software myths propagate misinformation and confusion that ha"e caused serious problems for managers, technical people and customers. /anagement /1ths /1th2 @e already ha"e a boo- that0s full of standards and procedures for building software. @on0t that pro"ide my people with e"erything they need to -nowF Rea*it12 he boo- of standards may "ery well e6ist, but is it usedF Is it completeF In many cases, the answer is no. 5

/1th2 If we get behind schedule, we can add more programmers and catch up. Rea*it12 Software de"elopment is not a mechanistic process li-e manufacturing. /1th2 If we decide to outsource the software proGect to a third party, I can Gust rela6 and let that firm build it. Rea*it12 If an organi8ation does not understand how to manage and control software proGects internally, it will in"ariably struggle when it out sources software proGects. C$stomer /1ths /1th: ProGect re!uirements continually change, but change can be easily accommodated because software is fle6ible. Rea*it12 It is true that software re!uirements do change, but the impact of change "aries with the time at which it is introduced. /1th2 ( general statement of obGecti"es is sufficient to begin writing programs we can fill in the details later. Rea*it12 (lthough a comprehensi"e and stable statement of re!uirements is not always possible, an ambiguous statement of obGecti"es is a recipe for disaster. #ra%titioner)s /1ths /1th2 done. 7nce we write the program and get it to wor- our Gob is

Rea*it12 A he sooner you begin writing code, the longer it0ll ta-e you to get done.B Industry data indicate that between =: and 9: percent of all effort e6pended on software will be e6pended after it is deli"ered to the customer for the first time. /1th2 Cntil I get the program running, I ha"e no way of assessing its !uality. Rea*it12 7ne of the most effecti"e software !uality assurance mechanisms can be applied from the inception of a proGect.the formal technical re"iew. /1th2 he only deli"erable wor- product for a successful proGect is the wor-ing program. Rea*it12 ( wor-ing program is only one part of a software configuration that includes many elements. H

/1th2 Software engineering will ma-e us creates "oluminous and unnecessary documentation and will in"ariably slow us down. Rea*it12 Software engineering is not about creating documents. It is about creating !uality. Ietter !uality leads to reduced rewor-. JJJJJJJJ

+. A GENERIC 'IEW OF #ROCESS

Cha ter O3er3iew @hat is itF ( software process.a series of predictable steps that leads to a timely, high.!uality product. @ho does itF )anagers, software engineers, and customers. @hy is it importantF Pro"ides stability, control, and organi8ation to an otherwise chaotic acti"ity. @hat are the StepsF ( handful of acti"ities are common to all software process, details "ary. @hat is the wor- productF Programs, documents, and data. Correct processF (ssessment, !uality deli"erable.

+.1 SOFTWARE ENGINEERING 4 A (A0ERED TEC&NO(OG0

/ocus on !uality: must rest on an organi8ational commitment to !uality. Process model: foundation for S' is the process layers, a frame wor-, models documents, data, reports etc. )ethods: how to0s, communication, re!uirement analysis design modeling program connection, testing and support. ools: pro"ide automated or semi automated support for the process and methods.

+.+ A #ROCESS FRA/EWOR5

#ro%ess framewor" /ramewor- acti"ities @or- tas-s @or- products )ilestones K deli"erables <( chec-points Cmbrella (cti"ities Framewor" A%ti3ities Communication: his framewor- acti"ity in"ol"es hea"y communication and collaboration with the customer and encompasses re!uirements gathering and other related acti"ities. Planning: It describes the technical tas-s to be conducted, the ris-s that are li-ely, the resources that will be re!uired, the wor- products to be produced, and a worschedule. )odeling: his acti"ity encompasses (nalysis of re!uirements Design Construction: his acti"ity combines Code generation esting Deployment: he software is deli"ered to the customer who e"aluates the deli"ered product and pro"ides feedbac- based on the e"aluation. Um6re**a A%ti3ities Software proGect trac-ing and control: allows the software team to assess progress against the proGect plan and ta-e necessary action to maintain schedule. /ormal technical re"iews: (ssesses software reengineering wor- products in an effort to unco"er and remo"e errors before they are propagated to the ne6t action or acti"ity. Software !uality assurance: Defines and conducts the acti"ities re!uired to ensure software !uality.

Software configuration management: manages the effects of change throughout the software process. @or- product preparation and production: encompasses the acti"ities re!uired to create wor- products such as models, documents, logs, forms, and lists. Reusability management: defines criteria for wor- product reuse and establishes mechanisms to achie"e reusable components. )easurement: defines and collects process, proGect, and product measures that assist the team in deli"ering software that meets customers0 needsL can be used in conGunction with all other framewor- and umbrella acti"ities.

Ris- management: assesses ris-s that may affect the outcome of the proGect or the !uality of the product. The #ro%ess /o!e*2 A!a ta6i*it1 the framewor- acti"ities will always be applied on e"ery proGect ... IC the tas-s *and degree of rigor+ for each acti"ity will "ary based on: the type of proGect characteristics of the proGect common sense GudgmentL concurrence of the proGect team

+., T&E CA#A7I(IT0 /ATURIT0 /ODE( INTEGRATION 8C//I9

he C))I defines each process area in terms of Aspecific goalsB and the Aspecific practicesB re!uired to achie"e these goals. Specific goals establish the characteristics that must e6ist if the acti"ities implied by a process area are to be effecti"e. Specific practices refine a goal into a set of process.related acti"ities.

he C))I represents a process meta.model in tow different ways: *#+ as continuous model and *>+ as a staged model. Ca a6i*it1 *e3e*s2 (e3e* :2 In%om *ete. he process area is either not performed or does not achie"e all goals and obGecti"es defined by the C))I for le"el # capacity. (e3e* 12 #erforme!. (ll of the specific goals of the process area ha"e been satisfied. @or- tas-s re!uired to produce defined wor- products are being conducted. (e3e* +2 /anage!. (ll le"el # criteria ha"e been satisfied. In addition, all wor- associated with the process area conforms to an organi8ationally defined policyL all people doing the wor- ha"e access to ade!uate resources to get the Gob doneL sta-eholders re acti"ely in"ol"ed in the process area as re!uireL all wortas-s and wor- products are Amonitored, controlled, and re"iewedL and are e"aluated for adherence to the process descriptionB

(e3e* ,2 Define!. (ll le"el > criteria ha"e been achie"ed. In addition, the process is Atailored from the organi8ation0s set of standard processes according to the organi8ation0s tailoring guidelines, and contributes worproducts, measures, and other process.impro"ement information to the organi8ational process assetsB (e3e* .2 ;$antitati3e*1 manage!. (ll le"el % criteria ha"e been achie"ed. In addition, the process area is controlled and impro"ed using measurement and !uantitati"e assessment. A<uantitati"e obGecti"es for !uality and process performance are established and used as criteria in managing the processB

(e3e* <2 O timi=e!. (ll capability le"el 5 criteria ha"e been achie"ed. In addition, the process area is adapted and optimi8ed using !uantitati"e means to meet changing customer needs and to continually impro"e the efficacy of the process area under considerationB. +.. #ROCESS #ATTERNS Process patterns define a set of acti"ities, actions, wor- tas-s, wor- products and?or related beha"iors. ( template is used to define a pattern. ypical e6amples: Customer communication *a process acti"ity+ (nalysis *an action+ Re!uirements gathering *a process tas-+ Re"iewing a wor- product *a process tas-+ Design model *a wor- product+

+.< #ROCESS ASSESS/ENT

he process should be assessed to ensure that it meets a set of basic process criteria that ha"e been shown to be essential for a successful software engineering.
Software Process

identifies modifications to

is examined by

identifies capabilities and risk of

Software Process Assessment

Software Process Improvement

leads to

leads to

Capability Determination

motivates

)any different assessment options are a"ailable: SC()PI: pro"ides a fi"e.step process assessment model that incorporates initiating, diagnosing, establishing, acting, and learning. CI( IPI: pro"ides diagnostic techni!ue for assessing the relati"e maturity of a software organi8ation. SPIC': standard defines a set of re!uirements for software process assessment. IS7 $::#:>:::: for software is a generic standard that applies to any organi8ation that want impro"e the o"erall !uality of the product systems, or ser"ices that it pro"ides. JJJJJJ

,. #ROCESS /ODE(S
#res%ri ti3e /o!e*s
Prescripti"e process models ad"ocate an orderly approach to software engineering. That leads to a few &uestions ' If prescripti"e process models stri"e for structure and order, are they inappropriate for a software world that thri"es on changeF ,et, if we reGect traditional process models *and the order they imply+ and replace them with something less structured, do we ma-e it impossible to achie"e coordination and coherence in software wor-F

,.1 The Waterfa** /o!e*

#:

he @aterfall model sometimes called the classic life cycle, suggests a systematic, se!uential approach to software de"elopment. It is a oldest paradigm for software engineering. )ost widely used though no longer state.of.art. 'ach step results in documentation. )ay be suited to for well.understood de"elopments using familiar technology. Dot suited to new, different systems because of specification uncertainty. Difficulty in accommodating change after the process has started. Can accommodate iteration but indirectly. @or-ing "ersion not a"ailable till late in process. 7ften get bloc-ing states.

,.+ T&E INCRE/ENTA( #ROCESS /ODE(S

here are many situations in which initial software re!uirements are reasonably well defined, but the o"erall scope of the de"elopment effort precludes a purely linear process. In addition, there may be a compelling need to pro"ide a limited set of software functionality to users !uic-ly and then refine and e6pand on that functionality in later software releases. ##

In such cases, a process model that is designed to produce the software in increments is chosen. The In%rementa* /o!e* (pplies an iterati"e philosophy to the waterfall model. Di"ide functionality of system into increments and use a liner se!uence of de"elopment on each increment. /irst increment deli"ered is usually the core product, i.e. only basic functionality. Re"iews of each increment impact on design of later increments. )anages ris- well. '6treme Programming *MP+, and other (gile )ethods, are incremental, but they do not implement the waterfall model steps in the standard order.

The Ra i! A

*i%ation De3e*o ment 8RAD9 /o!e*

Similar to waterfall but uses a "ery short de"elopment cycle *=:to$: days to completion+. Cses component.based construction and emphasi8es reuse and code generation. Cse multiple teams on scaleable proGects. Re!uires hea"y resource. Re!uires de"elopers and customers who are hea"ily committed. Performance can be a problem. Difficult to use with new technology #>

,., E'O(UTIONAR0 /ODE(S

'"olutionary models are iterati"e. hey are characteri8ed in a manner that enables software engineers to de"elop increasingly more complete "ersions of the software. #rotot1 ing Ideally moc-.up ser"es as mechanism for identifying re!uirements. issues. )ay create pressure from users on deli"er earlier. )ay use a less.than.ideal platform to deli"er e.g Nisual Iasic O e6cellent for prototyping, may not be as effecti"e in actual operation. Specifying re!uirements is often "ery difficult. Csers don0t -now e6actly what they want until they see it. Prototyping in"ol"es building a moc-.up of the system and using to obtain for user feedbac-. #% Csers li-e the method, get a feeling for the actual system. 3ess ideally may be the basis for completed. Prototypes often ignore !uality?performance?maintenance

Closely related to what are now called A(gile )ethodsB

Quick plan

Communication

Mo deling Quick de sign

Deployment Delivery & Feedback

Construction of prototype

The S ira* /o!e* the best approaches. scales software de"elopmentF e"olution of productF assessment s-ills Re!uires e6cellent management and risCan use prototyping during any phase in the Is a realistic approach to the problems of large De"elopment cycles through multiple*%.=+ tas- regions *=stage "ersion+. Customer communication Planning Ris- analysis 'ngineering Construction and release Customer e"aluation Incremental releases 'arly releases may be paper or prototypes. 3ater releases become more complicated )odels software until it is no longer used Dot a sil"er bullet, but considered to be one of

#5

planning
estimation scheduling risk analysis

communication modeling
analysis design start

deployment
delivery feedback

construction
code test

Con%$rrent De3e*o ment /o!e* he concurrent de"elopment model, sometimes called concurrent engineering, can be represented schematically as a series of framewor- acti"ities, software engineering actions and tas-s, and their associated states. he concurrent process model defines a series of e"ents that will trigger transitions from state to state for each of the software engineering acti"ities, action, or tas-s. he concurrent process model is applicable to all types of software de"elopment and pro"ides an accurate picture of the current state of a proGect. Rather than confining software engineering acti"ities, actions, and tas-s to a se!uence of e"ents, it defines a networ- of acti"ities. 'ach acti"ity, action, or tas- on the networ- e6ists simultaneously with other acti"ities, actions, or tas-s. '"ents generated at one point in the process networ- trigger transitions among the states.

#H

none !odeling activity

Under development

represents the state of a software engineering activity or task

A waiting changes

Under review Under revision aselined

Done

,.. S#ECIA(I>ED #ROCESS /ODE(S (omponent #ased developmentPthe process to apply when reuse is a de"elopment obGecti"e. Formal methodsPemphasi8es the mathematical specification of re!uirements. (7SDPpro"ides a process and methodological approach for defining, specifying, designing, and constructing aspects

,.< T&E UNIFIED #ROCESS 8U#9 Unifie! #ro%ess a Ause.case dri"en, architecture.centric, iterati"e and incrementalB software process closely aligned with the Cnified )odeling 3anguage *C)3+

#=

 Unifie! #ro%ess #hases he inception phases of the up encompass both customer communication and planning acti"ities and emphasi8e the de"elopment and refinement of use.cases as a primary model. (n elaboration phase that encompasses the customer0s communication and modeling acti"ities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. ( construction phase that refines and translates the design model into implemented software components. ( transition phase that transfers the software from the de"eloper to the end. user for beta testing and acceptance. ( production phase in which on.going monitoring and support are conducted.

#4

UP P ases
Inception "laboration Construction #ransition Production

!orkflows $e%uirements Analysis Design Implementation #est Support Iterations &' &( &n)' &n

U# Wor" #ro!$%ts he following figure illustrates the -ey wor- products produced as conse!uences of the four technical up phases.

Inception phase
*ision document Initial use)case model Initial pro+ect glossary Initial business case Initial risk assessment, Pro+ect planphases and iterations, usiness modelif necessary, .ne or more prototypes
"nc ept i o n

"laboration phase
Use)case model Supplementary re%uirements including non)functional Analysis model Software architecture Description, "xecutable architectural prototype, Preliminary design model $evised risk list Pro+ect plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Construction phase
Design model Software components Integrated software increment #est plan and procedure #est cases Support documentation user manuals installation manuals description of current increment

#ransition phase
Delivered software increment eta test reports /eneral user feedback

JJJJJJJJ

.. SOFTWARE RE;UIRE/ENTS
#9

 Contents2 Functional and non"functional re&uirements )ser re&uirements S*stem re&uirements Interface specification The Software +e&uirements ,ocument Re?$irements engineering2 he process of establishing the ser"ices that the customer re!uires from a system and the constraints under which it operates and is de"eloped he re!uirements themsel"es are the descriptions of the system ser"ices and constraints that are generated during the re!uirements engineering process

What is a re?$irement? It may range from a high.le"el abstract statement of a ser"ice or of a system constraint to a detailed mathematical functional specification his is ine"itable as re!uirements may ser"e a dual function !a* #e the #asis for a bid for a contract " therefore must #e open to interpretation !a* #e the #asis for the contract itself " therefore must #e defined in detail -oth these statements ma* #e called re&uirements Re?$irements a6stra%tion 8Da3is@ 1AA,9 If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisations needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system. T1 es of re?$irement Cser re!uirements Statements in natural language plus diagrams of the services the s*stem provides and its operational constraints. .ritten for customers System re!uirements / structured document setting out detailed " descriptions of the s*stem services. .ritten as a contract #etween client and contractor Software specification #$

/ detailed software description which can serve as a #asis for a design or implementation. .ritten for developers.

Definitions an! s e%ifi%ations

R equir em ents definitio n 1. T he softwar em ust provide a m eans of rep resenting and 1. accessing extern al files create db y oth er to ols.

R equir em ents specification 1.1 T h e user sho uld be p rovide d with facilities to define the type o f 1.2 external files. 1.2 E ach external file type m ay h a ve an as socia te d to ol which m ay b e 1.2 applied to the file . 1.3 E ach external file type m ay b e rep rese nted as a specific icon on 1.2 the users d isplay. 1.4 F acilities should be pro vide d for the ic on r epresenting an 1.2 external file type to be defined by theu ser. 1.5 W he n a user selects an icon rep resentin g an extern al file , the 1.2 effect o f that selection is to app ly the too l asso ciated with th e type of 1.2 the external file to th e file rep resentedby the selected ico n.

Re?$irements rea!ers2
U s e rr e q u ir e m e n ts C li e n tm a n a g e r s S y s te m e n d u s e r s C li e n te n g in e e r s C o n tr a c t o rm a n a g e r s S y s te m a r c h it e c ts S y s te m e n d u s e r s C li e n te n g in e e r s S y s te m a r c h it e c ts S o f t w a r ed e v e l o p e r s C li e n te n g in e e r s( p e r h a p s ) S y s te m a r c h it e c ts S o f t w a r ed e v e l o p e r s

S y s te m r e q u i r e m e n ts

S o f t w a r ed e s ig n s p e c i f ic a ti o n

Another %*assifi%ation of re?$irements /unctional re!uirements Don.functional re!uirements Domain re!uirements

..1 FUNCTIONA( RE;UIRE/ENTS

Describe functionality or system ser"ices, how the system should react to particular inputs and how the system should beha"e in particular situations. Depend on the type of software, e6pected users and the type of system where the software is used /unctional user re!uirements may be high.le"el statements of what the system should do but functional system re!uirements should describe the system ser"ices in detail. >:

EBam *es2 The user shall #e a#le to search either all of the initial set of data#ases or select a su#set from it. The s*stem shall provide appropriate viewers for the user to read documents in the document store. Ever* order shall #e allocated a uni&ue identifier (0+,E+1I, which the user shall #e a#le to cop* to the account2s permanent storage area. Problems arise when re!uirements are not precisely stated. (mbiguous re!uirements may be interpreted in different ways by de"elopers and users. Consider the term Qappropriate "iewers0 in the pre"ious e6ample. )ser intention . special purpose "iewer for each different document type ,eveloper interpretation . Pro"ide a te6t "iewer that shows the contents of the document Re!uirements should be complete and consistent Complete hey should include descriptions of a** facilities re!uired Consistent here should be no conflicts or contradictions in the descriptions of the system facilities

In practice, it is impossible to produce a complete and consistent re!uirements document

..+ NON4FUNCTIONA( RE;UIRE/ENTS

Define system properties and constraints e.g. reliability, response time and storage re!uirements. Constraints are I?7 de"ice capability, system representations, etc. Can be constraints on the process too Cse a particular C(S' system, programming language or de"elopment method System maybe unusable if non.functional re!uirements are not satisfied *Critical+ Non4f$n%tiona* %*assifi%ations Product re!uirements Re!uirements which specify that the deli"ered product must beha"e in a particular way e.g. e6ecution speed, reliability, etc. 7rganisational re!uirements Re!uirements which are a conse!uence of organisational policies and procedures e.g. process standards used, implementation re!uirements, etc. '6ternal re!uirements >#

Re!uirements which arise from factors which are e6ternal to the system and its de"elopment process e.g. interoperability re!uirements, legislati"e re!uirements, etc. Non4f$n%tiona* re?$irements eBam *es

Product re!uirement It shall #e possi#le for all necessar* communication #etween the /PSE and the user to #e e%pressed in the standard /da character set 7rganisational re!uirement The s*stem development process and delivera#le documents shall conform to the process and delivera#les defined in 3Y4(o"SP"ST/5"67

'6ternal re!uirement The s*stem shall not disclose an* personal information a#out customers apart from their name and reference num#er to the operators of the s*stem Goa*s an! re?$irements Don.functional re!uirements may be "ery difficult to state precisely and imprecise re!uirements may be difficult to "erify. ;oal / general intention of the user such as ease of use Nerifiable non.functional re!uirement / statement using some measure that can #e o#8ectivel* tested ;oals are helpful to de"elopers as they con"ey the intentions of the system users EBam *es A s1stem goa* The s*stem should #e eas* to use #* e%perienced controllers and should #e organised in such a wa* that user errors are minimised. A 3erifia6*e non4f$n%tiona* re?$irement E%perienced controllers shall #e a#le to use all the s*stem functions after a total of two hours training. /fter this training$ the average num#er of errors made #* e%perienced users shall not e%ceed two per da*.
Property Speed Size Ease of use Reliability M easure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems

Re?$irements meas$res

Robustness Portability /aintaina6i*it1 ?

Non4f$n%tiona* re?$irement %onf*i%ts >>

Conflicts between different non.functional re!uirements are common in comple6 systems '6ample: Spacecraft system ma6imum storage re!uired should be 5)I *fit onto R7)+ system should be written in (da language *suitable of critical real.time software de"elopment+ It might be impossible to write an (da program with the re!uired functionality in less than 5)I RR rade.off needed.

.., DO/AIN RE;UIRE/ENTS

Deri"ed from the application domain and describe system characteristics and features that reflect the domain )ay be new functional re!uirements, constraints on e6isting re!uirements or define specific computations If domain re!uirements are not satisfied, the system may be unwor-able Domain re?$irements 8eBam *es9 3ibrary system There shall #e a standard user interface to all data#ases which shall #e #ased on the 496.7: standard. -ecause of cop*right restrictions$ some documents must #e deleted immediatel* on arrival. ,epending on the user2s re&uirements$ these documents will either #e printed locall* on the s*stem server for manuall* forwarding to the user or routed to a networ; printer. rain Protection system The deceleration of the train shall #e computed as< ,train = ,control > ,gradient .here ,gradient is 6.?@msA B compensated gradientCalpha and where the values of 6.?@msA Calpha are ;nown for different t*pes of train

Domain re?$irements ro6*ems Cnderstand ability Re!uirements are e6pressed in the language of the application domain his is often not understood by software engineers de"eloping the system Implicitness Domain specialists understand the area so well that they do not thin- of ma-ing the domain re!uirements e6plicit.

... USER RE;UIRE/ENTS

Should describe functional and non.functional re!uirements so that they are understanda#le #* s*stem users who don0t ha"e detailed technical -nowledge >%

Cser re!uirements are defined using natural language, tables and diagrams. 3ac- of clarity Precision is difficult without ma-ing the document difficult to read Re!uirements confusion /unctional and non.functional re!uirements tend to be mi6ed.up Re!uirements amalgamation Se"eral different re!uirements may be e6pressed together Grid facilities To assist in the positioning of entities on a diagram$ the user ma* turn on a grid in either centimetres or inches$ via an option on the control panel. Initiall*$ the grid is off. The grid ma* #e turned on and off at an* time during an editing session and can #e toggled #etween inches and centimetres at an* time. / grid option will #e provided on the reduce"to"fit view #ut the num#er of grid lines shown will #e reduced to avoid filling the smaller diagram with grid lines. Re?$irement ro6*ems ;rid re!uirement mi6es three different -inds of re!uirement Conceptual functional re!uirement *the need for a grid+ Don.functional re!uirement *grid units+ Don.functional CI re!uirement *grid switching+ Sometimes re!uirements include both conceptual and detailed information the detailed information should be specified in the system re!uirement specification Str$%t$re! resentation

#ro6*ems with nat$ra* *ang$age

EBam *e2 e!itor gri! re?$irement

Grid facilities: The editor shall provide a grid facility where a matrix of horizontal and vertical lines provides a background to the editor window . This grid shall be a passive grid where the alignment of entities is the user's responsibility. Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to' grid lines can be useful, the positioning is imprecise. The user is the best person to decide where entities should be positioned. G$i!e*ines for writing re?$irements In"ent a standard format and use it for all re!uirements Cse language in a consistent way. Cse shall for mandatory re!uirements, should for desirable re!uirements Cse te6t highlighting to identify -ey parts of the re!uirement ("oid the use of computer Gargon )ore detailed specifications of user re!uirements Ser"e as a basis for designing the system >5

..< S0STE/ RE;UIRE/ENTS

)ay be used as part of the system contract System re!uirements may be e6pressed using system models Re?$irements an! !esign In principle, re!uirements should state W&AT the system should do *and the design should describe how it does this+ In practice, re!uirements and design are inseparable ( system architecture may be designed to structure the re!uirements he system may inter.operate with other systems that generate design re!uirements he use of a specific design may be a domain re!uirement Nat$ra* (ang$age s e%ifi%ation2 #ro6*ems (mbiguity he readers and writers of the re!uirement must interpret the same words in the same way. D3 is naturally ambiguous so this is "ery difficult '.g. signs on an escalator: QShoes must be worn0 QDogs must be carried0 7"er.fle6ibility he same thing may be said in a number of different ways in the specification 3ac- of modularisation D3 structures are inade!uate to structure system re!uirements

A*ternati3es to N( s e%ifi%ation N o ta tio n D escrip tio n S tru ctu red n atu ral T h is ap p ro ach d ep en d s o n d efin in g stan d ard fo rm s o r tem p lates to ex p ress th e lan g u ag e req u irem en ts sp ecificatio n .
D esig n d escrip tio n T h is ap p ro ach u ses a lan g u ag e lik e a p ro g ram m in g lan g u ag e b u t w ith m o re lan g u ag es ab stract featu res to sp ecify th e req u irem en ts b y d efin in g an o p eratio n al m o d el o f th e sy stem . G rap h ical n o tatio n s M ath em atical sp ecificatio n s A g rap h ical lan g u ag e, su p p lem en ted b y tex t an n o tatio n s is u sed to d efin e th e fu n ctio n al req u irem en ts fo r th e system . U se -case d escrip tio n s (Jaco b sen , C h risterso n et al., 1 9 9 3 ) are o n e tech n iq u e. T h ese are n o tatio n s b ased o n m ath em atical co n cep ts su ch as fin ite -state m ach in es o r sets. T h ese u n am b ig u o u s sp ecificatio n s red u ce th e arg u m en ts b etw e en cu sto m er an d co n tracto r ab o u t sy stem fu n ctio n ality . H o w ev er, m o st cu sto m ers d o n t u n d erstan d fo rm al sp ecificatio n s an d are relu ctan t to accep t it as a system co n tract.

Str$%t$re! *ang$age s e%ifi%ations ( limited form of natural language may be used to e6press re!uirements his remo"es some of the problems resulting from ambiguity and fle6ibility and imposes a degree of uniformity on a specification >H

7ften supported using a forms.based approach

Form46ase! s e%ifi%ations Definition of the function or entity Description of inputs and where they come from Description of outputs and where they go to Indication of other entities re!uired Pre and post conditions *if appropriate+ he side effects *if any+ #D(46ase! re?$irements !efinition Re!uirements may be defined operationally using a programming language li-e notation but with more fle6ibility of e6pression )ost appropriate in two situations @here an operation is specified as a se!uence of actions and the order is important *when nested conditions and loops are in"ol"ed+ @hen hardware and software interfaces ha"e to be specified. (llows interface obGects and types to be specified #D( !isa!3antages PD3 may not be sufficiently e6pressi"e to e6press the system functionality in an understandable way Dotation is only understandable to people with programming language -nowledge he re!uirement may be ta-en as a design specification rather than a model to help understand the system

..C Interfa%e s e%ifi%ation )ost systems must operate with other systems and the operating interfaces must be specified as part of the re!uirements hree types of interface may ha"e to be defined Procedural interfaces Data structures that are e6changed Data representations /ormal notations are an effecti"e techni!ue for interface specification

interface PrintSer"er S

#D( interfa%e !es%ri tion

?? defines an abstract printer ser"er >=

?? re!uires: interface Printer, interface PrintDoc ?? pro"ides: initiali8e, print, displayPrint<ueue, cancelPrint&ob, switchPrinter "oid initiali8e * Printer p + L "oid print * Printer p, PrintDoc d + L "oid displayPrint<ueue * Printer p + L "oid cancelPrint&ob *Printer p, PrintDoc d+ L "oid switchPrinter *Printer p#, Printer p>, PrintDoc d+ L T ??PrintSer"er

..D T&E RE;UIRE/ENTS DOCU/ENT

he re!uirements document is the official statement of what is re!uired of the system de"elopers Should include both a definition and a specification of re!uirements It is D7 a design document. (s far as possible, it should set of @2( the system should do rather than 27@ it should do it Users of a re?$irements !o%$ment
S p e c if y th er e q u i r e m e n t sa n d r e a dt h e m t oc h e c k th a t th e y m e e tt h e i rn e e d s .T h e y s p e c i f yc h a n g e stot h e r e q u i r e m e n t s

S y s te m c u s t o m e r s

M a n a g e r s

U s eth er e q u ir e m e n ts d o c u m e n tt op la nab idf o r th es y s t e m a n dt op la nt h e s y s te m d e v e l o p m e n tp r o c e s s

S y s te m e n g i n e e r s

U s eth er e q u ir e m e n tst o u n d e r s t a n dw h a ts y s t e m ist o b ed e v e l o p e d

S y s te m t e s t e n g i n e e r s

U s eth er e q u ir e m e n tst o d e v e l o pv a li d a t io nt e s t sf o r th es y s t e m

S y s te m m a i n t e n a n c e e n g i n e e r s

U s eth er e q u ir e m e n tst oh e lp u n d e r s t a n dt h es y s te m a n d th er e la t io n s h i p sb e t w e e ni ts p a r ts

Re?$irements !o%$ment re?$irementsE Specify e6ternal system beha"iour Specify implementation constraints 'asy to change Ser"e as reference tool for maintenance >4

Record forethought about the life cycle of the system i.e. predict changes Characterise responses to une6pected e"ents IEEE re?$irements stan!ar! Introduction ;eneral description Specific re!uirements (ppendices Inde6 his is a generic structure that must be instantiated for specific systems

RE;UIRE/ENTS DOCU/ENT STRUCTURE Introduction ;lossary Cser re!uirements definition System architecture System re!uirements specification System models System e"olution (ppendices Inde6 JJJJJJJ

<. RE;UIRE/ENTS ENGINEERING #ROCESSES

O6Fe%ti3es he obGecti"e of this chapter is to discuss the acti"ities in"ol"ed in the re!uirements engineering process. @hen you study this chapter, you will:

>9

Cnderstand the principal re!uirements of engineering acti"ities and their relationshipsL 2a"e been introduced to se"eral techni!ues of re!uirements elicitation and analysisL understand the importance of re!uirements "alidation and how re!uirements re"iews are used in this processL understand why re!uirements management is necessary and how it supports other re!uirements engineering acti"ities. Contents /easibility studies Re!uirements elicitation and analysis Re!uirements "alidation Re!uirements management Requirements engineering processes R' processes "ary widely depending on the application domain the people in"ol"ed and the organisation de"eloping the re!uirements 2owe"er, there are a number of generic acti"ities common to all processes /easibility study Re!uirements elicitation and analysis Re!uirements specification *documenting+ Re!uirements "alidation Re!uirements management is an additional acti"ity to manage changing re!uirements
F easibility stud y Requirements elicitation and analysis

R equirements specification Requirements va lidation

F easibility report System models U ser and system requirements

Requirements document

<.1 FEASI7I(IT0 STUD0

( feasibility study decides whether or not the proposed system is worthwhile ( short focused study that chec-s If the system contributes to organisational obGecti"es >$

If the system can be engineered using current technology and within budget If the system can be integrated with other e6isting systems Feasibility study implementation

Iased on information assessment *what is re!uired+, information collection and report writing <uestions for people in the organisation @hat if the system wasn0t implementedF @hat are current process problemsF 2ow will the proposed system helpF @hat will be the integration problemsF Is new technology neededF @hat s-illsF @hat facilities must be supported by the proposed systemF Feasibility study report he /S report should recommend whether or not the system de"elopment should continue. It may propose changes to the scope, budget, schedule and also suggest re!uirement changes

<.+ RE;UIRE/ENTS E(ICITATION AND ANA(0SIS

*re!uirements disco"ery+ In"ol"es technical staff wor-ing with customers to find out about the application domain, the ser"ices that the system should pro"ide and the system0s operational constraints )ay in"ol"e end.users, managers, engineers in"ol"ed in maintenance, domain e6perts, trade unions, etc. hese are called sta;eholders Problems of requirements analysis Sta"eho*!ers don0t -now what they really want Sta-eholders e6press re!uirements in their own terms Different sta-eholders may ha"e conflicting re!uirements 7rganisational and political factors may influence the system re!uirements he re!uirements change during the analysis process. Dew sta-eholders may emerge and the business en"ironment change The requirements analysis process

%:

R eq uirem en ts valid ati on D om ain un de rstand in g

R eq uirem en ts de fin itio n and sp ecifica tion

P rio ritiz ation

P roc ess en try

R eq uirem en ts co llection

C on flict res olutio n

C la ssific ation

The requirements analysis process activities Domain understanding Re!uirements collection Classification Conflict resolution Prioritisation Re!uirements chec-ing Techniques for requirement elicitation and analysis "iewpoint.oriented elicitation ethnography scenarios structured analysis methods *system models+ prototyping here is no uni"ersal method for re!uirement analysisE System models Different models may be produced during the re!uirements analysis acti"ity @ill be co"ered *ater Viewpoint-oriented elicitation Sta-eholders represent different ways of loo-ing at a problem or problem "iewpoints his multi.perspecti"e analysis is important as there is no single correct way to analyse system re!uirements Scenarios Descriptions of how a system is used in practice 2elpful in re!uirements elicitation as people can relate to these more easily than an abstract statement of what they re!uire from a system Cseful for adding detail to an outline re!uirements description %#

Scenario descriptions System state at the beginning of the scenario Dormal flow of e"ents in the scenario @hat can go wrong and how this is handled 7ther concurrent acti"ities System state on completion of the scenario Scenario based techniques use casesE e"ent scenarios '"ent scenarios may be used to describe how a system responds to the occurrence of some particular e"ent Csed in the Niewpoint 7riented Re!uirements Definition *N7RD+ method. thnography (n analyst spends time obser"ing and analysing how people actually worPeople do not ha"e to e6plain their worSocial and organisational factors of importance may be obser"ed Identifies implicit system re!uirements Ethnographic studies have shown that wor; is usuall* richer and more comple% than suggested #* simple s*stem models Scope of ethnography Re!uirements that are deri"ed from the way that people actually wor- rather than the way in which process definitions suggest that they ought to wor e.g. air.traffic controllers switch off flight path conflict alarms Re!uirements that are deri"ed from cooperation and awareness of other people0s acti"ities e.g. predict no. of aircraft entering their sector by getting information from neighbouring controllers and plan accordingly Dot suitable for using alone, has to be combined with some other techni!ue

<., RE;UIRE/ENTS 'A(IDATION

Concerned with showing that the re!uirements define the system that the customer really wants Re!uirements error costs are high so "alidation is "ery important /i6ing a re!uirements error after deli"ery may cost up to #:: times the cost of fi6ing an implementation error Types of requirements chec!ing Dalidit*. Does the system pro"ide the functions which best support the customer0s needsF %>

(onsistenc*. (re there any re!uirements conflictsF (ompleteness. (re all functions re!uired by the customer includedF +ealism. Can the re!uirements be implemented gi"en a"ailable budget and technology Derifia#ilit*. Can the re!uirements be chec-ed Requirements validation techniques

Re!uirements re"iews Systematic manual analysis of the re!uirements Prototyping Csing an e6ecutable model of the system to chec- re!uirements. est.case generation De"eloping tests for re!uirements to chec- testability (utomated consistency analysis Chec-ing the consistency of a structured re!uirements description Requirements reviews Regular re"iews while the re!uirements definition is being formulated Ioth client and contractor staff should be in"ol"ed in re"iews Re"iews may be forma* *with completed documents+ or informa*. ;ood communications between de"elopers, customers and users can resol"e problems at an early stage Review chec!s Nerifiability. Is the re!uirement realistically testableF Comprehensibility. Is the re!uirement properly understoodF raceability. Is the origin of the re!uirement clearly statedF (daptability. Can the re!uirement be changed without a large impact on other re!uirementsF "utomated consistency chec!ing
R e q uirem en ts inaform a l la ng ua ge R e q uirem en ts pr ob le mr e p ort

R eq uirem en ts pr oc ess or R e q uire m e n ts data ba se

R e q uirem en ts an alys e r

<.. RE;UIRE/ENTS /ANAGE/ENT

Re!uirements management is the process of managing changing re!uirements during the re!uirements engineering process and system de"elopment %%

Re!uirements are ine"itably incomplete and inconsistent Dew re!uirements emerge during the process as business needs change and a better understanding of the system is de"eloped Different "iewpoints ha"e different re!uirements and these are often contradictory #hy requirements change he priority of re!uirements from different "iewpoints changes during the de"elopment process System customers may specify re!uirements from a business perspecti"e that conflict with end.user re!uirements he business and technical en"ironment of the system changes during its de"elopment Requirements evolution
In itial un de rstand in g of prob le m C ha ng ed un de rst and in g of pr ob le m

In itial req uirem en ts

C ha ng ed req uirem en ts

T im e

nduring and volatile requirements En!$ring re?$irements. Stable re!uirements deri"ed from the core acti"ity of the customer organisation. )ay be deri"ed from domain models '.g. a hospital will always ha"e doctors, nurses, etc. 'o*ati*e re?$irements. Re!uirements which change de"elopment or when the system is in use. '.g. In a hospital, re!uirements deri"ed from health.care policy $lassification of volatile requirements )utable re!uirements Re!uirements that change due to the system0s en"ironment 'mergent re!uirements Re!uirements that emerge as understanding of the system de"elops Conse!uential re!uirements Re!uirements that result from the introduction of the computer system Compatibility re!uirements Re!uirements that depend on other systems or organisational processes %5 during

Requirements management planning During the re!uirements engineering process, you ha"e to plan: Re!uirements identification 2ow re!uirements are indi"idually identified ( change management process he process followed when analysing a re!uirements change raceability policies he amount of information about re!uirements relationships that is maintained C(S' tool support he tool support re!uired to help manage re!uirements change Traceability raceability is concerned with the relationships between re!uirements, their sources and the system design Source traceability 3in-s from re!uirements to sta-eholders who proposed these re!uirements Re!uirements traceability 3in-s between dependent re!uirements Design traceability 3in-s from the re!uirements to the design " traceability matri% Re?. i! 1.1 1.+ 1., +.1 +.+ +., ,.1 ,.+ 1.1 1.+ D 1., R D R R D R R +.1 +.+ +., R R D D D ,.1 ,.+ D

$"S tool support Re!uirements storage Re!uirements should be managed in a secure, managed data store @e need re!uirement databasesE Change management he process of change management is a wor-flow process whose stages can be defined and information flow between these stages partially automated raceability management (utomated retrie"al of the lin-s between re!uirements Requirements change management %H

Should apply to all proposed changes to the re!uirements Principal stages Problem analysis. Discuss re!uirements problem and propose change Change analysis and costing. (ssess effects of change on other re!uirements Change implementation. )odify re!uirements document and other documents to reflect change
R e v is e d r e q u i r e m e n t s

I d e n t if i e d p r o b le m P r o b l e m a n a l y s i sa n d c h a n g es p e c i f ic a t io n

C h a n g ea n a ly s i s a n dc o s ti n g

C h a n g e im p le m e n t a ti o n

JJJJJJJJ

C. S0STE/ /ODE(S
O6Fe%ti3es he obGecti"e of this chapter is to introduce a number of system models that may be de"eloped during the re!uirements engineering process. @hen you ha"e study the chapter, you will: %=

Cnderstand why its is important to establish the boundaries of a system and model its conte6tL Cnderstand the concepts of beha"ioural modeling, data modeling and obGect modelingL 2a"e been introduced to some of the notations defined in the Cnified )odeling 3anguage *C)3+ and how these notations may be used to de"elop system models.

Contents Conte6t models Ieha"ioural models Data models 7bGect models Structured methods System models (bstract descriptions of systems whose re!uirements are being analysed used to de"elop an understanding of the e6isting system or to specify the re!uired system used to communicate with others they simplify the system *by lea"ing out details+ and emphasise certain characteristics &ifferent perspectives Different models present the system from different perspecti"es '6ternal perspecti"e . showing the system0s conte6t or en"ironment Ieha"ioural perspecti"e . showing the beha"iour of the system Structural perspecti"e . showing the system or data architecture 'odel types (,ifferent approaches to a#straction Data f*ow mo!e* showing how the data is processed at different stages. Com osition mo!e* showing how entities are composed of other entities. Ar%hite%t$ra* mo!e* showing principal sub.systems. C*assifi%ation mo!e* showing how entities ha"e common characteristics. Stim$*$sGres onse mo!e* showing the system0s reaction to e"ents.

C.1 CONTEHT /ODE(S

Csed to illustrate the operational conte6t of a system . show what lies outside the system boundaries. Dot only technical factors affect system boundary positioning Social and organisational concerns %4

(rchitectural models show the system and its relationship with other systems. %ample( $onte%t of an "T' system

Security system Branch accounting system Auto-teller system Branch counter system Maintenance system Usage database Account database

(rchitectural models do not describe the system0s relationships with the other systems in the en"ironment 2ence, architectural models are supplemented by other models such as process models data.flow models Process models Process models show the o"erall process and the processes that are supported by the system Data flow models may be used to show the processes and the flow of information from one process to another quipment procurement process

%9

D elivery note Equipment spec. Che cked spec. G et cost estimate s Spec .+ supplier + estimate Supplier list Find suppliers Choose supplier D elivery note

Spec ify equipment required

V alidate specification

A ccept de livery of equipment O rde r notification Plac e equipment or de r

Che ck de livered items Insta llation instruc tions

Equipment spec. Supplier da ta ba se

O rde r de tails + Bla nk orde r form

Insta ll equipment Insta llation acceptance A ccept de livered equipment Equipment de tails Equipment da taba se

Che cked and signed orde r form

C.+ 7E&A'IOURA( /ODE(S

Ieha"ioural models are used to describe the o"erall beha"iour of a system. wo types of beha"ioural model are: Data processing models that show how data is processed as it mo"es through the systemL State machine models that show the systems response to e"ents.

&ata-processing models processing hese show the processing steps as data flows through a system Intrinsic part of many analysis methods Simple and intuiti"e notation that customers can understand easily *different notations are used in different methods for drawing D/Ds+ lements of a &F& Processes Change the data. 'ach process has one or more inputs and outputs Data stores used by processes to store and retrie"e data *files, DIs+ Data flows mo"ement of data among processes and data stores '6ternal entities outside things which are sources or destinations of data to the system %$ Data flow diagrams *D/D+ are used to model the system0s data

%ample( )rder processing &F&

Completed order form Signed order form V alidate order Signed order form Record order Order details Signed order form Adjust available budget Order amount + account details Orders file Budget file Send to supplier Checked and signed order + order notification

Order details + blank order form

Complete order form

&ata flow diagrams D/Ds model the system from a functional perspecti"e. rac-ing and documenting how the data associated with a process is helpful to de"elop an o"erall understanding of the system. Data flow diagrams may also be used in showing the data e6change between a system and other systems in its en"ironment.

*nsulin pump &F&

lood lood par ameters lood sugar sensor lood sugar anal ysis lood sugar lev el Insulin re%uirement computa tion Insulin Pump contr ol commands Insulin pump Insulin delivery contr oller Insulin re%uir ement

State machine models hese model the beha"iour of the system in response to e6ternal and internal e"ents. hey show the system0s responses to stimuli so are often used for modelling real.time systems. State charts are an integral part of the C)3 and are used to represent state machine models. State charts (llow the decomposition of a model into sub.models *see following slide+. 5:

( brief description of the actions is included following the Qdo0 in each state. Can be complemented by tables describing the states and the stimuli. 'icrowave oven model
0ull power 0ull power do1 set power 4 566 #imer 3umber 0 ull power 2alf power Set time do1 get number exit1 set time Door closed Door open 2alf po wer do1 set power 47 66 Door closed .peration do1 operate oven

8aiting do1 display time

2alf power

#imer

Star t "nabled do1 display 9$eady9 Door open

Cancel

8aiting do1 display time

Disa bled do1 display 98 aiting9

'icrowave oven state description State @aiting 2alf power /ull power Set time Disabled 'nabled 7peration Des%ri tion he o"en is waiting for input. he display shows the current time. he o"en power is set to %:: watts. he display shows Q2alf power0. he o"en power is set to =:: watts. he display shows Q/ull power0. he coo-ing time is set to the user0s input "alue. coo-ing time selected and is updated as the time is set. he display shows the

7"en operation is disabled for safety. Interior o"en light is on. Display shows QDot ready0. 7"en operation is enabled. Interior o"en light is off. Display shows QReady to coo-0. 7"en in operation. Interior o"en light is on. Display shows the timer countdown. 7n completion of coo-ing, the bu88er is sounded for H seconds. 7"en light is on. Display shows QCoo-ing complete0 while bu88er is sounding.

'icrowave oven stimuli Stim$*$s 5# Des%ri tion

2alf power /ull power imer Dumber Door open Door closed Start Cancel

he user has pressed the half power button he user has pressed the full power button he user has pressed one of the timer buttons he user has pressed a numeric -ey he o"en door switch is not closed he o"en door switch is closed he user has pressed the start button he user has pressed the cancel button

'icrowave oven operation

.peration Checking do1 check status #urntable fault Alarm do1 display event "mitter fault .< #ime Cook do1 run generator #imeout

Done do1 bu::er on for ; secs,

Door open Disabled 8aiting

Cancel

C., DATA /ODE(S

(lso called semantic data models Semantic data models

Csed to describe the logical structure of data processed by the system. (n entit*"relation"attri#ute model sets out the entities in the system, the relationships between these entities and the entity attributes @idely used in database design. Can readily be implemented using relational databases. +ibrary semantic model

5>

Article title authors pdf file fee 1 delivers n Order order number total payment date tax status n places 1 Buyer name address e-mail billing info 1 m

published-in fee-payable-to

Source n 1 title publisher issue date pages 1 in 1 Country

Copyright Agency 1 name has-links address

in

copyright form tax rate

&ata dictionaries Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included. (d"antages Support name management and a"oid duplicationL Store of organisational -nowledge lin-ing analysis, design and implementationL )any C(S' wor-benches support data dictionaries.

&ata dictionary entries Name

(rticle authors Iuyer fee.payable. to (ddress *Iuyer+

Des%ri tion

T1 e

Date
%:.#>.>::> %:.#>.>::> %:.#>.>::> >$.#>.>::>

Details of the published article that may be ordered by people 'ntity using 3IIS,S. he names of the authors of the article who may be due a (ttribute share of the fee. he person or organisation that orders a copy of the article. 'ntity

( #:# relationship between (rticle and the Copyright (gency Relation who should be paid the copyright fee. he address of the buyer. his is used to any paper billing (ttribute information that is re!uired.

%#.#>.>::>

C.. O7IECT /ODE(S

7bGect models describe the system in terms of obGect classes and their associations. 5%

(n obGect class is an abstraction o"er a set of obGects with common attributes and the ser"ices *operations+ pro"ided by each obGect. Narious obGect models may be produced Inheritance modelsL (ggregation modelsL Interaction models. Datural ways of reflecting the real.world entities manipulated by the system )ore abstract entities are more difficult to model using this approach 7bGect class identification is recognised as a difficult process re!uiring a deep understanding of the application domain 7bGect classes reflecting domain entities are reusable across systems Inheritan%e mo!e*s 7rganise the domain obGect classes into a hierarchy. Classes at the top of the hierarchy reflect the common features of all classes. 7bGect classes inherit their attributes and ser"ices from one or more super.classes. hese may then be specialised as necessary. Class hierarchy design can be a difficult process if duplication in different branches is to be a"oided. O6Fe%t mo!e*s an! the U/( he C)3 is a standard representation de"ised by the de"elopers of widely used obGect.oriented analysis and design methods. It has become an effecti"e standard for obGect.oriented modelling. Dotation 7bGect classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom sectionL Relationships between obGect classes *-nown as associations+ are shown as lines lin-ing obGectsL Inheritance is referred to as generalisation and is shown Qupwards0 rather than Qdownwards0 in a hierarchy. )b,ect models and the -'+

he C)3 is a standard representation de"ised by the de"elopers of widely used obGect.oriented analysis and design methods. It has become an effecti"e standard for obGect.oriented modelling. Dotation 7bGect classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom sectionL Relationships between obGect classes *-nown as associations+ are shown as lines lin-ing obGectsL Inheritance is referred to as generalisation and is shown Qupwards0 rather than Qdownwards0 in a hierarchy. +ibrary class hierarchy 55

=ibrary item Ca talogue n umber Ac%uisition da te Cost # ype Sta tus 3umber of copies Ac%uire >? Ca talo gue >? Dispose >? Issue >? $ eturn >?

Published item #itle Publisher

$ecor ded item #itle !edium

ook Author "dition Publica tion da te IS 3

!aga:ine @ ear Issue

0ilm Director Date of release Distributor

Computer program * ersion Platf orm

-ser class hierarchy

=ibrary user 3ame Address Phone $egistr ation & $egister >? De)r egister >?

$eader Affiliation

orrower Items on loan !ax, loans

Staf f Department Department phone

Student !a+or sub+ect 2ome ad dress

'ultiple inheritance

5H

Rather than inheriting the attributes and ser"ices from a single parent class, a system which supports multiple inheritance allows obGect classes to inherit from se"eral super. classes. his can lead to semantic conflicts where attributes?ser"ices with the same name in different super.classes ha"e different semantics. )ultiple inheritance ma-es class hierarchy reorganisation more comple6. 'ultiple inheritance
ook Author "dition Publication da te IS 3 *oice recording Speak er Duration $ecor ding da te

# alking book &# apes

)b,ect aggregation (n aggregation model shows how classes that are collections are composed of other classes. (ggregation models are similar to the part.of relationship in semantic data models. )b,ect aggregation
Study pack Course title 3umber @ear Instructor

Assignment Cr edits

.2P slides Slides

=ecture notes # ext

*ideota pe # ape ids ,

"xercises &Pr oblems Description

Solutions # ext Diagrams

)b,ect behaviour modelling

5=

( beha"ioural model shows the interactions between obGects to produce some particular system beha"iour that is specified as a use.case. Se!uence diagrams *or collaboration diagrams+ in the C)3 are used to model interaction between obGects. *ssue of electronic items
"cat1 Catalog 1=ibrary Item =ib'1 3etServer

1=ibrary User

=ookup Display Issue Issue licence Accept licence Compress

Deliver

C.< STRUCTURED /ET&ODS

Structured methods incorporate system modelling as an inherent part of the method. )ethods define: a set of models a process for deri"ing these models and rules and guidelines that should apply to the models. C(S' tools support system modelling as part of a structured method. Don.functional system re!uirements not modelled (ppropriateness Do not usually include information about whether a method is appropriate for a gi"en problem. oo much documentation Can be too detailed and difficult for users to understand. $"S wor!benches ( coherent set of tools that is designed to support related software process acti"ities such as analysis, design or testing. (nalysis and design wor-benches support system modelling during both re!uirements engineering and system design. 54

'ethod wea!nesses

hese wor-benches may support a specific design method or may pro"ide support for a creating se"eral different types of system model. "n analysis and design wor!bench
Data dictionary Structur ed diagramming tools $eport gener ation facilities

Code gener a tor

Central information repository

Auery langua ge facilities

0orms creation tools

Design- anal ysis and checking tools

ImportBexpor t facilities

"nalysis wor!bench components Diagram editors )odel analysis and chec-ing tools Repository and associated !uery language Data dictionary Report definition and generation tools /orms definition tools Import?e6port translators Code generation tools JJJJJJ

D. DESIGN ENGINEERING
59

he goal of design engineering is to produce a model or representation that e6hibits firmness, commodity, and delight. o accomplish this, a designer must practice di"ersification and then con"ergence. Di"ersification and Con"ergence . the !ualities which demand intuition and Gudgment are based on e6perience. Principles and heuristics that guide the way the model is e"ol"ed. Set of criteria that enables !uality to be Gudge. Process of iteration that ultimately leads to final design representation.

Design engineering for computer software changes continually as new methods, better analysis, and broader understanding e"ol"e. '"en today, most software design methodologies lac- the depth, fle6ibility, and !uantitati"e nature that are normally associated with more classical engineering design disciplines.

D.1 DESIGN #ROCESS AND DESIGN ;UA(IT0 The software design is an iterative process through which re&uirements are translated into a blueprint for constructing the software. hroughout the design process, the !uality of the e"ol"ing design is assessed with a series of formal technical re"iews or design. hree characteristics that ser"e as a guide for the e"aluation of a good design. he design must implement all of the e6plicit re!uirements contained in the analysis model, and it must accommodate all of the implicit re!uirements desired by the customer. he design must be a readable, understandable guide for those how generate code and for those who test and subse!uently support the software. he design should pro"ide a complete picture of the software, addressing the data, functional, and beha"ioral domains form an implementation perspecti"e.

;$a*it1 G$i!e*ines In order to e"aluate the !uality of a design representation, we must establish technical criteria for good design.

( design should e6hibit an architecture that *a+ has been created using recogni8able architectural styles or patterns. *b+ is composed of components that e6hibit good design characteristics. *c+ can be implemented in an e"olutionary fashion, thereby facilitating implementation and testing. ( design should be modularL that is, the software should be logically partitioned into elements or subsystems. ( design should contain distinct representations of data, architecture, interfaces, and components. ( design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recogni8able data patterns. 5$

( design should lead to components that e6hibit independent functional characteristics. ( design should lead to interfaces that reduce the comple6ity of connections between components and with the e6ternal en"ironment. ( design should be deri"ed using a repeatable method that is dri"en by information obtained during software re!uirements analysis. ( design should be represented using a notation that effecti"ely communicates its meaning. ;$a*it1 Attri6$tes 2ewlett Pac-ard de"eloped set of software !uality attributes name /CRPS. /unctionality, Csability, Reliability, Performance and Supportability. he /CRPS !uality attributes represent a target for all software design. Functionalit* is assessed by e"aluating the feature set and capabilities of the program, the generality of the functions that are deli"ered, and the security of the o"erall system. )sa#ilit* is assessed by considering human factors, o"erall aesthetics, consistency and documentation. +elia#ilit* is e"aluated by measuring the fre!uency and se"erity of failure, the accuracy of output results, the mean.time.to.failure *) /+, the ability to reco"er from failure and the predictability of the program. Performance is measuring by processing speed, response time, resource consumption, throughput and efficiency. Supporta#ilit* combines the ability to e6tend the program *e6tensibility+, adaptability, ser"iceability.these three attributes represent amore common term, maintainability.in addition, testability, compatibility, and configurability.

D.+ DESIGN CONCE#TS

/undamental software design concepts pro"ide the necessary frame wor- for Agetting it right.B (bstraction . )any le"els of abstraction can be posed. he highest le"el states the solution in broad terms using the language of the problem en"ironment. he lower le"el gi"es more detailed description of the solution. Procedural /#straction refers to a se!uence of instruction that ha"e specific and limited functions. ,ata /#straction is a named collection of data that describes a data obGect.

(rchitecture E pro"ides o"erall structure of the software and the ways in which the structure pro"ides conceptual integrity for a system. he goal of H:

software design is to deri"e and architectural rendering of a system which ser"es as a framewor- from which more detailed design acti"ities can be conducted. he (rchitectural design is represented by the following models Structural !odel O 7rgani8ed collection of program components. Framewor; !odel O Increases le"el of design abstraction by identifying repeatable architectural design framewor-s that are encountered in similar types of applications. ,*namic !odel O (ddresses the beha"ioral aspects of the program architecture. Process !odel O /ocuses on design of business or technical process that system must accommodate. Functional !odel O Csed to represent functional hierarchy of the system.

Patterns O ( pattern is a named nugget of insight which con"eys the essences of pro"en solutions to a recurring problem with a certain conte6t amidst competing concerns. he design pattern pro"ides a description that enables a designer to determine @hether the pattern is applicable to the current wor-F @hether the pattern can be reusedF @hether the pattern can ser"e as a guide for de"eloping a similar but functionally or structurally different patternF

)odularity O the software is di"ided into separately named and addressable components called modules that are integrated to satisfy problem re!uirements. Information 2iding O modules should be specified and designed so that information contained within a module is inaccessible to other modules that ha"e no need for such information. Information hiding pro"ides greatest benefits when modifications are re!uired during testing and software maintenance. /unctional Independence O is achie"ed by de"eloping modules with single minded function and an a"ersion to e6cessi"e interaction with other modules. Independence is assessed using two !ualitati"e criteria $ohesion O is a natural e6tension of information hiding concept, module performs single tas-, re!uiring little interaction with other components in other parts of a program. $oupling O interconnection among modules and a software structures, depends on interface comple6ity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

H#

Refinement O is a process of elaboration. Refinement causes the designer to elaborate on original statement, pro"iding more and more detailed as each successi"e refinement occurs. Refactoring O important design acti"ity suggested for agile methods, refactoring is a recogni8ation techni!ue that simplifies design of a component without changing its function or beha"ior. ARefactoring is a process of changing a software system in such away that it does not alter the e6ternal beha"ior of the code yet impro"es its internal structure. Design Classes O describes some element of problem domain, focusing on aspects of the problem that are user or customer "isible. he software team must define a set of design classes that *#+ Refine the analysis classes by pro"iding design detail that will enable the classes to be implemented and *>+ Create a new set of design classes that implement a software infrastructure to support the business solution. /i"e different types of design classes each representing a different layer of the design architecture is suggested )ser Interface classes define all abstractions that are necessary for 2uman Computer Interaction *2CI+. In many cases, 2CI occurs within the conte6t of a metaphor *e.g., a chec-boo-, an order form, a fa6 machine+ and the design classes for the interface may be "isual representations of the elements of the metaphor. -usiness domain classes are often refinements of the analysis classes defined earlier. he classes identify the attributes and ser"ices *methods+ that are re!uired to implement some element of the business domain. Process classes implement lower.le"el business abstractions re!uired to fully manage the business domain classes. Persistent classes represent data stores *e.g, a database+ that will persist beyond the e6ecution of the software. S*stem classes implement software management and control functions that enable the system to operate and communicate within its computing en"ironment and with the outside world.

D., T&E DESIGN /ODE(

he design model can be "iewed in two in two different dimensions. he process dimension indicates the e"olution of the design model as design tas-s are e6ecuted as part of the software process. he abstraction dimension represents the le"el of detail as each element of the analysis model is transformed into a design e!ui"alent and then refined iterati"ely.

H>

high
analysis model
class diagrams analysis packages C$C models collaboration diagrams data flow diagrams control)flow diagrams processing narratives

use)cases ) text use)case diagrams activity diagrams swim lane diagrams collaboration diagrams state diagrams se%uence diagrams

class diagrams analysis packages C$C models collaboration diagrams data flow diagrams control)flow diagrams processing narratives state diagrams se%uence diagrams

$e%uirements1 constraints interoperability targets and configuration

design class reali:ations subsystems collaboration diagrams

technical interface design 3avigation design /UI design

component diagrams design classes activity diagrams se%uence diagrams

design class reali:ations subsystems collaboration diagrams component diagrams design classes activity diagrams se%uence diagrams

design model
refinements to: design class reali:ations subsystems collaboration diagrams refinements to: component diagrams design classes activity diagrams se%uence diagrams

low

deployment diagrams

architecture elements

interface elements

component)level elements

deployment)level elements

process dimension

DATA DESIGN E(E/ENTS 3i-e other software engineering acti"ities, data design creates a model of data and?or information that is represented at a high le"el of abstraction. (t the program component le"el, the design of data structures and the associated algorithms re!uired to manipulate them is essential to the creation of high.!uality applications. (t the application le"el, the translation of a data model into a database is pi"otal to achie"ing the business obGecti"es of a system. (t the business le"el, the collection of information stored in disparate databases and reorgani8ed into a Adata warehouseB enables data mining or -nowledge disco"ery that can ha"e an impact on the success of the business itself. ARC&ITECTURA( DESIGN E(E/ENTS he architectural design for software is the e!ui"alent to the floor plan of a house. he floor plan depicts the o"erall layout of the rooms, their si8e, shape, and relationship to one another, and the doors and windows that allow mo"ement into and out of the rooms. he floor plan gi"es us an o"erall "iew of the house. (rchitectural design elements gi"e us an o"erall "iew of the software. H%

 sources:

he architectural model is deri"ed from three *#+ Information about the application domain for the software to be builtL *>+ Specific analysis model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand *%+ the a"ailability of architectural patterns and styles.

INTERFACE DESIGN E(E/ENTS he interface design for software is the e!ui"alent to a set of detailed drawing for the doors, windows and e6ternal utilities of a house. hese drawings depict the si8e and shape of doors and windows, the manner in which they operate, the way in which utilities connections *e.g., water, electrical, gas, and telephone+ come into the house and are distributed among the rooms depicted in the floor plan. here are three important elements of interface design: *#+ the user interface *CI+ *>+ e6ternal interfaces to other systems, de"ices, networ-s, or other producers or consumers of informationL and *%+ internal interfaces between "arious design components. hese interface design elements allow the software to communicate e6ternally and enable internal communication and collaboration among the components that populate the software architecture.

H5

!obilePhone 8irelessPDA

Cont rolPanel
=CDdisplay ="Dindicators keyPadCharacteristics speaker wirelessInterface read<eyStroke>? decode<ey >? displayStatus>? light="Ds>? sendControl!sg >?

< eyPad

DDint erfaceEE < eyPad

read<eystroke >? decode<ey>?

0igure C ,5 U!= int erface represent at ion for Cont rolPanel

CO/#ONENT4(E'E( DESIGN E(E/ENTS he component.le"el design for software is e!ui"alent to a set of detailed drawings for each room in a house. hese drawing depict wiring and plumbing within each room, the location of electrical receptacles and switches, faucets, sin-s, showers, tubs, drains, cabinets, and closets. hey also describe the flooring to be used, the moldings to be applied, and e"ery other detail associated with a room. he component.le"el design for software fully describes the internal detail of each software component.

Sensor!anagement

Sensor

DE#(O0/ENT4(E'E( DESIGN E(E/ENTS Deployment le"el design elements indicates how software functionality and subsystems will be allocates within the physical computing en"ironment that will support the software.

HH

Cont rol Panel

Security

CPI server
homeownerAccess

Personal computer
externalAccess

Security

Surveillance

home! anagement

communication

0igure C ,F U!= deployment diagram for SafeHome

JJJJJJJ

J. CREATING AN ARC&ITECTURA( DESIGN

Design is an acti"ity concerned with ma-ing maGor decisions, often of s structural nature. It shares with programming a concern for abstracting information representation and processing se!uences, but the le"el of detail is !uite different at the e6tremes. Design builds coherent, well.planned representations of programs that concentrate on the interrelationships of parts at the higher le"el and the logical operations in"ol"ed at the lower le"els. .hat is /rchitectural designF .ho does itF .h* is it importantF .hat are the stepsF .hat is the wor; productF Gow do I ensure that I have done it rightF

J.1 SOFTWARE ARC&ITECTURE

'ffecti"e software architecture and its e6plicit representation and design ha"e become dominant themes in software engineering. Wh1 Ar%hite%t$re? H=

he architecture is not the operational software. Rather, it is a representation that enables a software engineer to: *#+ analy8e the effecti"eness of the design in meeting its stated re!uirements, *>+ consider architectural alternati"es at a stage when ma-ing design changes is still relati"ely easy, and *%+ reduce the ris-s associated with the construction of the software.

Wh1 is Ar%hite%t$re Im ortant? Representations of software architecture are an enabler for communication between all parties *sta-eholders+ interested in the de"elopment of a computer.based system. he architecture highlights early design decisions that will ha"e a profound impact on all software engineering wor- that follows and, as important, on the ultimate success of the system as an operational entity. (rchitecture Aconstitutes a relati"ely small, intellectually graspable model of how the system is structured and how its components wor- togetherB.

J.+ DATA DESIGN he data design action translates data obGects defined as part of the analysis model into data structures at the software component le"el and, when necessary, a database architecture at the application le"el. At the ar%hite%t$ra* *e3e* K Design of one or more databases to support the application architecture Design of methods for Qmining0 the content of multiple databases na"igate through e6isting databases in an attempt to e6tract appropriate business.le"el information Design of a data warehousePa large, independent database that has access to the data that are stored in databases that ser"e the set of applications re!uired by a business

At the %om onent *e3e* K refine data obGects and de"elop a set of data abstractions implement data obGect attributes as one or more data structures re"iew data structures to ensure that appropriate relationships ha"e been established simplify data structures as re!uired he systematic analysis principles applied to function and beha"ior should also be applied to data. (ll data structures and the operations to be performed on each should be identified. ( data dictionary should be established and used to define both data and program design. 3ow le"el data design decisions should be deferred until late in the design process. H4

he representation of data structure should be -nown only to those modules that must ma-e direct use of the data contained within the structure. ( library of useful data structures and the operations that may be applied to them should be de"eloped. ( software design and programming language should support the specification and reali8ation of abstract data types.

J., ARC&ITECTURA( ST0(ES 'ach style describes a system category that encompasses: *#+ a set of components *e.g., a database, computational modules+ that perform a function re!uired by a system, *>+ a set of connectors that enable Acommunication, coordination and cooperationB among components, *%+ constraints that define how components can be integrated to form the system, and *5+ semantic models that enable a designer to understand the o"erall properties of a system by analy8ing the -nown properties of its constituent parts. Data.centered architectures Data flow architectures Call and return architectures 7bGect.oriented architectures 3ayered architectures Data4Centere! Ar%hite%t$re

( data store *e.g., a file or database+ resides at the center of this architecture and is accessed fre!uently by other components that update, add, delete, or otherwise modify data within the store. he following figure illustrates a typical data.centered style.

Data F*ow Ar%hite%t$re H9

his architecture is applied when input data are to be transformed through a series of computational or manipulati"e components into output data. ( pipe and filter structure has a set of components, called filters, connected by pipes that transmit data from one component to the ne6t. If the data flow degenerates into a single line of transforms, it is termed batch se!uential.

Ca** an! Ret$rn Ar%hite%t$re his architectural style enables a software designer *system architect+ to achie"e a program structure that is relati"ely easy to modify and scale. wo substyles e6ist within this category: !ain programCsu#program architecture. his classic program structure decomposes function into a control hierarchy where a AmainB program in"o-es a number of program components, which in turn may in"o-e still other components. he following figure illustrates architecture of this type. +emote procedure call architecture. he components of main program ?subprogram architecture are distributed across multiple computers on a networ-.

H$

O6Fe%t4oriente! ar%hite%t$re he component of a system encapsulates data and the operations that must be applied to manipulate the data communication and coordination between components is accomplished "ia message passing. (a1ere! Ar%hite%t$re he basic structure of a layered architecture is illustrated in the following figure. ( number of different layers are defined, each accomplishing operations that progressi"ely become closer to the machine instruction set. (t the outer layer, components ser"ice user interface operations. (t the inner layer, components perform operating system interfacing. Intermediate layers pro"ide utility ser"ices and application software functions.

=:

J.. ARC&ITECTURA( #ATTERNS ConcurrencyPapplications must handle multiple tas-s in a manner that simulates parallelism operating s*stem process management pattern tas; scheduler pattern PersistencePData persists if it sur"i"es past the e6ecution of the process that created it. wo patterns are common: a data#ase management s*stem pattern that applies the storage and retrie"al capability of a DI)S to the application architecture an application level persistence pattern that builds persistence features into the application architecture DistributionP the manner in which systems or components within systems communicate with one another in a distributed en"ironment ( #ro;er acts as a Qmiddle.man0 between the client component and a ser"er component.

J.< ARC&ITECTURA( DESIGN he software must be placed into conte6t the design should define the e6ternal entities *other systems, de"ices, people+ that the software interacts with and the nature of the interaction ( set of architectural archetypes should be identified (n archet*pe is an abstraction *similar to a class+ that represents one element of system beha"ior he designer specifies the structure of the system by defining and refining software components that implement each archetype Ar%hite%t$ra* ConteBt ( system engineer must model conte6t. ( system conte6t diagram accomplishes this re!uirement by representing the flow of information into and out of the system, the user interface and rele"ant support processing. (t the architectural design le"el, a software architect uses an architectural conte6t diagram *(CD+ to model the manner in which software interacts with entities e6ternal to its boundaries. he generic structure of the architectural conte6t diagram is illustrated in /igure.

=#

Safehome Product

Internet)based system

control panel homeowner

target system1 Security 0unction uses uses sensors

uses

surveillance function peers

sensors

Ar%het1 es the SafeGome home security function, we might define the following archetypes: Dode O Represents a cohesi"e collection of input and output elements of the home security function. /or e6ample a node might be comprised of *#+ "arious sensors and *>+ a "ariety of alarm *output+ indicators. Dectector O (n abstraction that encompasses all sensing e!uipment that feeds information into the target system. Indicator O (n abstraction that represents all mechanism *e.g., alarm siren, flashing lights, bell+ for indicating that an alarm condition is occurring. Controller O (n abstraction that depicts the mechanism that allows the arming or disarming of a node. If controllers reside on a networ-, they ha"e the ability to communicate with one another.

=>

C ontroller

communica tes w ith

3ode

Detector

Indica tor

0igure '6,G U != rela tionships f or Sa fe2ome security function a rchetypes >a da pted from H .S66I?

Refining the Ar%hite%t$re into Com onents

Continuing the SafeGome home security function e6ample, we might define the set of top.le"el components that address the following functionality. E%ternal communication management O coordinates communication of the security function with e6ternal entities, for e6ample, internet.based systems. '6ternal alarm notification. (ontrol panel processing O manages all control panel functionality. ,etector management O coordinates access to all detectors attached to the system. /larm processing O "erifies and acts on all alarm conditions.
Safe2ome "xecutive 0unction selection
"xt ernal Communicat ion !anagement

Security

Surveillance

2ome management

/UI

Internet Interface
Control panel processing detector management alarm processing

Des%ri6ing Instantiations of the S1stem =%

he instantiation of the architecture means that the architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate. /ig Illustrates an instantiation of the SafeGome architecture for the security system. Components shown in figure are refined further to show additional detail.
Safe2ome "xecutive

"xternal Communication !anagement

Security / UI Internet Interface

Cont rol panel processing det ect or management alarm processing

<ey pad processing

scheduler

phone communicat ion

CP display funct ions

alarm sensor sensor sensor sensor sensor sensor sensor sensor sensor

JJJJJJJJJ

A. O7IECT4ORIENTED DESIGN
O7IECTI'ES =5

o e6plain how a software design may be represented as a set of interacting obGects that manage their own state and operations. o describe the acti"ities in the obGect.oriented design process. o introduce "arious models that can be used to describe an obGect.oriented design. o show how the C)3 may be used to represent these models. Dot about implementation, but about design. TO#ICS CO'ERED 7bGects and obGect classes (n obGect.oriented design process Design e"olution O7IECT4ORIENTED DE'E(O#/ENT 7bGect.oriented analysis, design and programming are related but distinct. 77( is concerned with de"eloping an obGect model of the application domain. 77D is concerned with de"eloping an obGect.oriented system model to implement re!uirements. 77P is concerned with realising an 77D using an 77 programming language such as &a"a or CUU. Chara%teristi%s of OOD 7bGects are abstractions of real.world or system entities and manage themsel"es. 7bGects are independent and encapsulate state and representation information. System functionality is e6pressed in terms of obGect ser"ices. Shared data areas are eliminated. 7bGects communicate by message passing *no global "ariables+. 7bGects may be distributed and may e6ecute se!uentially or in parallel. Intera%ting o6Fe%ts
o '1 C' sta te o ' o ps'>? o 71C7 sta te o 7 o ps7 >? o J1 CJ sta te o J o psJ > ?

o (1 C7 sta t e o ( o ps7 >?

o 51 C' sta te o 5 o ps' > ?

o ;1C; sta te o ; o ps; > ?

A!3antages of OOD 'asier maintenance. 7bGects may be understood as stand.alone entities. 7bGects are potentially reusable components. /or some systems, there may be an ob"ious mapping from real world entities to system obGects. =H

A.1 O7IECTS AND O7IECT C(ASSES

7bGects are entities in a software system which represents instances of real.world and system entities. 7bGect classes are templates for obGects. hey may be used to create obGects. 7bGect classes may inherit attributes and ser"ices from other obGect classes.
/n o#8ect is an entit* that has a state and a defined set of operations which operate on that state. The state is represented as a set of o#8ect attri#utes. The operations associated with the o#8ect provide services to other o#8ects (clients which re&uest these services when some computation is re&uired. 0#8ects are created according to some o#8ect class definition. /n o#8ect class definition serves as a template for o#8ects. It includes declarations of all the attri#utes and services which should #e associated with an o#8ect of that class.

The Unifie! /o!e*ing (ang$age Se"eral different notations for describing obGect.oriented designs were proposed in the #$9:s and #$$:s. he Cnified )odeling 3anguage is an integration of these notations. It describes notations for a number of different models that may be produced during 77 analysis and design. It is now a de facto standard for 77 modelling. Em *o1ee o6Fe%t %*ass 8U/(9
"mployee name1 string address1 string date.f ir th1 Date employee3o1 integer socialSecurity3o1 string depar tment1 Dept manager1 "mployee salar y1 integer status1 Kcurrent- left- retiredL taxCode1 integer , ,, +oin >? leave >? retire >? changeDetails >?

O6Fe%t %omm$ni%ation Conceptually, obGects communicate by message passing. )essages he name of the ser"ice re!uested by the calling obGectL ==

Copies of the information re!uired to e6ecute the ser"ice and the name of a holder for the result of the ser"ice. In practice, messages are often implemented by procedure calls Dame V procedure nameL Information V parameter list. /essage eBam *es Call a method associated with a buffer ?? obGect that returns the ne6t "alue ?? in the buffer " V circularIuffer.;et *+ L ?? Call the method associated with a ?? thermostat obGect that sets the ?? temperature to be maintained thermostat.set emp *>:+ L

Genera*isation an! inheritan%e 7bGects are members of classes that define attribute types and operations. Classes may be arranged in a class hierarchy where one class *a super.class+ is a generalisation of one or more other classes *sub.classes+. ( sub.class inherits the attributes and operations from its super class and may add new methods or attributes of its own. ;eneralisation in the C)3 is implemented as inheritance in 77 programming languages. A genera*isation hierar%h1
"mplo yee

!anager budgetsControlled dateAppointed

Programmer pro+ect prog=anguages

Pro+ect !anager pro+ects

Dept, !anager dept

Strateg ic !anager responsibilities

A!3antages of inheritan%e It is an abstraction mechanism which may be used to classify entities. It is a reuse mechanism at both the design and the programming le"el. he inheritance graph is a source of organisational -nowledge about domains and systems. =4

#ro6*ems with inheritan%e 7bGect classes are not self.contained. hey cannot be understood without reference to their super.classes. he inheritance graphs of analysis, design and implementation ha"e different functions and should be separately maintained.

A.+ AN O7IECT4ORIENTED DESIGN #ROCESS

Structured design processes in"ol"e de"eloping a number of different system models. hey re!uire a lot of effort for de"elopment and maintenance of these models and, for small systems, this may not be cost.effecti"e. 2owe"er, for large systems de"eloped by different groups design models are an essential communication mechanism. #ro%ess stages 2ighlights -ey acti"ities Define the conte6t and modes of use of the systemL Design the system architectureL Identify the principal system obGectsL De"elop design modelsL Specify obGect interfaces. Weather s1stem !es%ri tion
( weather mapping system is re!uired to generate weather maps on a regular basis using data collected from remote, unattended weather stations and other data sources such as weather obser"ers, balloons and satellites. @eather stations transmit their data to the area computer in response to a re!uest from that machine.

Data display layer wheredata and integrates he area computer system "alidates the collected concerned with preparing and it with the data from different sources. are he integrated data is archi"ed and, using data ob+ects Msubsystem from this archi"e and a digitised map database a set of local weather presenting the data in a maps is created. D )aps may be printed for distribution on form a special.purpose map printer or may be N ata human) readable displayed in a number of different formats. display
S1stem %onteBt an! mo!e*s of $se

De"elop an understanding of the relationships between the software being Msubsystem are concerned with storing thedesigned ob+ects andD its e6ternal en"ironment for future processing N ata data System conte6t archiving ( static model that describes other systems in the en"ironment. Cse a subsystem model to show other systems. /ollowing slide shows the systems Data processing layer where around the weather station system. are concerned with checking Msubsystem ob+ects )odel of system use inte rating the collected D ata and N ( dynamic model that describes how the system interacts with its processing g to show data en"ironment. Cse use.cases interactions (a1ere! ar%hite%t$re Data collection layer where

Data archiving layer where

Msubsystem D N ata collection

are concerned with ac%uiring ob+ects from remote sources data

=9

 S$6s1stems in the weather ma

MsubsystemN Data collection .bserver Comms 8eather station alloon Satellite

ing s1stem
MsubsystemN Data display User User inter face inter face !ap !ap display !ap printer

MsubsystemN Data processing Data checking Data integ ration

MsubsystemN Data archiving Data Data storage storage !ap store Data store

Use4%ase mo!e*s Cse.case models are used to represent each interaction with the system. ( use.case model shows the system features as ellipses and the interacting entity as a stic- figure. Use4%ases for the weather station

=$

Star tup

Shutdown

$epor t

Calibrate

# est

Use4%ase !es%ri tion

S1stem @eather station Use4%ase Report A%tors @eather data collection system, @eather station Data he weather station sends a summary of the weather data that has been collected from the instruments in the collection period to the weather data collection system. he data sent are the ma6imum minimum and a"erage ground and air temperatures, the ma6imum, minimum and a"erage air pressures, the ma6imum, minimum and a"erage wind speeds, the total rainfall and the wind direction as sampled at H minute inter"als. Stim$*$s he weather data collection system establishes a modem lin- with the weather station and re!uests transmission of the data. Res onse he summarised data is sent to the weather data collection system Comments @eather stations are usually as-ed to report once per hour but this fre!uency may differ from one station to the other and may be modified in future.

Ar%hite%t$ra* !esign 7nce interactions between the system and its en"ironment ha"e been understood, you use this information for designing the system architecture. ( layered architecture as discussed in Chapter ## is appropriate for the weather station Interface layer for handling communicationsL Data collection layer for managing instrumentsL Instruments layer for collecting data. here should normally be no more than 4 entities in an architectural model.

Weather station ar%hite%t$re

4:

8eather station !anages all external communications Collects and summarises weather data Package of instruments for raw data collections

MsubsystemN Inter face

MsubsystemN Data collection

MsubsystemN Instruments

O6Fe%t i!entifi%ation Identifying obGects *or obGect classes+ is the most difficult part of obGect oriented design. here is no Wmagic formulaW for obGect identification. It relies on the s-ill, e6perience and domain -nowledge of system designers. 7bGect identification is an iterati"e process. ,ou are unli-ely to get it right first time. roa%hes to i!entifi%ation

Cse a grammatical approach based on a natural language description of the system *used in 2ood 77D method+. Iase the identification on tangible things in the application domain. Cse a beha"ioural approach and identify obGects based on what participates in what beha"iour. Cse a scenario.based analysis. he obGects, attributes and methods in each scenario are identified. Weather station !es%ri tion @eather station is a pac-age of software controlled instruments which collects data, performs some data processing and transmits this data for further processing. he instruments include air and ground thermometers, an anemometer, a wind "ane, a barometer and a rain gauge. Data is collected periodically. @hen a command is issued to transmit the weather data, the weather station processes and summarises the collected data. he summarised data is transmitted to the mapping computer when a re!uest is recei"ed. Weather station o6Fe%t %*asses ;round thermometer, (nemometer, Iarometer (pplication domain obGects that are Qhardware0 obGects related to the instruments in the system. @eather station 4#

he basic interface of the weather station to its en"ironment. It therefore reflects the interactions identified in the use.case model. @eather data 'ncapsulates the summarised data from the instruments. Weather station o6Fe%t %*asses

8eatherStatio identifie r repo t8 eather r >? calibrate >instruments? test >? sta tup >instruments? r shutdown
>instruments? n

8eatherDa ta air# empe ature r s ground empe ature # r s windSpee ds windDirectio ns pressur es rainf all collect >? summarise >? Anemomeer t windSpee d windDirecti on test >? ar ome er t pressur e heigh t test >? calib ate r >?

/roun d thermom er et atur tempe r e test >? ate calib r >?

F$rther o6Fe%ts an! o6Fe%t refinement Cse domain -nowledge to identify more obGects and operations @eather stations should ha"e a uni!ue identifierL @eather stations are remotely situated so instrument failures ha"e to be reported automatically. herefore attributes and operations for self.chec-ing are re!uired. Design mo!e*s

Design models show the obGects and obGect classes and relationships between these entities. Static models describe the static structure of the system in terms of obGect classes and relationships. Dynamic models describe the dynamic interactions between obGects. EBam *es of !esign mo!e*s 4>

Sub.system models that show logical groupings of obGects into coherent subsystems. Se!uence models that show the se!uence of obGect interactions. State machine models that show how indi"idual obGects change their state in response to e"ents. 7ther models include use.case models, aggregation models, generalisation models, etc. S$6s1stem mo!e*s Shows how the design is organised into logically related groups of obGects. In the C)3, these are shown using pac-ages . an encapsulation construct. his is a logical model. he actual organisation of obGects in the system may be different. Weather station s$6s1stems
MsubsystemN Interface MsubsystemN Data collection

CommsController

8eatherData

8eatherStation

Instrument Status

MsubsystemN Instruments Air thermometer

$ain/auge

Anemometer

/round thermometer

arometer

8ind*ane

Se?$en%e mo!e*s Se!uence models show the se!uence of obGect interactions that ta-e place 7bGects are arranged hori8ontally across the topL ime is represented "ertically so models are read top to bottomL Interactions are represented by labelled arrows, Different styles of arrow represent different types of interactionL ( thin rectangle in an obGect lifeline represents the time when the obGect is the controlling obGect in the system. 4%

Data %o**e%tion se?$en%e

re%uest >repor

1 CommsControll er t ? repo t r >?

1 eatherStati 8 on

1 1 8eatherData 8

acknowledge >?

summarise >?

reply >repor acknowledge >?

t ?

send >repor

t ?

State%harts Show how obGects respond to different ser"ice re!uests and the state transitions triggered by these re!uests If obGect state is Shutdown then it responds to a Startup*+ messageL In the waiting state the obGect is waiting for further messagesL If report@eather *+ then system mo"es to summarising stateL If calibrate *+ the system mo"es to a calibrating stateL ( collecting state is entered when a cloc- signal is recei"ed. Weather station state !iagram

45

.peration

calibrate >?

Calibrating calibration .<

Shutdown

star tup >?

8 aiting

test >? transmission done

# esting test complete

shutdown >?

#ransmitting clock collection done report8 eather >? weather summary complete

Summarising Collecting

O6Fe%t interfa%e s e%ifi%ation 7bGect interfaces ha"e to be specified so that the obGects and other components can be designed in parallel. Designers should a"oid designing the interface representation but should hide this in the obGect itself. 7bGects may ha"e se"eral interfaces which are "iewpoints on the methods pro"ided. he C)3 uses class diagrams for interface specification but &a"a may also be used.

Weather station interfa%e interface @eatherStation S public "oid @eatherStation *+ L public "oid startup *+ L public "oid startup *Instrument i+ L public "oid shutdown *+ L public "oid shutdown *Instrument i+ L public "oid report@eather * + L public "oid test *+ L public "oid test * Instrument i + L public "oid calibrate * Instrument i+ L public int getID *+ L T ??@eatherStation

A., DESIGN E'O(UTION

2iding information inside obGects means that changes made to an obGect do not affect other obGects in an unpredictable way. 4H

(ssume pollution monitoring facilities are to be added to weather stations. hese sample the air and compute the amount of different pollutants in the atmosphere. Pollution readings are transmitted with weather data. Changes re?$ire! (dd an obGect class called (ir !uality as part of @eatherStation. (dd an operation report(ir<uality to @eatherStation. )odify the control software to collect pollution readings. (dd obGects representing pollution monitoring instruments. #o**$tion monitoring

8eatherStation identifier repo t8eather repo tAirAuality r >? calibrate >instruments? r >? test sta tup >instruments? >? shutdown >instruments? r

Air %uality 3.Dat s amo eDat ben k eneDat a : a collect summarise >? >?

Pollution monitoring instruments

JJJJJ

3.meter

Smoke !eter en:ene!ete r

LLLLLLLLL

1:. #ERFOR/ING USER INTERFACE DESIGN

Cser Interface design create an effecti"e communication medium between a human and a computer. /ollowing a set of interface design principles, design identifies 4=

interface obGects and actions and then creates a screen layout that forms the basis for a user interface prototype. Interfa%e Design 'asy to learnF 'asy to useF 'asy to understandF Typical &esign rrors lac- of consistency too much memori8ation no guidance ? help no conte6t sensiti"ity poor response (rcane?unfriendly

1:.1 GO(DEN RU(ES

Place the user in control Reduce the user0s memory load )a-e the interface consistent #*a%e the User in Contro* Define interaction modes in a way that does not force a user into unnecessary or undesired actions. Pro"ide for fle6ible interaction. (llow user interaction to be interruptible and undoable. Streamline interaction as s-ill le"els ad"ance and allow the interaction to be customi8ed. 2ide technical internals from the casual user. Design for direct interaction with obGects that appear on the screen. meaningful conte6t. applications. If past interacti"e models ha"e created user e6pectations, do not ma-e changes unless there is a compelling reason to do so. 44 )aintain consistency across a family of Re!$%e the User)s /emor1 (oa! Reduce demand on short.term memory. 'stablish meaningful defaults. Define shortcuts that are intuiti"e. he "isual layout of the interface should be based on a real world metaphor. Disclose information in a progressi"e fashion. /a"e the Interfa%e Consistent (llow the user to put the current tas- into a

1:.+ USER INTERFACE ANA(0SIS AND DESIGN

he o"erall process for analy8ing and designing a user interface begins with the creation of different models of system function. Interfa%e Ana*1sis an! Design /o!e*s Cser model P a profile of all end users of the system Design model P a design reali8ation of the user model )ental model *system perception+ P the user0s mental image of what the interface is Implementation model P the interface Aloo- and feelB coupled with supporting information that describe interface synta6 and semantics. User Interfa%e Design #ro%ess he analysis and design process for user interfaces is iterati"e and can be represented using a spiral model. he user interface analysis and design process encompasses four distinct framewor- acti"ities. Cser, tas- and en"ironment analysis and modeling. Interface design. Interface construction *implementation+. Interface "alidation.

he analysis of the user en"ironment focuses on the physical wor- en"ironment. (mong the !uestions to be as-ed are @here will the interface be located physicallyF @ill the user be sitting, standing or performing other tas-s unrelated to the interfaceF Does the interface hardware accommodate space, light or noise constraintsF (re there special human factors consideration dri"en by en"ironmental factorsF

he information gathered as part of the analysis acti"ity is used to create an analysis model for the interface. he goal of interface design is to define a set of interface obGects and actions *and their screen representations+ that enable a user to perform all defined tas-s in a manner that meets e"ery usability goal defined for the system. Nalidation focuses on *#+ the ability of the interface to implement e"ery user tas- correctly, to accommodate all tas- "ariations, and to achie"e all general user re!uirements. *>+ the degree to which the interfaced is easy to use and easy to learn *%+ the users acceptance of the interface as a useful tool in their wor-. 49

1:., INTERFACE ANA(0SIS

Interface analysis means understanding the people *end.users+ who will interact with the system through the interfaceL the tas-s that end.users must perform to do their wor-, the content that is presented as part of the interface the en"ironment in which these tas-s will be conducted. User Ana*1sis (re users trained professionals, technician, clerical, or manufacturing wor-ersF @hat le"el of formal education does the a"erage user ha"eF (re the users capable of learning from written materials or ha"e they e6pressed a desire for classroom trainingF (re users e6pert typists or -eyboard phobicF @hat is the age range of the user communityF @ill the users be represented predominately by one genderF 2ow are users compensated for the wor- they performF Do users wor- normal office hours or do they wor- until the Gob is doneF Is the software to be an integral part of the wor- users do or will it be used only occasionallyF @hat is the primary spo-en language among usersF @hat are the conse!uences if a user ma-es a mista-e using the systemF (re users e6perts in the subGect matter that is addressed by the systemF Do users want to -now about the technology the sits behind the interfaceF

Tas" Ana*1sis an! /o!e*ing (nswers the following !uestions 1 @hat wor- will the user perform in specific circumstancesF @hat tas-s and subtas-s will be performed as the user does the wor-F @hat specific problem domain obGects will the user manipulate as wor- is performedF @hat is the se!uence of wor- tas-sPthe wor-flowF @hat is the hierarchy of tas-sF Cse.cases define basic interaction 4$

as- elaboration refines interacti"e tas-s 7bGect elaboration identifies interface obGects *classes+ @or-flow analysis defines how a wor- process is completed when se"eral people *and roles+ are in"ol"ed Swim*ane Diagram
pat ient pharmacist physician

r e % u e st s t h at a p re scr ip t io n b e re f ille d

d e t e r min e s st at u s o f p re scr ip t io n

no refills rem a ining refills rem a ining

ch e cks p at ie n t r e co rd s

a pproves refill

ch e cks in v e n t o ry f o r re f ill o r alt e r n at iv e

refill not a llowed

r e ce iv e s o u t o f st o ck n o t if icat io n

out of stock

e v alu at e s alt e rn at iv e me d icat io n

alternative available in stock

r e ce iv e s t ime B d at e t o p ick u p

none

p icks u p p r e scr ip t io n

f ills p re scrip t io n

r e ce iv e s r e % u e st t o co n t act p h y sician

0igure '(,(

Swimlane diagram for prescript ion refill funct ion

Ana*1sis of Dis *a1 Content

9:

(re different types of data assigned to consistent geographic locations on the screen *e.g., photos always appear in the upper right hand corner+F Can the user customi8e the screen location for contentF Is proper on.screen identification assigned to all contentF If a large report is to be presented, how should it be partitioned for ease of understandingF @ill mechanisms be a"ailable for mo"ing directly to summary information for large collections of data. @ill graphical output be scaled to fit within the bounds of the display de"ice that is usedF 2ow will color to be used to enhance understandingF 2ow will error messages and warning be presented to the userF

1:.. INTERFACE DESIGN STE#S

Csing information de"eloped during interface analysisL define interface obGects and actions *operations+. Define e"ents *user actions+ that will cause the state of the user interface to change. )odel this beha"ior. Depict each interface state as it will actually loo- to the end.user. Indicate how the user interprets the state of the system from information pro"ided through the interface. Interfa%e Design #atterns he Design pattern is an abstraction that prescribes a design solution to a specific, well bounded design problem Patterns are a"ailable for he complete CI Page layout /orms and input ables Direct data manipulation Da"igation Searching Page elements e.Commerce Design Iss$es Response time 2elp facilities 'rror handling )enu and command labeling (pplication accessibility Internationali8ation 9#

1:.< DESIGN E'A(UATION

Design e"aluation determines whether it meets the needs of the user. '"aluation can span a formality spectrum that ranges from an informal Atest dri"e,B in which a user pro"ide impromptu feedbac- to a formally designed study that uses statistical methods for the e"aluation of !uestionnaires completed by a population of end.users. (fter the design model has been completed, a first le"el prototype is created. he design model of the interface has been created, a number of e"aluation criteria can be applied during early design re"iews. he length and comple6ity of the written specification of the system and its interface pro"ide an indication of the amount of learning re!uired by users of the system. he number of user tas-s specified and the a"erage number of actions per taspro"ide an indication of interaction time and the o"erall efficiency of the system. he number of actions, tas-s and system states indicated by the design model imply the memory load on users of the system Interface style, help facilities and error handling protocol pro"ide indication of the comple6ity of the interface and the degree to which it will be accepted by the user.

o collect !ualitati"e data, !uestionnaires can be distributed to users of the prototype. <uestions can be *#+ simple yes?no response, *>+ numeric response, *%+ scaled *subGecti"e+ response, *5+ li-ert scales *e.g., strongly agree, somewhat agree+, *H+ percentage *subGecti"e+ response or *=+ open.ended. If !uantitati"e data are desired, a form of time study analysis can be conducted.
p r e l i m i n a r y d e s i g n

b u i l d p r o t o t y p e # 1 i n t e r f a c e

b u i l d p r o t o t y p e # i n t e r f a c e

n u s e r e v a l u a t e ' s i n t e r f a c e

d e s i g n m o d i f i c a t i o n s a r e m a d e

e v a l u a t i o n i s s t u d i e d b y d e s i g n e r
I n t e r f a c e d e s i g n i s c o m p l e t e

11. TESTING STRATEGIES

9>

Software Testing esting is the process of e6ercising a program with the specific intent of finding errors prior to deli"ery to the end user. What Testing Shows

Who Tests the Software?

11.1 A STRATEGIC A##ROAC& TO SOFTWARE TESTING

( number of software testing strategies ha"e proposed in the literature. (ll pro"ide the software de"eloper with a template for testing and all ha"e the following generic characteristics: o perform effecti"e testing, a software team should conduct effecti"e formal technical re"iews. Iy doing this, many errors will be eliminated before testing commences. esting begins at the component le"el and wor-s AoutwardB toward the integration of the entire computer.based system. Different testing techni!ues are appropriate at different points in time. esting is conducted by the de"eloper of the software and *for large proGects+ an independent test group. esting and debugging are different acti"ities, but debugging must be accommodated in any testing strategy. 'erifi%ation an! 'a*i!ation

Nerification refers to the set of acti"ities that ensure that software correctly implements a specific function. Nalidation refers to a different 9%

set of acti"ities that ensure that the software that has been built is traceable to customer re!uirements. Nerification: (re we building the product rightF Nalidation: (re we building the right productF

Nerification and "alidation encompasses a Lwide array of S<( acti"ities that include formal technical re"iews, !uality and configuration audits, performance monitoring, simulation, feasibility study, documentation re"iew, database re"iew, algorithm analysis, de"elopment testing, usability testing, !ualification testing, and installation testing. Organi=ing for software testing he people who ha"e built the software are now as-ed to test the software. Cnfortunately, de"elopers ha"e a "ested interest in demonstrating that the program is error free, that it wor-s according to customer re!uirements, and that it will be completed on schedule and within budget. here are often a number of misconceptions *#+ that the de"eloper of software should do no testing at all, *>+ that the software should be Atossed o"er the wallB to strangers who will test it mercilessly, *%+ that testers get in"ol"ed with the proGect only when the testing steps are about to begin. In many cases, the de"eloper also conducts integration testing.a testing step that leads to the construction of the complete software architecture. 7nly after the software architecture is complete does an independent test group become in"ol"ed. he role of an independent test group *I ;+ is to remo"e the inherent problems associated with letting the builder test the thing that has been built. he de"eloper and the I ; wor- closely throughout a software proGect to ensure that thorough tests will be conducted. @hile testing is conducted, the de"eloper must be a"ailable to correct errors that are unco"ered.

A software Testing Strateg1 for %on3entiona* software he module *component+ is our initial focus Integration of modules follows A software Testing Strateg1 for O6Fe%t Oriente! software our focus when Atesting in the smallB changes from an indi"idual module *the con"entional "iew+ to an 77 class that encompasses attributes and operations and implies communication and collaboration Criteria for %om *etion of testing <uestion arises e"ery time software testing is discussed: when are we done testing.how do we -now that we0"e tested enoughF 7ne response to the !uestion is: ,ou0re ne"er done testingL the burden simply shifts from you to your customer. '"ery time the customer?user e6ecutes a computer program, the program is being tested. ,ou0re done testing when you run out of time or you run out of money. 95

Iy collecting metrics during software testing and ma-ing use of e6isting software reliability models, it is possible to de"elop meaningful guidelines for answering the !uestion: when are we done testingF

STRATEGIC ISSUES
State testing obGecti"es e6plicitly. Cnderstand the users of the software and de"elop a profile for each user category. De"elop a testing plan that emphasi8es Arapid cycle testing.B Iuild ArobustB software that is designed to test itself Cse effecti"e formal technical re"iews as a filter prior to testing Conduct formal technical re"iews to assess the test strategy and test cases themsel"es. De"elop a continuous impro"ement approach for the testing process.

11.+. TEST STRATEGIES FOR CON'ENTIONA( SOFTWARE

here are many strategies that can be used to test software: ( software team could wait until the system is fully constructed and then conduct tests on the o"erall system in hopes of finding errors. his approach, although appealing, simply does not wor-. It will result in buggy software that disappoints the customer and end.user. ( software engineer could conduct tests on a daily basis, whene"er any part of the system is constructed. his approach, although less appealing to many, can be "ery effecti"e.

Unit Testing Cnit testing focuses "erification effort on the smallest unit of software design. the software component or module.

Unit Test En3ironment

9H

 Integration Testing Integration testing is a systematic techni!ue for constructing the software architecture while at the same time conducting tests to unco"er errors associated with interfacing. O tions2 M the Abig bangB approach an incremental construction strategy

To Down Integration op.down integration testing is an incremental approach to construction of the software architecture. )odules are integrated by mo"ing downward through the control hierarchy, beginning with the main control module.

he integration process is performed in a series of fi"e steps. he main control module is used as a test dri"er, and stubs are substituted for all components directly subordinate to the main control module. 9=

Depending on the integration approach selected *i.e., depth or breadth first+, subordinate stubs are replaced one at a time with actual components. ests are conducted as each component is integrated. 7n completion of each set of tests, another stub is replaced with the real component. Regressing testing may be conducted to ensure that new errors ha"e not been introduced.

7ottom4U Integration Iottom.up integration testing as its name implies, begins construction and testing with atomic modules. ( bottom.up integration strategy may be implemented with the following four steps: 3ow.le"el components are combined into clusters that perform a specific software subfunction. ( dri"er is written to coordinate test case input and output. he cluster is tested. Dri"ers are remo"ed and clusters are combined mo"ing upward in the program structure.

Regression testing Regression testing may be conducted manually, by re.e6ecuting a subset of all test cases or using automated capture?playbac- tools. he regression test suite contains three different classes of test cases. ( representati"e sample of tests that will e6ercise all software functions. (dditional tests that focus on software functions that are li-ely to be affected by the change. ests that focus on the software components that ha"e been changed. Smo"e Testing ( common approach for creating Adaily buildsB for product software. Smo-e testing steps: Software components that ha"e been translated into code are integrated into a Abuild.B ( build includes all data files, libraries, reusable modules, and engineered components that are re!uired to implement one or more product functions. 94

( series of tests is designed to e6pose errors that will -eep the build from properly performing its function. he intent should be to unco"er Ashow stopperB errors that ha"e the highest li-elihood of throwing the software proGect behind schedule. he build is integrated with other builds and the entire product *in its current form+ is smo-e tested daily. he integration approach may be top down or bottom up.

11., 7(AC547OH TESTING Ilac-.Io6 esting alludes to tests that are conducted at the software interface. ( blac-.bo6 test e6amines some fundamental aspect of a system with little regard for the internal logical structure of the software.

11..

2ow is functional "alidity testedF 2ow is system beha"ior and performance testedF @hat classes of input will ma-e good test casesF Is the system particularly sensiti"e to certain input "aluesF 2ow are the boundaries of a data class isolatedF @hat data rates and data "olume can the system tolerateF @hat effect will specific combinations of data ha"e on system operationF

W&ITE47OH TESTING OR G(ASS47OH TESTING

@hite.Io6 esting of software is predicated on close e6amination of procedural detail. 3ogical paths through the software and collaborations between components are tested by pro"iding test cases that e6ercise specific sets of conditions and?or loops.

Wh1 Co3er? 3ogic errors and incorrect assumptions are in"ersely proportional to a path0s e6ecution probability @e often belie"e that a path is not li-ely to be e6ecutedL in fact, reality is often counter intuiti"e. 99

 will contain some.

ypographical errors are randomL it0s li-ely that untested paths

11.< 'A(IDATION TESTING

/ocus is on software re!uirements Nalidation est Criteria Configuration re"iew (lpha?Ieta testing /ocus is on customer usage

11.C S0STE/ TESTING /ocus is on system integration Reco"ery testing forces the software to fail in a "ariety of ways and "erifies that reco"ery is properly performed Security testing "erifies that protection mechanisms built into a system will, in fact, protect it from improper penetration Stress testing e6ecutes a system in a manner that demands resources in abnormal !uantity, fre!uency, or "olume Performance esting test the run.time performance of software within the conte6t of an integrated system.

11.D T&E ART OF DE7UGGING

Debugging occurs as a conse!uence of successful testing. hat is, when a test case unco"ers an error, debugging is an action that results in the remo"al of the error.

The De6$gging #ro%ess2 Debugging will always ha"e one of two outcomes: he cause will be found and corrected he cause will not be found. In the latter case, the person performing debugging may suspect a cause, design one or more test cases to help "alidate that suspicion, and wor- toward error correction in an iterati"e fashion.

9$

@hy is debugging so difficultF In all li-elihood, human psychology has more to do with an answer than software technology. 2owe"er, a few characteristics of bugs pro"ide some clues: he symptom and the cause may be geographically remote. hat is, the symptom may appear in one part of a program, while the cause may actually be located at a site that is far remo"ed. 2ighly coupled components e6acerbate this situation. he symptom may disappear when another error is corrected. he symptom may actually be caused by non errors. he symptom may be caused by human error that is not easily traced. he symptom may be a result of timing problems, rather than procession problems. It may be difficult to accurately reproduce input conditions. he symptom may be intermittent. his is particularly common in embedded systems that couple hardware and software ine6tricably. he symptom may be due to causes that are distributed across a number of tas-s running on different processors.

During debugging, we encounter errors that range from mildly annoying to catastrophic.

#s1%ho*ogi%a* Consi!erations Debugging is one of the more frustrating parts of programming. It has elements of problem sol"ing or brain teasers, coupled with the annoying recognition that you ha"e made a mista-e. 2eightened an6iety and the unwillingness to accept the possibility of error increases the tas- difficulty. /ortunately, there is a great sigh of relief and a lessening of tension when the bug is ultimately corrected. De6$gging Strategies Regardless of the approach that is ta-en, debugging has one o"erriding obGecti"e: to find and correct the cause of a software error. he obGecti"e is reali8ed by a combination of systematic e"aluation, intuition and luc-. In general, three debugging strategies ha"e been proposed Irute force $:

Iac-trac-ing Cause elimination.

Debugging tactics: he brute force category of debugging is probably the most common and least efficient method of isolating the cause of a software error. Iac-trac-ing is a fairly common debugging approach that can be used successfully in small programs. Cause elimination is manifested by induction or deduction and introduces the concept of binary partitioning. (utomated debugging 'ach of these debugging approaches can be supplemented with debugging tools that pro"ide semi.automated support for the software engineer as debugging strategies are attempted. he people factor ( fresh "iewpoint, unclouded by hours of frustration, can do wonders. ( final ma6im for debugging might be: when all else fails, get help. Corre%ting the error

7nce a bug has been found, it must be corrected. Iut, as we ha"e already noted, the correction of a bug can introduce other errors and therefore do more harm than good. Nan Nlecsuggests three simple !uestions that e"ery software engineer should as- before ma-ing the AcorrectionB that remo"es the cause of a bug: Is the cause of the bug reproduced in another part of the programF @hat Ane6t bugB might be introduced by the fi6 that I0m about to ma-eF @hat could we ha"e done to pre"ent this bug in the first placeF JJJJJJJ

1+. #RODUCT /ETRICS

1+.1 SOFTWARE ;UA(IT0

$#

Software !uality is conformance to e6plicitly stated functional and performance re!uirements, e6plicitly documented de"elopment standards, and implicit characteristics that are e6pected of all professionally de"eloped software. he definition ser"es to emphasi8e three important points: Software re!uirements are the foundation from which !uality is measured. 3ac- of conformance to re!uirements is lac- of !uality. Specified standards define a set of de"elopment criteria that guide the manner in which software is engineered. If the criteria are not followed, lac- of !uality will almost surely result. here is asset of implicit re!uirements that often goes unmentioned. If software conforms to its e6plicit re!uirements but fails to meet implicit re!uirements, software !uality is suspect.

Software !uality is a comple6 mi6 of factors that will "ary across different applications and the customers who re!uest them.

/%Ca**)s ;$a*it1 Fa%tors groups: /actors that can be directly measured. /actors that can be measuring only indirectly. In each case measurement should occur. @e must compare the software to some datum and arri"e at an indication of !uality. he factors that affect software !uality can be categori8ed in two broad

)cCall, Richards and @alters propose a useful categori8ation of factors that affect software !uality. hese software !uality factors, shown in figure, focus on three important aspects of a software product: Its operational characteristics, its ability to undergo change, and its adaptability to new en"ironments. Referring to the factors noted in figure, )cCall and his colleagues pro"ide the following descriptions:

(orrectness< he e6tent to which a program satisfies its specification and fulfills the customer0s mission obGecti"es. +elia#ilit*< he e6tent to which a program can be e6pected to perform its intended function with re!uired precision. $>

Efficienc*< he amount of computing resources and code re!uired by a program to perform its function. Integrit*< he e6tent to which access to software or data by unauthori8ed persons can be controlled. )sa#ilit*< he effort re!uired to learn, operate, prepare input for, and interpret output of a program. !aintaina#ilit*< he effort re!uired to locate and fi6 and error in a program. Fle%i#ilit*< he effort re!uired to modify an operational program. Testa#ilit*< he effort re!uired to test a program to ensure that it performs its intended function. Porta#ilit*< the effort re!uired to transfer the program from one hardware and?or software system en"ironment to another. +eusa#ilit*< the e6tent to which a program can be reused in other applications. related to the pac-aging and scope of the functions that the program performs. Interopera#ilit*< he effort re!uired to couple one system to another.

" $omment )cCall0s !uality factors were proposed in the early #$4:s. hey are as "alid today as they were in that time. It0s li-ely that software built to conform to these factors will e6hibit high !uality well into the >#st century, e"en if there are dramatic changes in technology. ISO A1+C ;$a*it1 Fa%tors2 he IS7 $#>= standard was de"eloped in an attempt to identify !uality attributes for computer software. he standard identifies si6 -ey !uality attributes: Functionalit*< he degree to which the software satisfies stated needs as indicated by the following sub.attributes: suitability, accuracy, interoperability, compliance and security. +elia#ilit*< he amount of time that the software is a"ailable for use as indicated by the following sub.attributes: maturity, fault tolerance, reco"erability. )sa#ilit*< the degree to which the software is easy to use as indicated by the following sub.attributes: understandability, learnability, operability. Efficienc*< he degree to which the software ma-es optimal use of system resources as indicated by the following sub.attributes: time, beha"ior, resource beha"ior. !aintaina#ilit*< he ease with which repair may be made to the software as indicated by the following sub.attributes: analy8ability, changeability, stability, testability. $%

Porta#ilit*< he ease with which the software can be transposed from one en"ironment to another as indicated by the following sub. attributes: adaptability, installability, conformance, replaceabilty.

The Transition to a ;$antitati3e 'iew @e e6amine a set of software metrics that can be applied to the !uantitati"e assessment of software !uality. In all cases, the metrics represent indirect measuresL that is, we ne"er really measure !uality but rather some manifestation of !uality. he complicating factor is the precise relationship between the "ariable that is measuring and the !uality of software.

1+.+ /ETRICS FOR T&E ANA(0SIS /ODE(

Function"#ased metrics< use the function point as a normali8ing factor or as a measure of the Asi8eB of the specification Specification metrics< used as an indication of !uality by measuring number of re!uirements by type F$n%tion47ase! /etri%s he function point metric */P+, first proposed by (lbrecht, can be used effecti"ely as a means for measuring the functionality deli"ered by a system. /unction points are deri"ed using an empirical relationship based on countable *direct+ measures of softwareWs information domain and assessments of software comple6ity Information domain "alues are defined in the following manner: 5um#er of e%ternal inputs (EIs 5um#er of e%ternal outputs (E0s 5um#er of e%ternal in&uiries (EHs 5um#er of internal logical files (IIFs 5um#er of e%ternal interface files (EIFs used: FP . count total / 01234 5 1216 / 7 8Fi9: 869 @here count total is the sum of all /P entries obtained from figure.
"nformation Domain #alue "xternal Inputs "Is? > "xternal .utputs ".s? > "xternal In%uiries"As > ? Internal =ogical 0ilesI=0s? > "xternal Interface 0iles"I0s? > Count total !eig ting factor Count 7 M 7 M simple
7 J 7 G ;

F$n%tion #oints o compute function points */P+, the following relationship is

average
J ; J '6 G

comple$
5 G 5 '; '6

4 4 4 4 4

M 7
7 M 7 M

he Fi *iV # to #5+ are value ad8ustment factors based on responses to the following !uestions:
#. Does the system re!uire reliable bac-up and reco"eryF

$5

>. %. 5. H. =. 4. 9. $. #:. ##. #>. #%. #5.

(re speciali8ed data communications re!uired to transfer information to or form the applicationF (re there distributed processing functionsF Is performance criticalF @ill the system run in an e6isting, hea"ily utili8ed operational en"ironmentF Does the system re!uire on.line data entryF Does the on.line data entry re!uire the input transaction to be built o"er multiple screens or operationsF (re the I3/s updated on.lineF (re the inputs, outputs, files or in!uiries comple6F Is the internal processing comple6F Is the code designed to be reusableF (re con"ersion and installation included in the designF Is the system designed for multiple installations in different organi8ationsF Is the application designed to facilitate change and for ease of use by the userF

'ach of these !uestions is answered using a scale that ranges from : to <. he constant "alues in e&uation"@ and the weighting factors that are applied to information domain counts are determined empirically.

1+., /ETRICS FOR T&E DESIGN /ODE(

Design metrics for computer software, li-e all other software metrics, are not perfect. Debate continues o"er their efficacy and the manner in which they should be applied. Ar%hite%t$ra* Design /etri%s (rchitectural design metrics focus on characteristics of the program architecture with an emphasis on the architectural structure and the effecti"eness of modules or components within the architecture. (rchitectural design metrics Structural comple6ity V g*fan.out+ Data comple6ity V f*input K output "ariables, fan.out+ System comple6ity V h*structural K data comple6ity+ 2X metric: architectural comple6ity as a function of fan.in and fan.out )orphology metrics: a function of the number of modules and the number of interfaces between modules

/or hierarchical architectures structural comple6ity of a module I is defined in the following manner: S*i+ V f>out*i+ @here fout*i+ is the fan.out of module i. $H

Data comple6ity pro"ides an indication of the comple6ity in the internal interface for a module I and is defined as D*i+ V "*i+ ? Yfout*i+ U #Z @here "*i+ is the number of input and output "ariables that are passed to and from module i. /inally, system comple6ity is defined as the sum of structural and data comple6ity specified as C*i+ V S*i+ U D*i+

(s each of these comple6ity "alues increases, the o"erall architectural comple6ity or the system also increases. his leads to a greater li-elihood that integration and testing effort will also increase. /enton suggests a number of simple morphology metrics that enable different program architectures to be compared using a set of straight forward dimensions. Referring to the call.and.return architecture in figure. he following metric can be defined: size = n > a where n is the num#er of nodes and a is the num#er of arcs. he C.S. (ir /orce Systems command has de"eloped a number of software !uality indicators that are based on measurable design characteristics of a computer program. he (ir /orce uses information obtained form data and architectural design to deri"e a design structure !uality inde6 that ranges from : to #. he following "alues must be ascertained to compute the DS<I. S# V the total number of modules defined in the program architecture S> V the number of modules whose correct function depends on the source of data input or that produce data to be used elsewhere. S% V the number of modules whose correct function depends on prior processing. S5 V the number of database items. SH V the total number of uni!ue database items. S= V the number of database segments S4 V the number of modules with a single entry and e6it. Program Structure: ,@, where ,@ is defined as follows: If the architectural design was de"eloped using a distinct method, then ,@V #, otherwise ,@V:. )odule independence: ,A V # O *SACS@+ )odules not dependent on prior processing: ,9 V # O *S9CS@+ Database si8e: ,J V #. *S7CSJ+ Database compartmentali8ation: ,7 V # O *SKCSJ+ )odule entrance?e6it characteristic: ,K V # O *SLCS@+ @ith these intermediate "alues determined, the DS<I is computed in the following manner: DS<I V [wi,i @here i V # to =, wi is the relati"e weighting of the importance of each of the intermediate "alues, and [wi V # /etri%s for O6Fe%t4Oriente! Design @hitmire describes nine distinct and measurable characteristics of an 77 design: $=

Si8e
Si8e is defined in terms of four "iews: population, "olume, length, and functionality 2ow classes of an 77 design are interrelated to one another he physical connections between elements of the 77 design Athe degree to which an abstraction possesses the features re!uired of it, or the degree to which a design component possesses features in its abstraction, from the point of "iew of the current application.B (n indirect implication about the degree to which the abstraction or design component can be reused he degree to which all operations wor-ing together to achie"e a single, well.defined purpose (pplied to both operations and classes, the degree to which an operation is atomic he degree to which two or more classes are similar in terms of their structure, function, beha"ior, or purpose )easures the li-elihood that a change will occur

Comple6ity

Coupling Sufficiency

Completeness

Cohesion

Primiti"eness

Similarity

Nolatility

C*ass4Oriente! /etri%s he class is the fundamental unit of an obGect oriented system.

Proposed #* (hidam#er and Memerer !etrics Suite weighted methods per class depth of the inheritance tree number of children coupling between obGect classes response for a class lac- of cohesion in methods The !00, !etrics Suite )ethod inheritance factor: Coupling factor Polymorphism factor Proposed #* Iorenz and Midd<
class si8e number of operations o"erridden by a subclass number of operations added by a subclass speciali8ation inde6

Com onent4(e3e* Design /etri%s $4

(ohesion metrics< a function of data obGects and the locus of their definition (oupling metrics< a function of input and output parameters, global "ariables, and modules called (omple%it* metrics< hundreds ha"e been proposed *e.g., cyclomatic comple6ity+ O eration4Oriente! /etri%s Proposed #* Iorenz and Midd<
a"erage operation si8e operation comple6ity a"erage number of parameters per operation

User Interfa%e Design /etri%s Ia*out appropriateness< a function of layout entities, the geographic position and the AcostB of ma-ing transitions among entities.

1+.. /ETRICS FOR SOURCE CODE

(lso called 2alstead0s Software Science: a comprehensi"e collection of metrics all predicated on the number *count and occurrence+ of operators and operands within a component or program It should be noted that 2alstead0s AlawsB ha"e generated substantial contro"ersy, and many belie"e that the underlying theory has flaws. 2owe"er, e6perimental "erification for selected programming languages has been performed. he measures are
n# V the number of distinct operators that appear in a program. n> V the number of distinct operands that appear in a program. D# V the total number of operator occurrences. D> V the total number of operand occurrences. 2alstead shows that length D can be estimated

DV n# log> n# U n> log> n> and program "olume may be defined. N V D log> *n#Un>+ It should be noted that N will "ary with programming language and represents the "olume of information re!uired to specify a program. heoretically, a minimum "olume must e6ist for a particular algorithm. 2alstead defines a "olume ratio 3 as the ratio of "olume of the most compact form of a program to the "olume of the actual program. 3 must always be less than #. In terms of primiti"e measures, the "olume ratio may be e6pressed as 3 V >?n# M n>?D> )odules with high cyclomatic comple6ity are more li-ely to be error prone than modules whose cyclomatic comple6ity is lower. /or this reason, the tester should e6pand abo"e a"erage effort to unco"er errors in such modules before they are integrated in a system. *ie! to Testing $9

1+.< /ETRICS FOR TESTING

&a*stea! /etri%s A

esting effort can also be estimated using metrics deri"ed from 2alstead measures
Csing the definitions for program "olume, N, and program le"el, P3, 2alstead effort, e, can be computed as

PI = @ C Nn@CA 3 (5ACnA O and e = DCPI he percentage of o"erall testing effort to be allocated to a module can be estimated using the following relationship: Percentage of testing effort (; V e(; ? [e(i
@here e(; is computed for module ; using e!uations and the summation in the denominator of e!uation is the sum of 2alstead effort across all modules of the system.

/etri%s for O6Fe%t4Oriente! Testing Iinder suggests a broad array of design metrics that ha"e a direct influence on the AtestabilityB of an 77 system.
Iac; of cohesion in methods (I(0! < he higher the "alue of 3C7), the more states must be tested to ensure that methods do not generate side effects. Percent pu#lic and protected (P/P : his metric indicates the percentage of class attributes that are public or protected. Pu#lic access to data mem#ers (P/, : his metric indicates the number of classes that can be access another class0s attributes, a "iolation of encapsulation. 5um#er of root classes (50+ : his metric is a count of the distinct class hierarchies that are described in the design model. Fan"in (FI5 : @hen used in the 77 conte6t, fan.in for the inheritance hierarchy is an indication of multiple inheritance. /IDR# indicates that a class inherits its attributes and operations from more than one root class. 5um#er of children (50( and depth of the inheritance tree (,IT : Superclass methods will ha"e to be retested for each subclass.

1+.C /ETRICS FOR /AINTENANCE I''' Std. $9>.# O #$99 suggests a software maturity inde6 that pro"ides an indication of the stability of a software product. he following information is determined: !T V the number of modules in the current release. Fc V the number of modules in the current release that ha"e been changed. Fa V the number of modules in the current release that ha"e been added. Fd V the number of modules from the preceding release that were deleted in the current release. he software maturity inde6 is computed in the following manner: S)I V Y!r O *Fa > Fc >Fd+Z?!T (s S)I approaches #.:, the product begins to stabili8e. S)I may also be used as a metric for planning software maintenance acti"ities. he mean time to produce a release of a software product can be correlated with S)I, and empirical models for maintenance effort can be de"eloped.

1,. /ETRICS FOR #ROCESS N #ROIECTS

Software process and proGect metrics are !uantitati"e measures that enable software engineers to gain insight into the efficacy of the software process and the proGects that are conducted using the process as a framewor-. SOFTWARE /EASURE/ENT $$

1,.1

Software measurement can be categori8ed in two ways. ,irect measures of the software process and product. Indirect measures of the product that includes functionality, !uality, comple6ity, efficiency, reliability, maintainability. Si=e4Oriente! /etri%s errors per X37C *thousand lines of code+ defects per X37C \ per 37C pages of documentation per X37C errors per person.month 'rrors per re"iew hour 37C per person.month \ per page of documentation F$n%tion4Oriente! /etri%s errors per /P *thousand lines of code+ defects per /P \ per /P pages of documentation per /P /P per person.month Re%on%i*ing (OC an! F# /etri%s he relationship between lines of code and function points depend upon the programming language that is used to implement the software and the !uality of the design. ( number of studies ha"e attempted to relate /P and 37C measures. he following table pro"ides rough estimates of the a"erage number of lines of code re!uired to build one function point in "arious programming languages.

Wh1 O t for F#? Programming language independent. Csed readily countable characteristics that are determined early in the software process. Does not Apenali8eB in"enti"e *short+ implementations that use fewer 37C that other clumsier "ersion. )a-es it easier to measure the impact of reusable components. #::

O6Fe%t4Oriente! /etri%s 5um#er of scenario scripts (use"cases < ( Scenario script is a detailed se!uence of steps that describes the interaction between the user and the application. 5um#er of Me* classes< Xey classes are the Ahighly independent componentsB that are defined early in obGect.oriented analysis. 5um#er of support classes< Supports Classes are re!uired to implement the system but are not immediately related to the problem domain. /verage num#er of support classes per ;e* class (anal*sis class < he a"erage number of support classes per -ey class were -nown for a gi"en problem domain, estimating would be much simplified. 5um#er of su#s*stems< ( subsystem is an aggregation of classes that support a function that is "isible to the end.user of a system. Use4Case Oriente! /etri%s acti"ities. Independent of programming languages. Do standard si8e for use.case. We6 Engineering #roFe%t /etri%s Dumber of static @eb pages *the end.user has no control o"er the content displayed on the page+ Dumber of dynamic @eb pages *end.user actions result in customi8ed content displayed on the page+ Dumber of internal page lin-s *internal page lin-s are pointers that pro"ide a hyperlin- to some other @eb page within the @eb(pp+ Dumber of persistent data obGects Dumber of e6ternal systems interfaced Dumber of static content obGects Dumber of dynamic content obGects Dumber of e6ecutable functions ( normali8ation measure similar to 37C and /P. Csed for estimation before significant modeling and construction

1,.+

/ETRICS FOR SOFTWARE ;UA(IT0

he o"erriding goal of software engineering is to produce a high !uality system, application, or product within a timeframe that satisfies a mar-et need. o achie"e this goal: Software 'ngineer must apply effecti"e methods coupled with modern tools. reali8ed. le"el results. #:# Pri"ate metrics collected are assimilated to pro"ide proGect Software 'ngineer must measure a high !uality is to be

his metrics pro"ide the effecti"eness of indi"idual and group software !uality assurance and control acti"ities. 'rror data can also be used to compute defect remo"al efficiency for each process framewor- acti"ity. /eas$ring ;$a*it1

(orrectness P the degree to which a program operates according to specification !aintaina#ilit*Pthe degree to which a program is amenable to change Integrit*Pthe degree to which a program is imper"ious to outside attac)sa#ilit*Pthe degree to which a program is easy to use Defe%t Remo3a* Effi%ien%1 8DRE9 ( !uality metric that pro"ides benefits at both the proGect and process le"el is defect remo"al efficiency. @hen considered for a proGect as a whole, DR' is defined in the following manner: DR' V E ? *E U ,+

@here E is the number of errors found before deli"ery of the software to the end.user , is the number of defects found after deli"ery. JJJJJJ

1.. RIS5 /ANAGE/ENT

#roFe%t Ris"s .hat can go wrongF #:>

.hat is the li;elihoodF .hat will the damage #eF .hat can we do a#out itF 1..1 REACTI'E 3s #ROACTI'E RIS5 STRATEGIES Rea%ti3e Ris" /anagement proGect team reacts to ris-s when they occur mitigationPplan for additional resources in anticipation of fire fighting fi6 on failurePresource are found and applied when the ris- stri-es crisis managementPfailure does not respond to applied resources and proGect is in Geopardy #roa%ti3e Ris" /anagement formal ris- analysis is performed organi8ation corrects the root causes of ris <) concepts and statistical S<( e6amining ris- sources that lie beyond the bounds of the software de"eloping the s-ill to manage change

1..+ SOFTWARE RIS5S Ris- always in"ol"es two characteristics Cncertainty : the ris- may or may not happenL that is, there are no #::] probable ris-s. 3oss : if the ris- becomes a reality, unwanted conse!uences or losses will occur.

Pro8ect ris;s threaten the proGect plan. ProGect ris-s identify potential budgetary, schedule, personal, resource, sta-eholder, and re!uirements problems and their impact on a software proGect. Technical ris;s threaten the !uality and timeliness of the software to be produced. If a technical ris- becomes a reality, implementation may become difficult or impossible. echnical ris-s occur because the problem is harder to sol"e than we thought it would be. -usiness ris;s threaten the "iability of the software to be built. he top fi"e business ris-s are: *#+ Iuilding an e6cellent product or system that no one really ants, *>+ Iuilding a product that no longer fits into the o"erall business strategy for the company, *%+ Iuilding a product that the sales force doesn0t understand how to sell, *5+ 3osing the support of senior management due to a change in focus or a change in people and *H+ 3osing budgetary or personnel commitment.

Predictable ris-s are e6trapolated from past proGect e6perience. #:%

Cnpredictable ris-s are the Go-er in the dec-. hey can and do occur, but they are e6tremely difficult to identify in ad"ance. Se3en rin%i *es of ris" management
#. >. %. 5. H. =. 4. !aintain a glo#al perspective P"iew software ris-s within the conte6t of system and the business problem Ta;e a forward"loo;ing viewPthin- about the ris-s that may arise in the futureL establish contingency plans Encourage open communicationPif someone states a potential ris-, don0t discount it. IntegratePa consideration of ris- must be integrated into the software process Emphasize a continuous processPthe team must be "igilant throughout the software process, modifying identified ris-s as more information is -nown and adding new ones as better insight is achie"ed. ,evelop a shared product visionPif all sta-eholders share the same "ision of the software, it li-ely that better ris- identification and assessment will occur. Encourage teamwor;Pthe talents, s-ills and -nowledge of all sta-eholder should be pooled

1..,. RIS5 IDENTIFICATION Product sizePris-s associated with the o"erall si8e of the software to be built or modified. -usiness impactPris-s associated with constraints imposed by management or the mar-etplace. (ustomer characteristicsPris-s associated with the sophistication of the customer and the de"eloperWs ability to communicate with the customer in a timely manner. Process definitionPris-s associated with the degree to which the software process has been defined and is followed by the de"elopment organi8ation. ,evelopment environmentPris-s associated with the a"ailability and !uality of the tools to be used to build the product. Technolog* to #e #uiltPris-s associated with the comple6ity of the system to be built and the ^newness^ of the technology that is pac-aged by the system. Staff size and e%periencePris-s associated with the o"erall technical and proGect e6perience of the software engineers who will do the wor-. Assessing #roFe%t Ris" 2a"e top software and customer managers formally committed to support the proGectF (re end.users enthusiastically committed to the proGect and the system?product to be builtF (re re!uirements fully understood by the software engineering team and their customersF 2a"e customers been in"ol"ed fully in the definition of re!uirementsF Do end.users ha"e realistic e6pectationsF Is proGect scope stableF Does the software engineering team ha"e the right mi6 of s-illsF (re proGect re!uirements stableF #:5

Does the proGect team ha"e e6perience with the technology to be implementedF Is the number of people on the proGect team ade!uate to do the GobF Do all customer?user constituencies agree on the importance of the proGect and on the re!uirements for the system?product to be builtF Ris" Com onents performance ris;Pthe degree of uncertainty that the product will meet its re!uirements and be fit for its intended use. cost ris;Pthe degree of uncertainty that the proGect budget will be maintained. support ris;Pthe degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. schedule ris;Pthe degree of uncertainty that the proGect schedule will be maintained and that the product will be deli"ered on time.

1... RIS5 #ROIECTION

+is; pro8ection, also called ris; estimation$ attempts to rate each ris- in two ways the li-elihood or probability that the ris- is real the conse!uences of the problems associated with the ris-, should it occur. he are four ris- proGection steps: establish a scale that reflects the percei"ed li-elihood of a ris delineate the conse!uences of the ris estimate the impact of the ris- on the proGect and the product, note the o"erall accuracy of the ris- proGection so that there will be no misunderstandings. RisProbability Impact R))) Ris- )itigation )onitoring K )anagement following relationship: R' V P 6 ( where P is the probability of occurrence for a ris-, and #:H 'stimate the probability of occurrence 'stimate the impact on the proGect on a scale of # to H, where # V low impact on proGect success H V catastrophic impact on proGect success sort the table by probability and impact Assessing Ris" Im a%t he o"erall ris; e%posure$ R', is determined using the

De3e*o ing a Ris" Ta6*e

( is the cost to the proGect should the ris- occur.

1..< RIS5 REFINE/ENT

During early stages of proGect planning, a ris- may be stated !uite generally. (s time passes and more is learned about the proGect and the ris-, it may be possible to refine the ris- into a set of more detailed ris-s, each somewhat easier to mitigate, monitor, and manage. 7ne way to do this is to represent the ris- in condition transition.conse!uence format. hat is, the ris- is stated in the following form: ;i"en that _conditionR then there is concern that _conse!uenceR. his general condition can be refined in the following manner: Su#condition@< Certain reusable components were de"eloped by a third party will no -nowledge of internal design standards. Su#conditionA< he design standard for component interfaces has not been solidified and may not conform to certain e6isting reusable components. Su#condition9< Certain reusable components ha"e been implemented in a language that is not supported on the target en"ironment.

1..C RIS5 /ITIGATION@ /ONITORING@ AND /ANAGE/ENT )itigationPhow can we a"oid the ris-F )onitoringPwhat factors can we trac- that will enable us to determine if the ris- is becoming more or less li-elyF )anagementPwhat contingency plans do we ha"e if the ris- becomes a realityF he R))) plan documents all wor- performed as part of risanalysis and are used by the proGect manager as part of the o"erall proGect plan. Some software teams do not de"elop a formal R))) document. Rather, each ris- is documented indi"idually using a Ris- Information Sheet *RIS+. #:=

1..D T&E R/// #(AN

In most cases, the RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily. 7nce R))) has been documented and the proGect has begun, rismitigation and monitoring steps commence. Ris- monitoring is a proGect trac-ing acti"ity with three primary obGecti"es: #. >. %. o assess whether predicted ris-s do, in fact, occur. o ensure that ris- a"ersion steps defined for the ris- are being properly applied. o collect information that can be used for future ris- analysis. Ris" Information Sheet

ProGect: 'mbedded software for M,` system. Ris- type: schedule risPriority *# low ... H critical+: 5 Ris- factor: ProGect completion will depend on tests which re!uire hardware component under de"elopment. 2ardware component deli"ery may be delayed. Probability: =: ] Impact: ProGect completion will be delayed for each day that hardware is una"ailable for use in software testing. )onitoring approach: Scheduled milestone re"iews with hardware group. Contingency plan: )odification of testing strategy to accommodate delay using software simulation. 'stimated resources: = additional person months beginning 4.#.$= JJJJJ

1<. ;UA(IT0 /ANAGE/ENT

1<.1 ;UA(IT0 CONCE#TS Nariation control is the heart of the !uality control. ( manufacturer wants to minimi8e the "ariation among the products that are produced. #:4

;$a*it1 he /merican Geritage ,ictionar* defines &ualit* as Aa characteristic or attribute of something.B /or software, two -inds of !uality may be encountered: <uality of design encompasses re!uirements, specifications, and the design of the system. <uality of conformance is an issue focused primarily on implementation. user satisfaction V compliant product U good !uality U deli"ery within budget and schedule

;$a*it1 Contro* <uality control in"ol"es the series of inspections, re"iews, and tests used throughout the software process to ensure each wor- product meets the re!uirements placed upon it. <uality control includes a feedbac- loop to the process that created the worproduct. ( -ey concept of !uality control is that all wor- products ha"e defined, measurable specifications to which h we may compare the output of each process. he feedbac- loop is essential to minimi8e the defects produced.

;$a*it1 Ass$ran%e <uality assurance consists of a set of auditing and reporting functions that assess the effecti"eness and completeness of !uality control acti"ities. he goal of !uality assurance is to pro"ide management with the data necessary to be informed about product !uality, thereby gaining insight and confidence that product !uality is meeting its goals. Cost of ;$a*it1 Prevention costs include !uality planning formal technical re"iews test e!uipment raining failure mode analysis

Internal failure costs include rewor repair E%ternal failure costs are complaint resolution product return and replacement

help line support warranty wor-

#:9

1<.+

SOFTWARE ;UA(IT0 ASSURANCE

Software <uality can be defined as Conformance to e6plicitly state functional and performance re!uirements, e6plicitly documented de"elopment standards, and implicit characteristics that are e6pected of all professionally de"eloped software. Definition ser"es to emphasi8e three important points: Software re!uirements are the foundation from which !uality is measured. 3ac- of conformance to re!uirements is lac- of !uality. Specified standard define a set of de"elopment criteria that guide the manner in which software is engineered. If the criteria are not followed, lac- of !uality will almost surely result. ( set of implicit re!uirements often goes unmentioned. If software conforms to its e6plicit re!uirements but fails to meet implicit re!uirements, software !uality is suspect. S;A A%ti3ities Prepares an S<( plan for a proGect. he plan identifies '"aluations to be performed. (udits and re"iews to be performed. Standards that is applicable to the proGect. Procedures for error reporting and trac-ing. Documents to be produced by the S<( group. (mount of feedbac- pro"ided to the software proGect team. Participates in the de"elopment of the proGect0s software process description. #:$

he S<( group re"iews the process description for compliance with organi8ational policy, internal software standards, e6ternally imposed standards *e.g., IS7.$::#+, and other parts of the software proGect plan. Re"iews software engineering acti"ities to "erify compliance with the defined software process. Identifies, documents, and trac-s de"iations from the process and "erifies that corrections ha"e been made. (udits designated software wor- products to "erify compliance with those defined as part of the software process. Re"iews selected wor- productsL identifies, documents, and trac-s de"iationsL "erifies that corrections ha"e been made Periodically reports the results of its wor- to the proGect manager. 'nsures that de"iations in software wor- and wor- products are documented and handled according to a documented procedure. Records any noncompliance and reports to senior management. Doncompliance items are trac-ed until they are resol"ed.

1<., SOFTWARE RE'IEWS

Software re"iews are a AfilterB for the software process. hat is, re"iews are applied at "arious points during software engineering and ser"e to unco"er errors and defects that can then be remo"ed. What Are Re3iews? a meeting conducted by technical people for technical people a technical assessment of a wor- product created during the software engineering process a software !uality assurance mechanism a training ground What Re3iews Are Not? ( proGect summary or progress assessment ( meeting intended solely to impart information ( mechanism for political or personal reprisalE Cost im a%t of software !efe%ts he primary obGecti"e of formal technical re"iews is to find errors during the process so that they do not become defects after release of the software. he ob"ious benefit of formal technical re"iews is the early disco"ery of errors so that they do not propagate to the ne6t step in the software process. ##:

o illustrate the cost impact of early error detection, we consider a series of relati"e costs that are based on actual cost data collected for large software proGects. Defe%t Am *ifi%ation an! Remo3a*

( defect amplification model can be used to illustrate the generation and detection of errors during the preliminary design, detail design, and coding steps of a software engineering process. During the step, errors may be inad"ertently generated. Re"iew may fail to unco"er newly generated errors and errors from pre"ious steps, resulting in some number of errors that are passed through. o conduct re"iews, a software engineer must e6pend time and effort, and the de"elopment organi8ation must spend money.

1<.. FOR/A( TEC&NICA( RE'IEWS

are: #. to unco"er errors in function, logic, or implementation for any representation of the software. >. to "erify that the software under re"iew meets its re!uirements. %. to ensure that the software has been represented according to predefined standards. 5. to achie"e software that is de"eloped in a uniform manner H. to ma-e proGects more manageable. The Re3iew /eeting '"ery re"iew meeting should abide by the following constraints: #. Ietween three and fi"e people should be in"ol"ed in the re"iew. >. (d"ance preparation should occur but should re!uire no more than two hours of wor- for each person. %. he duration of the re"iew meeting should be less than two hours. ( formal technical re"iew is a software !uality control acti"ity performed by software engineers. he obGecti"es of formal technical re"iews

be preparedPe"aluate product before the re"iew re"iew the product, not the producer ###

-eep your tone mild, as- !uestions instead of ma-ing accusations stic- to the re"iew agenda raise issues, donWt resol"e them a"oid discussions of stylePstic- to technical correctness schedule re"iews as proGect tas-s record and report all re"iew results Re3iew Re orting an! Re%or! 5ee ing ( re"iew summary report answers three !uestions: #. @hat was re"iewedF >. @ho re"iewed itF %. @hat were the findings and conclusionsF

he re"iew summary report is a single page form. he re"iew issues list ser"es two purposes: #. >. o identify problem areas within the product o ser"e as an action item chec-list that guides the producer as corrections are made. (n issues list is normally attached to the summary report.

It is important to establish a follow.up procedure to ensure that items on the issues list ha"e been properly corrected. Re3iew G$i!e*ines

he following represents a minimum set of guidelines for formal technical re"iews: #. Re"iew the product, not the producer >. Set an agenda and maintain it %. 3imit debate and rebuttal 5. 'nunciate problem areas H. a-e written notes =. 3imit the number of participants and insist upon ad"ance preparation 4. De"elop a chec-list for each product that is li-ely to be re"iewed. 9. (llocate resources and schedule time for / Rs $. Conduct meaningful training for all re"iewers. #:. Re"iew your early re"iews.

Sam *e4Dri3en Re3iews 8SDRs9 SDRs attempt to !uantify those wor- products that are primary targets for full / Rs. To accomplish this ' Inspect a fraction ai of each software wor- product, i. Record the number of faults, fi found within ai. De"elop a gross estimate of the number of faults within wor- product i by multiplying fi by #?ai. Sort the wor- products in descending order according to the gross estimate of the number of faults in each. ##>

 1<.<

/ocus a"ailable re"iew resources on those wor- products that ha"e the highest estimated number of faults.

STATISTICA( SOFTWARE ;UA(IT0 ASSURANCE he software statistical !uality assurance implies the following steps: #. Information about software defects is collected and categori8ed. >. (n attempt is made to trace each defect to its underlying cause. %. Csing the Pareto principle *9:] of the defects can be traced to >:] of all possible causes+, isolate the >:] *the A"ital fewB+. 5. 7nce the "ital few causes ha"e been identified, mo"e to correct the problems that ha"e caused the defects.

SiB4Sigma for Software Engineering he term Asi6 sigmaB is deri"ed from si6 standard de"iationsP%.5 instances *defects+ per million occurrencesPimplying an e6tremely high !uality standard. he Si6 Sigma methodology defines three core steps: ,efine customer re!uirements and deli"erables and proGect goals "ia well.defined methods of customer communication !easure the e6isting process and its output to determine current !uality performance *collect defect metrics+ /nal*ze defect metrics and determine the "ital few causes.

If an e6isting software process is in place, but impro"ement is re!uired, Si6 Sigma suggests two additional steps: Improve the process by eliminating the root causes of defects. (ontrol the process to ensure that future wor- does not reintroduce the causes of defects.

If an organi8ation is de"eloping a software process the core steps are augmented as follows: ,esign the process to *#+ a"oid the root causes of defects and *>+ to meet customer re!uirements. Derif* that the process model will, in fact, a"oid defects and meet customer re!uirements.

1<.C SOFTWARE RE(IA7I(IT0 ##%

Software reliability is defined in statistical terms as Athe probability of failure.free operation of a computer program in a specified en"ironment for a specified time. /eas$res of re*ia6i*it1 an! A3ai*a6i*it1 ( simple measure of reliability is mean"time"#etween"failure *) I/+, where ) I/ V ) / U ) R he acronyms ) respecti"ely. / and ) R are mean"time"to"failure and mean"time"to"repair,

Software availa#ilit* is the probability that a program is operating according to re!uirements at a gi"en point in time and is defined as ("ailability V Y) /?*) / U ) R+Z 6 #::] Software Safet1 Software safet* is a software !uality assurance acti"ity that focuses on the identification and assessment of potential ha8ards that may affect software negati"ely and cause an entire system to fail. If ha8ards can be identified early in the software process, software design features can be specified that will either eliminate or control potential ha8ards. ( modeling and analysis is conducted as part of software safety. Initially, ha8ards are identified and categori8ed by criticality and ris-. /or e6ample, some of the ha8ards associated with a computer.based cruise control for an automobile might be. Causes uncontrolled acceleration that cannot be stopped. Does not respond to depression of bra-e pedal. Does not engage when switch is acti"ated. Slowly loses or gains speed.

1<.D T&E ISO A::: ;U(AIT0 STANDARDS

( !uality assurance system may be defined as the organi8ational structure, responsibilities, procedures, processes, and resources for implementing !uality management. <uality assurance systems are created to help organi8ations ensure their products and ser"ices satisfy customer e6pectations by meeting their specifications. IS7 $::: describes a !uality assurance system in generic terms that can be applied to any business regardless of the products or ser"ices offered. The ISO A::12+::: Stan!ar! IS7 $::#:>::: is the !uality assurance standard that applies to software engineering. he standard contains >: re!uirements that must be present for an effecti"e !uality assurance system. he re!uirements delineated by IS7 $::#:>::: address topics such as ##5

)anagement responsibility, !uality system, contract re"iew, design control, document and data control, product identification and traceability, process control, inspection and testing, correcti"e and pre"enti"e action, control of !uality records, internal !uality audits, training, ser"icing, and statistical techni!ues. JJJJJJJJJ

UNIT WISE ;UESTIONS UNIT O I

#. @hat is meant by softwareF Discuss in detail the e"ol"ing role of software. 7R '6plain the e"ol"ing role of software. >. Discuss in detail "arious characteristics of software. %. @hat is meant by ASoftware mythBF Discuss on "arious types of software myths and the true aspects of these myths. 7R '6plain the Software myths 5. '6plain in detail "arious software engineering layers. 7R @hat do you mean by software 'ngineeringF '6plain the software engineering layers. H. '6plain in detail the capability )aturity )odel Integration *C))I+ 7R '6plain the process maturity le"els in detail. =. '6plain in detail the process patterns with suitable e6amples. 4. Discuss in detail "arious characteristics of software. 9. '6plain briefly the different categories of computer software a"ailable today. (lso describe the recent challenges faced by it.

##H

$. @ith the help of a diagram discuss on software process framewor-. @hat are the fi"e generic process frame wor- acti"itiesF #:. Define a tas- set. 3ist the entities of tas- set for relati"ely small and simple proGect as well as for large and comple6 software proGect. ##. Draw the diagram depicting the software process and methods applied for assessment and impro"ement. (lso e6plain the techni!ues which are used to access the software process. JJJJJJJ

UNIT O II
#. @ith the help of the diagram discuss in detail waterfall model. ;i"e certain reasons for its failure. >. @rite briefly on *a+ the incremental model *b+ he R(D )odel 7R Describe the incremental software de"elopment process model. %. '6plain the Spiral model in detailF 5. @ith the help of the diagram e6plain the concurrent de"elopment model 7R Describe the elements of concurrent process model. H. @hat is meant by unified processF 'laborate on the unified process wor- products. =. Discuss the user re!uirements in detail. 7R @rite short notes on user re!uirements. @hat is re!uirements amalgamationF 4. Discuss in detail the system re!uirements along with locations for re!uirements specification. 9. 'laborate on software re!uirements document. $. @hat is meant by prototypingF Discuss in detail the Prototyping modelF #:. Discuss "arious phases of the unified process in detail. ##=

##. @hat are functional re!uirements of softwareF Discuss in detail. #>. Discuss the non.functional re!uirements of software in detail. #%. '6plain the structured language specifications in detail. Draw a se!uence diagram narrating "arious conse!uences during ( ) with drawal. JJJJJJJ

UNIT O III
#. @ith the help of diagram depict the re!uirements engineering process. (lso e6plain the spiral model of re!uirements engineering. >. 'laborate on /easibility studies. %. 'laborate on re!uirements elicitation and analysis process. 7R '6plain the re!uirements analysis techni!ues. 5. 'laborate on re!uirements disco"ery and "iew points. H. '6plain the 'thnography in detail. =. 'laborate on re!uirements management. 4. 'laborate on conte6t models. 9. @rite short notes on *a+ Data flow model *b+ State machine model. $. @hat are the use casesF Draw the use cases for library system. #:. Draw an interaction diagram for ( ) with drawal. ##. 3ist the number of chec-s which are to be carried out on the re!uirements in the re!uirements documents and the number of "alidation techni!ues. #>. '6plain briefly of re!uirements re"iews. ##4

#%. '6plain briefly on re!uirements change management process. #5. ;i"e few e6amples of types of models essential during the analysis process. #H. '6plain the data models with suitable e6amples also state few ad"antages of using a data dictionary. #=. ;i"e e6amples diagram for each of the following: *a+ Inheritance )odels *b+ 7bGect (ggregation *c+ 7bGect beha"ior model. #4. 'laborate on Structured methods. JJJJJJJJ

UNIT O I'
#. ;i"e few characteristics of good design. >. Illustrate on the following software attributes. *a+ functionality *b+ Csability *c+ Reliability *d+ performance *e+ supportability
7R

'6plain "arious software !uality standards and discuss how to assure them . %. @hat are the characteristics of well formed designF 5. @hat is architectureF Describe its importance. H. Discuss briefly on data design at the architectural le"el and Data design at the component le"el. =. '6plain *a+ Data Centered (rchitecture *b+ Data /low (rchitecture with the help of diagrams. 4. @hat is meant by (rchetypeF Csing a diagram e6plain few (rchetypes. 9. '6plain the process of refining the architecture into components with the help of a diagram. $. '6plain how instantiation of the architecture can be de"eloped with the help of a diagram. #:. @rite short notes on the following: *a+ (bstraction *b+ (rchitecture *c+ Patterns *d+ )odularity *f+ functional independence *g+ refinement *h+ Refactoring. *e+ information hiding

##. @hat are design classesF @hat are the types of classes created by the designerF #>. 'laborate on design model. #%. '6plain briefly on Data design elements and architectural design elements. #5. @rite short notes on interface design elements, component le"el design elements and deployment le"el design elements. #H. @hat are architectural stylesF '6plain briefly.

##9

#=. @rite short notes on architectural patterns. #4. @ith the help of a diagram e6plain call and return architecture and layered architecture. #9. '6plain the following terms with respect to the architectural patterns *a+ Concurrency *b+ Persistence *c+ Distribution #$. Draw the architectural conte6t diagram. '6plain different parts used in this diagram. >:. Draw the architectural diagram depicting the safe home security systems. >#. @ith the help of a diagram e6plain the process of refining the architecture into components.

JJJJJJJJ

UNIT O '
#. '6plain in detail the obGects and classes along with their notations. (lso e6plain the generali8ation hierarchy and association models. >. @rite short notes on *a+ concurrent 7bGects *b+ system conte6t and models of use. %. '6plain in detail the obGect identification process. 7R '6plain in detail obGect identification 7R @hat is an 7bGectF @hat are the ways of identifying obGectF 5. '6plain in detail on obGect interface specification. H. '6plain briefly the design e"olution. 7R '6plain briefly on design e"olution. =. APlace the user in controlB 'laborate. 4. '6plain in detail the interface analysis and design models. 9. '6plain the Cser interface design process. 7R @hat are the goals of the user interface designF $. '6plain the following terms *a+ 7bGect oriented analysis *c+ 7bGect oriented Programming. *b+ 7bGect oriented design

#:. ;i"e an e6ample with a diagram depicting the interaction of obGects. ##. '6plain in detail the obGect oriented design process. (lso gi"e the layered architecture for whether mapping system and sub systems in the whether mapping system.

##$

#>. @rite short notes on *a+ sub systems models *b+ Se!uence model *c+ state machine model. #%. AReduce the user memory loadB 'laborate. #5. A)a-e the interface consistentB 'laborate. #H. @rite short notes on *a+ Csed cases *b+ as- 'laboration *c+ 7bGect elaboration with respecti"e user interface design. #=. @rite short notes on *a+ wor- flow analysis *b+ 2ierarchical representation. #4. 'laborate on "arious interface design steps. #9. @ith the help of a diagram e6plain in detail interface design e"olution cycle.

JJJJJJJJ

UNIT O 'I
#. Define ASoftware estingB. ;i"e few generic characteristics of it. >. Discuss briefly on *a+ Nerification *b+ Nalidation. %. '6plain in detail the unit testing along with unit te6t procedures. 7R '6plain QCnit testing0. 5. '6plain briefly on integration testing. Discuss on top down integration by specifying different step to achie"e it and "arious criti!ues encounted during this approach. 7R '6plain top.down integration testing. H. @rite short notes on *a+ bottom up Integration *b+ Regression testing *c+ Smo-e esting. 7R @hat is meant by bottom.up integration testF '6plain how it is implementedF

=. @hat is meant by system testingF @rite short notes on the following with respect to system testing *a+ Reco"ery esting *b+ Security esting *c+ Stress testing *d+ Performance testing 4. @ith the help of a diagram e6plain the debugging process. 9. @hile correcting an error, what are the important facts to be consideredF 7R Describe "arious conse!uence of correcting the error. $. Discuss in detail *a+ )ccall0s <uality factors *b+ IS7 $#>= <uality factors. #:. Discuss in detail the metrics for testing. ##. Discuss o"erall strategy for software testing also discuss on software testing steps. #>. '6plain briefly on software testing strategy for obGect oriented architecture. #%. '6plain the terminating issued of testing.

#>:

#5. 3ist "arious ad"antages of using smo-e testing on comple6 time critical software engineering proGects. #H. @hat is critical module in integration testing and describe its characteristics. #=. Describe the following terms with respecti"e "alidation testing *a+ Nalidation test criteria *b+ configuration re"iew *c+ (lpha K Ieta esting. #4. 3ist the reason which leads us to the comple6ity of debugging. #9. Discuss "arious debugging strategies. #$. Discuss briefly on blac- bo6 and white bo6 testing. >:. Discuss in detail on function based metrics. >#. Discuss in detail the architectural design metrics. >>. Discuss the nine distinct and measurable characteristics of obGect oriented design. >%. Discuss the class oriented metrics.the )77D metrics suite. >5. Discuss the class oriented metrics.the CX metrics suite. >H. @rite short notes on *a+ component le"el design metrics *b+ 7peration 7riented )etrics. >=. @rite shorts notes on *a+ metrics for source code *b+ metrics for maintenance.
JJJJJJJJJJ

UNIT O 'II
#. @rite short notes on the following with respect to software measurement *a+ si8e oriented )etrics *b+ function.oriented metrics. 7R abulate the similarities and differences between si8e oriented, function oriented metrics. >. @rite short notes on *a+ Reacti"e "s Proacti"e ris- strategies *b+ Ris-s encountered during software de"elopment. %. '6plain in detail how ris-s are identified during software de"elopment. 7R @hat do you understand by ris- identificationF @hat are the popular techni!ues de"elop for this purpose. 5. '6plain briefly on A(ccessing ris- ImpactB. 7R @hat is meant by ris- assessmentF @hat are the different steps to be performed in risassessmentF '6plain. H. '6plain in detail the Ris- )itigation, )onitoring and management or R))). =. @rite short notes on *a+ 7bGect oriented metrics *b+ use case oriented metrics. 4. '6plain briefly the @eb engineering proGect metrics.

#>#

9. '6plain the following terms with respect to measuring *a+ Csability *b+ Integrity *c+ )aintainability *d+ Correctness. $. @rite short notes on defect remo"al efficiency.

software

!uality

#:. 3ist four ris-s proGection steps and e6plain the process of de"eloping ris- tables. ##. '6plain in detail R))) Plan. #>. @rite short notes on Ris- Refinement. JJJJJJJJ

UNIT O 'III
#. '6plain "arious acti"ities performed by software !uality assurance or S<( group. 7R Discuss about S<( acti"ities. >. '6plain in detail on "arious aspects of software re"iews. %. @rite short notes on the following with respect to formal technical re"iews *a+ the re"iew meeting *b+ re"iew reporting and record -eeping. 7R Discuss in detail about formal technical re"iews */ R+ performed by software engineers. 7R @hat is formal technical re"iewF '6plain how it will assess software design !uality. 5. '6plain briefly on the following with respect to formal technical re"iews *a+ Re"iew guidelines *b+ sample.dri"en re"iews. 7R @hat is formal technical re"iewF '6plain how it will assess software design !uality. H. @rite short notes on si6 sigma for software engineering and software reliability. =. @rite short notes on software reliability. 4. '6plain briefly on *a+ )easures of reliability and a"ailability *b+ software safety #>>

7R Discuss about measure of software reliability and software a"ailability. 9. @rite short note on the S<( plan. 7R '6plain the software !uality (ssurance *S<(+ plan. 7R Discuss about S<( acti"ities. $. @rite short notes on *a+ <uality *b+ <uality control *c+ <uality assurance *d+ cost of !uality. #:. Define Software !uality and write about its bac-ground issues. ##. 3ist the essential steps to perform statistical software !uality assurance. (lso pro"ide a generic e6ample to support your Gustifications. JJJJJJJJJ

#>%