!njalai !

mmal -ahalingam %ngineering 0ollege Department of 0omputer 1cience and %ngineering

Unit-III Design Concepts and Principles

Design Concepts: 1. Abstraction: It concentrate on the essential features and ignore details that are not relevant Procedural abstraction = a named sequence of instructions that has a specific & limited function e.g. Open (for the door) Data abstraction = a named collection of data that describes a data object e.g. Door Control abstraction = implies a program control mechanisms without specif internal details 2. Software architecture It defines overall structure of the software components and the wa s in which that structure provides conceptual integrit for a s stem . Patterns ! design pattern defines a design structure that solves a particular design problem within a specific conte"t and aimed #forces$ that ma have an impact on the manner in which the pattern is applied and used. %ach design pattern must determine the following& 'hether the pattern applicable to the current wor( 'hether the pattern can be reused. 'hether the pattern can serve as a guide for developing a similar) but functionalit or structurall different pattern. !. Infor"ation #iding: Information (data and procedure) contained within a module is inaccessible to modules that have no need for such information $. %efine"ent: *rocess of elaboration where the designer provides successivel more detail for each design component. &. 'odularit(& +he software is divided into separatel named and addressable components) sometimes called modularit . +here are , criteria to evaluate design method with effective modular design& -odular decomposabilit . provides s stematic means for brea(ing problem into sub problems -odular composabilit . supports reuse of e"isting modules in new s stems -odular understandabilit . module can be understood as a stand.alone unit -odular continuit . side.effects due to module changes minimi/ed -odular protection . side.effects due to processing errors minimi/ed ). *unctional Independence: +he functional independence is achieved b developing the functional modules with single. minded approach.

Cohesion: 2unctional strength of the module. ! cohesive module perform a single tas(. 3ow tightl bound or related 4a module5s6 internal elements are to one another. Coincidental: module performs unrelated functions #bad$ +ogical: module performs functions that are related onl logicall ,e"poral: module performs more than one function) but the all happen within a well.defined time span. Procedural: module performs more than one function) but the all do functions that are related Co""unicational: module performs more than one function) but the are all on the same bod of data. *unctional : Coupling: +he degree of interdependence between modules. Content coupling: modules can directl refer to the contents of each other. Co""on coupling: modules communicate via global data. Control coupling: modules communicate b data that allows one module to directl affect the behavior of the other. Sta"p coupling: modules communicate b a heterogeneous set of items) not all of which are used. Data coupling: modules communicate b parameters) where each parameter is a single item or a homogeneous set that incorporate no control element. -o coupling: there is no relationship. .. %efactoring: 7efactoring is a reorgani/ation technique that simplifies the design(or code) of a component without changing its function or behavior. /. Data structure: 7epresentation of the logical relationship among individual data elements (requires at least as much attention as algorithm design) 10. Software procedure: *recise specification of processing (event sequences) decision points) repetitive operations) data organi/ation8structure) 11. Design Classes: User interface classes 9 define abstractions necessar for 30I. 1usiness do"ain classes 9 refinements of anal sis classes. Process classes 9 lower.level business abstractions that manage business domain classes. Persistent classes 9 data stores (databases) that persist be ond e"ecution of the software S(ste" classes 9 management and control functions that enable the s stem to operate and communicate within its computing environment and with the outside world. Design Process: Design *rocess is a sequence of activities to develop the software design product. Design 2uidelines:

 ! design should e"hibit good architectural structure ! design should be modular ! design should contain distinct representations of data) architecture) interfaces) and components (modules) ! design should lead to data structures that are appropriate for the objects to be implemented and be drawn from recogni/able design patterns ! design should lead to components that e"hibit independent functional characteristics ! design should lead to interfaces that reduce the comple"it of connections between modules and with the e"ternal environment. ! design should be derived using a reputable method that is driven b information obtained during software requirements anal sis. Design Principles: +he design process should not suffer from tunnel vision +he design should be traceable to the anal sis model +he design should not reinvent the wheel +he design should minimi/e intellectual distance between the software and the problem as it e"ists in the real world +he design should e"hibit uniformit and integration +he design should be structured to accommodate change +he design should be structured to degrade gentl ) even with bad data) events) or operating conditions are encountered +he design should be assessed for qualit as it is being created +he design should be reviewed to minimi/e conceptual (semantic) errors. Design #euristics for 3ffecti4e 'odularit(: %valuate the first iteration of the program structure to reduce coupling and improve cohesion. !ttempt to minimi/e structures with high fan.out: strive for fan.in as structure depth increases. ;eep the scope of effect of a module within the scope of control for that module. %valuate module interfaces to reduce comple"it ) reduce redundanc ) and improve consistenc . Define modules whose function is predictable and not overl restrictive (e.g. a module that onl implements a single sub function). 1trive for controlled entr modules) avoid pathological connection (e.g. branches into the middle of another module) Design 'odel:

