SAD final exam by ravikiran

Part of design phase of SDLC
Determine what code modules are required Determine how code modules will work together to form the progra­mD­evelop specific instru­ctions for develo­pment team on how code modules should be written
Techniques in program design­St­ructure chart Program specif­ica­tions
Designing Progra­ms­Pla­nning before coding generally improves the develo­pment proces­sNever begin writing code without having a
complete unders­tanding of what code must doMit­igates risk of:
 Ineffi­cient programs  Incomp­atible programs  Programs missing key functi­ona­lity--- Program design goalP­rogram design that is modular and flexible
Top-down modular approach to design­De­termine major program components first,then detailed sub-co­mpo­nents supporting them Eases unders­tanding and commun­ication of design­Pr­ocess of program decomp­osition
Designing Progra­ms­Modular design advant­age­sCode that is easier to understand Code that is reusable Code that has less redundancy Code that is easier to mainta­in­Program modules should be decomposed until they perform a single functi­on-­--P­rogram design docume­nt­Pre­pared at completion of program design­Co­mpo­nents Program structure chart  Program specif­ica­tio­nsS­tru­cture Chart­Hie­rar­chical, high-level depiction of all
modular components of an progra­mE­mph­asizes structure and reusab­ility Modules should perform a single functi­on­Details sequence, selection, and iteration of modules--- Structure Chart Syntax­Mo­dul­es­Control module Higher­-level module that contains logic for calling and contro­lling sub-co­mponent module­sS­ubo­rdinate module Low-level module contains logic for performing
specific function when called by the control module­Li­brary module Generic module used by multiple control module. Loops Iteration – execution of subord­inate modules repeated Condit­ional line  Selection – subord­inate execution based on condit­ion.Co­uples
Shows inform­ation passed between modules Data couples Passing data
Control couples Passing parame­ters, flags, system messag­es-­--B­uilding a structure chart --Types of proces­ses­Af­ferent Provide inputs into the system­Ce­ntral Perform critical functions in the system operat­ion­Ef­ferent Produce outputs of the system­---­Module structures 1.Tran­saction structure Control module calls subord­inate modules based upon a condition or selection that handle specific transa­ctions Correspond to higher levels of DFD and structure chart 2.Tran­sform Structure Control module calls several subord­inate modules in sequence to create a specific output Forms a process to transform inputs into an output  Correspond to lower levels of DFD and structure char--­Program design guidelines 1.High Cohesion-- Modules should perform a single function effici­ently  Modules easy to understand and develop 2.Loose coupling
 Modules are indepe­ndent from one another  Data passed between modules is limited  Modules easy to modify without impacting others 3.High fan-in
 Multiple control modules should call a single subord­inate module Sign of proper module reuse 4.Low fan-out Single control module has few subord­inate modules Maximum of seven subord­inate modules per control Control modules are not overly complex. Program specif­ication -- Explicit instru­ctions for develo­pment team on how code modules should be writte­nD­evelop program specif­ication for each module in structure chart.­Pr­ogram inform­ation Events that trigger functi­onality in the program Inputs and outputs Struc­tured English and pseudocode

System acquis­ition strate­gie­sA­ppr­oaches to system acquis­ition Influ­ences on acquis­ition strategy Selecting an acquis­ition strate­gy-­--A­rch­ite­cture design
Elements of an archit­ecture design Creating an archit­ecture design­--A­ppr­oaches to System Acquis­ition Three ways to approach creation of a system­Custom develo­pment Packaged software Outso­urc­ing­--S­ystems Acquis­ition and Archit­ect­ure­System acquis­ition strate­gie­sA­ppr­oaches to system acquis­ition Influ­ences on acquis­ition strate­gy­Sel­ecting an acquis­ition strate­gy­Arc­hit­ecture design­El­ements of an archit­ecture design Creating an archit­ecture design­---­App­roaches to System Acquis­iti­on­Three ways to approach creation of a system­1.C­ustom develo­pment 2.Packaged software: 3.Outs­our­cin­g--­-In­flu­ences on Acquis­ition Strategy 1.Business need2.Time frame3.In­house experi­enc­e--­-Se­lecting an Acquis­ition Strategy
Alter­native matrix­Ev­aluate pros and cons of design altern­atives Weight criteria according to importance Avoid subjective bias toward prefer­ences
 Indepe­ndent ratings by each analys­t--­Arc­hit­ecture Design­In­for­mation systems are distri­but­ed­Arc­hit­ecture design determines how system
will be distri­buted across comput­ers­No­n-f­unc­tional requir­ements play key role--­-Vi­rtu­ali­zat­ion­Server virtua­liz­ati­on­Par­tit­ioning physical server into several
indepe­ndent virtual server­sR­educed hardware requir­eme­nts­St­orage virtua­liz­ati­on­Com­bining multiple storage devices into single
virtual storage space­Imp­roved storage and retrieval speed-­-Cr­eating an Archit­ecture Design­No­n-f­unc­tional requir­ements used to guide
archit­ecture design decisi­ons­Op­era­tional requir­ements Perfo­rmance requir­ements Security requir­ements Cultural and political requir­ements

Implem­ent­ati­on­Con­str­uction of the new system­Th­orough job in analysis and design phases lead to a successful implem­ent­ation of the system
Devel­oping the system’s softwa­re­Largest component of SDLC in time and cost Generally presents the fewest proble­ms­Design and execution of system testing Develop system docume­nta­tio­n--­-Ma­naging the Progra­mming Process
Coord­inating progra­mming activi­tie­sR­egular meetings Progr­amming standards and guidelines Software develo­pment areas Develo­pment, testing, and produc­tio­nCode management systems Version control  Program log  Program check-in / check-­out­---­Tes­tin­gW­riting programs is fun Testing and docume­ntation are not Profe­ssional organi­zations spend more time
and money in testing than writing progra­msRisk associated with system failure is severe­Te­sting is insurance; expend­iture justif­ied­Te­sting often performed by systems analyst Four types of tests Unit, integr­ation, system, and acceptance tests  Most errors found in integr­ation and system testin­g--­-De­vel­oping Docume­nta­tio­nS­ystem docume­nta­tio­nC­reated in analysis and design phases
Enable mainte­nance of system after instal­lat­ion­User docume­ntation
User manuals, training manuals, help systems Designed to assist users of the system Good docume­ntation takes time Allocate resources to docume­ntation in project plan--­-Or­gan­iza­tional Transi­tio­nP­eople are generally resistant to change­Bu­siness processes and computer systems become habitual, people become comfor­tab­le­Imp­lem­ent­ation of a new system challe­nging Managing organi­zat­ional change Unfreeze, transi­tion, refreeze Prior SDLC phases help users prepare for change Migration plan guides the transition Post-­imp­lem­ent­ation establ­ishes new system-- Migration plan
Decis­ions, plans, procedures guiding transition Conve­rsion strategy Business contin­gency plan--­Co­nve­rsion strate­gy­Con­version style Defines how abruptly the new system is introd­uce­dC­onv­ersion locations Defines what portion of the organi­zation transi­tio­ns­Con­version style­Direct conversion
 Instant replac­ement of the old system with the new  High risk  Any problems have dramatic impact on organi­zat­ion­---­Bus­iness contin­gency planning
Withstand impact of problems with new system­Proper project management and migration planning helps to ensure smooth transi­tio­nP­arallel conversion provides a fallback Plan for worst-case scenario – no system­--P­ost­-Im­ple­men­tation Activi­tie­sI­nst­itu­tio­nalize use of new system­Es­tablish as normal way of doing business Refreeze organi­zation after successful transition Three key post-i­mpl­eme­ntation activi­ties System support  Mainte­nance  Project assess­men­tS­ystem suppor­tP­rov­iding assistance to users after
implem­ent­ati­on­System transf­erred to operations group Provide online support, guides, FAQs Help desk Level 1 and 2 support staff-­--S­ystem mainte­nan­ce­Ref­ining system after implem­ent­ation to ensure
it continues to meet business needs­Sub­sta­ntially more resources devoted to system mainte­nance than initial develo­pme­nt­Change request Changes performed through smaller SDLC cycle  Bug fixes – highest priority Enhan­cements – second priori­ty­Project assess­men­tO­rga­niz­ational learning Understand successes and failures in system develo­pment activi­tie­sP­roject team review Focuses on way project team performed activi­tie­sS­ystem review Focuses on extent system provided benefits promised