Data Design 3le"ents: Data design creates a model of data that is represented at a high level of abstraction 7efined progressivel to more implementation.specific representation for processing b the computer base s stem +ranslation of data model into a data base is pivotal to achieving business objective of a s stem !t Progra" co"ponent le4el-< data structures and associated algorithms are designed. !t application le4el.< +ranslation of data model into a data base is pivotal to achieving business objective of a s stem !t business le4el-< transformation of database into data warehouse. Architectural Design 3le"ents: !rchitectural design is equivalent to the floor plan of the house. Derived from three sources (=) Information about the application domain of the software (>) !nal sis model such as dataflow diagrams or anal sis classes. (?) !rchitectural pattern and st les Interface Design ele"ents: 1et of detailed drawings constituting& (=) @ser interface (>) %"ternal interfaces to other s stems) devices etc (?) Internal interfaces between various components Co"ponent le4el design ele"ents: 2ull describe the internal details of each software component %.g. wiring) plumbing within each room @-A diagram can be used

SensorManagement

Sensor

Deplo("ent le4el design ele"ents: Indicates how software functionalit and subs stem will be allocated within the ph sical computing environment. @-A deplo ment diagram is developed and refined.

Architectural Design: !rchitectural Design is the design process for identif ing the subs stems ma(ing up the s stem and framewor( for subs stem control and communication. Software Architecture: +he software architecture of a program or computing s stem is the structure or structures of the s stem) which comprise the software components) the e"ternall visible properties of those components) and the relationships among them.

Ad4antages:

5h( Architecture is I"portant6

'odels for Architectural Design:

#ori7ontal Partitioning: It defines separate branches of the modular hierarch for each major program function Defines ? partition = Input) *rocess) Output

1enefits: eas to test software eas to maintain software Drawbac8s: causes more data to be passed across module interfaces) complicate overall control of program flow 9ertical Partitioning: control (decision ma(ing) & wor( should be distributed +op.Down in program structure top level modules 9 do control function) low level modules 9 do the wor(s( input) computation) output tas(s ) ! change in control module will affect the subordinates. ! change in wor(er module will less li(el effect others. 7epresentation of the logical relationship among individual elements of data.

1enefits: %as to maintain the changes. 7educe the change impact and error propagation. Data Design: +ransforming the anal sis information model (data dictionar and %7D) into data structures required to implement the software.

Data Design at architectural +e4el:

Data Design at Co"ponent +e4el: =. +he s stematic anal sis principles applied to function and behavior should also be applied to data. >. !ll data structures and the operations to be performed on each should be identified. ?. ! data dictionar should be established and used to define both data and program design.

B. Aow level data design decisions should be deferred until late in the design process. ,. +he representation of data structure should be (nown onl to those modules that must ma(e direct use of the data contained within the structure. C. ! librar of useful data structures and the operations that ma be applied to them should be developed. D. ! software design and programming language should support the specification and reali/ation of abstract data t pes. Architectural St(les: %ach st le describes a s stem categor that encompasses& (=) ! set of components (database, clients, servers and filters) (>) ! set of connectors that enables #communication and coordination(call) event broadcasting) pipes) (?) Constraints that define how components can be integrated to form the s stem (B: Semantic models to understand the overall properties of a s stem Data Centered Architecture: ! data store (e.g.) a file or database) resides at the center of this architecture and is accessed frequentl b other components that update) add) delete) or otherwise modif data within the store. It promotes integrabilit .

Data *low Architecture: 1hows the flow of input data) its computational components and output data 1tructure is also called pipe and 2ilter *ipe provides path for flow of data 2ilters manipulate data and wor( independent of its neighboring filter

Call and %eturn Architecture: !chieves a structure that is eas to modif and scale +wo sub st les (=) -ain program8sub program architecture .. 0lassic program structure .. -ain program invo(es a number of components) which in turn invo(e still other components (>) 7emote procedure call architecture .. 0omponents of main program8subprogram are distributed across computers over networ(

;b<ect ;riented Architecture: +he components of a s stem encapsulate data and the operations 0ommunication and coordination between components is done via message

+a(ered Architecture: ! number of different la ers are defined Inner Aa er( interface with O1) Intermediate Aa er @tilit services and application function) Outer Aa er (@ser interface)

Architectural Design: +he architectural design begins with representing the s stem in the conte"t i.e.) defining the e"ternal entities. Once all e"ternal software has been described) the designer specifies the structure of the s stem b defining and refining software components. %epresenting the s(ste" in the conte=t:

*ig: Architectural Conte=t Diagra" for Safe #o"e Securit( S(ste Defining Archet(pes:

*ig: Arche,(pe for Safe #o"e Securit( S(ste" %efining the Architecture into Co"ponents:

,ransfor" 'apping: ,ransfor" *low: Data coming from e"ternal forms must be converted into an internal form for processing. Design Steps for ,ransfor" 'apping: 7eview the fundamental s stem model to identif the information flow. 7eview and refine the data flow diagrams for the software. Determine if the D2D has the transform or transaction flow characteristics. Isolate the transform centre b specif ing incoming and outgoing flow boundaries. *erform first level factoring. *erform second level factoring. 7efine the first.iteration architecture using design heuristics for improved software qualit . ,ransaction 'apping: ,ransaction *low: Information flow is characteri/ed b a single data item) called a transaction that triggers other data flow along one of man paths. Design Steps for ,ransaction 'apping: 7eview the fundamental s stem model to identif the information flow. 7eview and refine the data flow diagrams for the software. Determine if the D2D has the transform or transaction flow characteristics. Identif the transaction centre and flow characteristics along each of the action paths. -ap D2D into transaction processing structure

 2actor and refine the transaction structure and structure of each action path. 7efine the first.iteration architecture using design heuristics for improved software qualit . User Interface Design Principles: Define interaction modes in a wa that does not force a user into unnecessar or undesired actions. *rovide for fle"ible interaction. !llow user interaction to be interruptible and undoable. 1treamline interaction as s(ill levels advance and allow the interaction to be customi/ed. 3ide technical internals from the casual user. Design for direct interaction with objects that appear on the screen. 'hile designing the user interface the capabilit ) need and e"perience of s stem user should be considered. User *a"iliarit(: Instead of using computer terminolog ma(e use of user oriented terminologies. Consistenc(: +he appropriate level of consistenc should be maintained in the user interface. 'ini"al Surprise: +he commands should operate in a (nown wa . %eco4erabilit(: +he s stem should provide a recovering facilit to user from his errors so that user can correct those errors. User 2uidance: +he user interface can be effectivel used b a novice user if some user guidance such as help s stems) online manuals etc.) %eal ,i"e S(ste"s: ! real.time s stem is a software s stem where the correct functioning of the s stem depends on the results produced b the s stem and the time at which these results are produced. Soft %eal ,i"e S(ste":- ! Esoft5 real.time s stem is a s stem whose operation is degraded if results are not produced according to the specified timing requirements #ard %eal ,i"e S(ste"&. ! Ehard5 real.time s stem is a s stem whose operation is incorrect if results are not produced according to the timing specification. %eal ,i"e Software Design: 1timulus8response s stem.Fiven a stimulus) the s stem must produce a response within a specified time. +here are two t pes& Periodic sti"uli& 1timuli which occur at predictable time intervals G 2or e"ample) a temperature sensor ma be polled =H times per second Aperiodic sti"uli: 1timuli which occur at unpredictable times G 2or e"ample) a s stem power failure ma trigger an interrupt which must be processed b the s stem

%eal ,i"e S(ste" Design: Design both the hardware and the software associated with s stem. *artition functions to either hardware or software Design decisions should be made on the basis on non.functional s stem requirements 3ardware delivers better performance but potentiall longer development and less scope for 0hange %eal ,i"e S(ste" Design Process: =. Identif the stimuli to be processed and the required responses to these stimuli >. 2or each stimulus and response) identif the timing constraints ?. !ggregate the stimulus and response processing into concurrent processes. ! process ma be associated with each class of stimulus and response B. Design algorithms to process each class of stimulus and response. +hese must meet the given timing requirements ,. Design a scheduling s stem which will ensure that processes are started in time to meet their deadlines C. Integrate using a real.time e"ecutive or operating 1 stem ,i"ing constraints: -a require e"tensive simulation and e"periment to ensure that these are met b the s stem -a mean that certain design strategies such as object.oriented design cannot be used because of the additional overhead involved -a mean that low.level programming language features have to be used for performance reasons %eal ,i"e S(ste" 'odeling: 7eal +ime s stems have to respond to events occurring at irregular intervals. +he effect of a stimulus in a real.time s stem ma trigger a transition from one state to another. 2inite state machines can be used for modeling real.time s stems. +he @-A includes notations for defining state machine models

Full power

Full power do: set power = 600

W aiting do: display time Full po wer Half po wer

Timer Number Set time do: get number exit: set time Door closed Door open Half power do: set power = 300 Door closed Disabled do: display 'W aiting' Start Enabled do: display 'Ready' System fault W aiting do: display time Operation do: operate oven Cancel

Half po wer

Timer

%eal ti"e Progra""ing: 3ard.real time s stems ma have to programmed in assembl language to ensure that deadlines are met Aanguages such as 0 allow efficient programs to be written but do not have constructs to support concurrenc or shared resource management !da as a language designed to support real.time s stems design so includes a general purpose concurrenc mechanism >a4a as a %eal ti"e s(ste": Iava supports lightweight concurrenc (threads and s nchroni/ed methods) and can be used for some soft real.time s stems Iava >.H is not suitable for hard 7+ programming or programming where precise control of timing is required. +he reasons are& G Jot possible to specif thread e"ecution time G @ncontrollable garbage collection G Jot possible to discover queue si/es for shared resources G Kariable virtual machine implementation G Jot possible to do space or timing anal sis %eal ,i"e 3=ecuti4es: 7eal.time e"ecutives are speciali/ed operating s stems which manage the processes in the 7+1 7esponsible for process management and resource (processor and memor ) allocation -a be based on a standard 7+% (ernel which is used unchanged or modified for a particular application Does not include facilities such as file -anagement ,he e=ecuti4e co"ponents are: %eal-ti"e cloc8 . *rovides information for process scheduling.

Interrupt handler. -anages aperiodic requests for service. Scheduler. 0hooses the ne"t process to be run. %esource "anager. !llocates memor and processor resources. Despatcher . 1tarts process e"ecution. Configuration "anager- 7esponsible for the d namic reconfiguration of the s stem software and hardware. 3ardware modules ma be replaced and software upgraded without stopping the s stems *ault "anager. 7esponsible for detecting software and hardware faults and ta(ing appropriate actions (e.g. switching to bac(up dis(s) to ensure that the s stem continues in operation +he processing of some t pes of stimuli must sometimes ta(e priorit Interrupt le4el priorit(- 3ighest priorit which is allocated to processes requiring a ver fast response Cloc8 le4el priorit(- !llocated to periodic processes

S c h e d u li n g in f o r m a ti o n

R e a l ti m e c l o c k

S c h e d u le r

I n te r r u p t h a n d le r

P r o c e s sr e s o u r c e r e q u i r e m e n ts

P r o c e s s e s a w a i ti n g r e s o u r c e s

R e s o u rc e m a n a g e r R e a d y p r o c e s s e s R e l e a s e d r e s o u r c e s

A v a i la b l e r e s o u r c e li s t

R e a d y li s t

D e s p a tc h e r E x e c u ti n g p r o c e s s

P r o c e s s o r li s t

Process 'anage"ent:

S c h e d u l e r C h o o s ep r o c e s s f o re x e c u t i o n

R e s o u r c em a n a g e r A l l o c a t em e m o r y a n dp r o c e s s o r

D e s p a t c h e r S ta r te x e c u ti o no na n a v a i la b l ep r o c e s s o r

0oncerned with managing the set of concurrent processes

*eriodic processes are e"ecuted at pre.specified time intervals +he e"ecutive uses the real.time cloc( to determine when to e"ecute a process *rocess period . time between e"ecutions *rocess deadline . the time b which processing must be complete +he scheduler chooses the ne"t process to be e"ecuted b the processor. +his depends on a scheduling strateg which ma ta(e the process priorit into account +he resource manager allocates memor and a processor for the process to be e"ecuted +he despatcher ta(es the process from read list) loads it onto a processor and starts e"ecution -on pre-e"pti4e scheduling G Once a process has been scheduled for e"ecution) it runs to completion or until it is bloc(ed for some reason (e.g. waiting for I8O) Pre-e"pti4e scheduling G +he e"ecution of e"ecuting processes ma be stopped if a higher priorit process requires service Scheduling algorith"s G 7ound.robin G 7ate monotonic G 1hortest deadline first Data Ac?uisition S(ste": 0ollect data from sensors for subsequent processing and anal sis. Data collection processes and processing processes ma have different periods and deadlines. Data collection ma be faster than processing e.g. collecting information about an e"plosion. 0ircular or ring buffers are a mechanism for smoothing speed differences. %eactor Data Collector:
S e n s o r s( e a c hd a taf lo wi s a se n so rv a l u e ) S e n s o r id e n ti f ie ra n d v a l u e S e n s o r S e n s o rd a ta p r o c e ss b u f f e r P r o c e ss e d f lu xl e v e l P r o c e ss d a ta D isp la y

P r o d u c e r p r o c e s s

C o n s u m e r p r o c e s s

 ! s stem collects data from a set of sensors monitoring the neutron flu" from a nuclear reactor. 2lu" data is placed in a ring buffer for later processing. +he ring buffer is itself implemented as a concurrent process so that the collection and processing processes ma be s nchroni/ed. 'utual 3=clusion: *roducer processes collect data and add it to the buffer. 0onsumer processes ta(e data from the buffer and ma(e elements available *roducer and consumer processes must be mutuall e"cluded from accessing the same element. +he buffer must stop producer processes adding information to a full buffer and consumer processes tr ing to ta(e information from an empt buffer. Software Configuration 'anage"ent @SC':: 10- identifies) organi/es) and controls modifications to the software being built b a software development team throughout the software process. -eed for SC': +he software configuration management is concerned with managing the changes in the evolving software. If the changes are not controlled at all then this stream of uncontrolled change can cause the well.running software project into chaos. 3ence it is essential to identif change) control the changes) ensure that the changes are properl implemented and report these changes to others. !nd to carr out these set of activities the software configuration is essential. 3le"ents of Configuration 'anage"ent S(ste": Co"ponent ele"ents :-! set of tools coupled with a file management (e.g.) database) s stem that enables access to and management of each software configuration item Process ele"ents:- ! collection of procedures and tas(s that define an effective approach to change management for all participants Construction ele"ents:- ! set of tools that automate the construction of software b ensuring that the proper set of valid components (i.e.) the correct version) is assembled #u"an ele"ents:- ! set of tools and process features used b a software team to implement effective 101aselines: I333 Definition: ! specification or product that has been formall reviewed and agreed upon) and that thereafter serves as the basis for further development) and that can be changed onl through formal change control procedures It is a milestone in the development of software and is mar(ed b the deliver of one or more computer software configuration items (010Is) that have been approved as a consequence of a formal technical review 1aseline Processes: ! series of software engineering tas(s produces a 010I +he 010I is reviewed and possibl approved +he approved 010I is given a new version number and placed in a project database (i.e.) software repositor )

 ! cop of the 010I is ta(en from the project database and e"amined8modified b a software engineer +he baselining of the modified 010I goes bac( to 1tep L>
modified SC Is Project databas e Softw are engineering tas k s Formal technical review s approved SC Is s tored SC Is extracted SC M controls SC Is BASELIN ES : Sys tem Specification Softw are R equirements D es ign Specification Source C ode Tes t Plans /Procedures /D ata O perational Sys tem

SC Is

Software Configuration Ite"s:

D a t am o d e l D e s ig ns p e c if ic a t io n d a t ad e s ig n a r c h it e c t u r a ld e s ig n m o d u led e s ig n in t e r f a c ed e s ig n C o m p o n e n tN in t e r f a c ed e s c r ip t io n a lg o r it h m d e s c r ip t io n P D L

T e s ts p e c if ic a t io n t e s tp la n t e s tp r o c e d u r e t e s tc a s e s

S o u r c ec o d e

SC' %epositor(:

 +he 10- repositor is the set of mechanisms and data structures that allow a software team to manage change in an effective manner +he repositor performs or precipitates the following functions Data integrit(=>Kalidates entries) ensures consistenc ) cascades modifications Information sharing=<1hares information among developers and tools) manages and controls multi.user access Tool integration=<%stablishes a data model that can be accessed b software engineering tools) controls access to the data Data integration=<!llows various 10- tas(s to be performed on one or more 010Is Methodology enforcement=<Defines an entit .relationship model for the repositor that implies a specific process model for software engineering Document standardization=>Defines objects in the repositor standard approach for creation of software engineering documents SC' *eatures: 9ersioning. o saves all of these versions to enable effective management of product releases and to permit developers to go bac( to previous versions Dependenc( trac8ing and change "anage"ent. o +he repositor manages a wide variet of relationships among the data elements stored in it. %e?uire"ents tracing. o *rovides the abilit to trac( all the design and construction components and deliverables that result from a specific requirement specification Configuration "anage"ent. o ;eeps trac( of a series of configurations representing specific project milestones or production releases. Kersion management provides the needed versions) and lin( management (eeps trac( of interdependencies. Audit trails. to guarantee a man

o SC' Process:

%stablishes additional information about when) wh ) and b whom changes are made.

+he 10- process defines a series of tas(s that have four primar objectives. +he are& Identif all items that collectivel define the software configuration -anage changes to one or more of these items 2acilitate construction of different versions of an application %nsure the software qualit is maintained as the configuration evolves over time *rovide information on changes that have occurred

Identification of ;b<ects in the Software Configuration: Identification separatel names each 010I and then organi/es it in the 10- repositor using an object.oriented approach Objects start out as basic objects and are then grouped into aggregate objects %ach object has a set of distinct features that identif it ! name that is unambiguous to all other objects ! description that contains the 010I t pe) a project identifier) and change and8or version information Aist of resources needed b the object +he object reali/ation (i.e.) the document) the file) the model) etc.) 9ersion Control: Kersion control combines procedures and tools to manage different versions of configuration objects that are created during the software process

 ! version control s stem implements or is directl capabilities&

integrated with four major

a project database (repository) that stores all relevant configuration objects a version management capabilit that stores all versions of a configuration object (or enables an version to be constructed using differences from past versions): a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software. an issues tracking (also called bug tracking) capabilit that enables the team to record and trac( the status of all outstanding issues associated with each configuration object. +he 10- repositor maintains a change set 1erves as a collection of all changes made to a baseline configuration @sed to create a specific version of the software 0aptures all changes to all files in the configuration along with the reason for changes and details of who made the changes

Change Control: 0hange control is a procedural activit that ensures qualit and consistenc as changes are made to a configuration object ! change request is submitted to a configuration control authorit ) which is usuall a change control board (00M) +he request is evaluated for technical merit) potential side effects) overall impact on other configuration objects and s stem functions) and projected cost in terms of mone ) time) and resources !n engineering change order (%0O) is issued for each approved change request Describes the change to be made) the constraints to follow) and the criteria for review and audit +he baselined 010I is obtained from the 10- repositor

 !ccess control governs which software engineers have the authorit to access and modif a particular configuration object 1 nchroni/ation control helps to ensure that parallel changes performed b two different people donNt overwrite one another.

Distribute the new 4ersion Configuration Audit: 0onfiguration auditing is an 1O! activit that helps to ensure that qualit is maintained as changes are made It complements the formal technical review and is conducted b the 1O! group It addresses the following questions& o 3as the change specified in the %0O been madeP 3ave an modifications been incorporatedP o 3as a formal technical review been conducted to assess technical correctnessP o 3as the software process been followed) and have software engineering standards been properl appliedP o 3as the change been QhighlightedQ and QdocumentedQ in the 010IP 3ave the change data and change author been specifiedP configuration object reflect the changeP o 3ave 10- procedures for noting the change) recording it) and reporting it been followedP o 3ave all related 010Is been properl updatedP ! configuration audit ensures that the correct 010Is (b version) have been incorporated into a specific build that all documentation is up.to.date and consistent with the version that has been built Status %eporting: Do the attributes of the additional

 0onfiguration status reporting (017) is also called status accounting. *rovides information about each change to those personnel in an organi/ation with a need to (now !nswers what happened) who did it) when did it happen) and what else will be affectedP 1ources of entries for configuration status reporting. %ach time a 010I is assigned new or updated information %ach time a change is approved b configuration audit is conducted +he configuration status report. *laced in an on.line database or on a website for software developers and maintainers to read Fiven to management and practitioners to (eep them appraised of important changes to the project 010Is the 00M and an %0O is issued. %ach time a