Business and Enterprise Skills Understanding Systems Analysis

System development
After completing this module you will be able to:
Describe the term systems development and systems development life cycle (SDLC) List the different meaning of SDLC. Describe the key points of IS !"###!$ and Capability Maturity Model

------------------------------------------------------------------------------

Organi ations e!ist in a dynamic environment" and thus" they regularly e!perience changes in their:
Legal re%&irements' s&ch as government reporting. Level and kinds of competition. (echnologies' s&ch as data entry devices' bar codes' and radio fre%&ency identification (#$%D) tags &sed to record and process information. Lines of b&siness or kinds of b&siness activities. )anagement desire for better access to information and improved management reporting. Systems development comprises the steps &ndertaken to create' modify' or maintain an organi*ation+s %nformation System. (hese steps' along ,ith the pro-ect management concepts disc&ssed belo,' g&ide the in!ho&se development of %nformation Systems' as ,ell as the ac%&isition of systems sol&tions. . term often &sed synonymo&sly ,ith systems development is systems development life cycle or SDLC& (he term systems development life cycle (SDLC) is &sed in several ,ays.

%t can mean: '& . formal set of activities' or a process' &sed to develop and implement a ne,
or modified %nformation System&

(& (he doc&mentation that specifies the systems development process referred
to as the systems development standards man&al.

)& (he progression of %nformation Systems thro&gh the systems

development process' from birth thro&gh implementation to on!going &se. (he life cycle idea comes from this last vie, and is the definition that ,e &se in this te/t. Systems development is also an important ! sometimes dominant ! component of more comprehensive organi*ational change via b&siness process reengineering. (hese terms as ,ell as systems life cycle and systems analysis and design are also &sed to refer to the systems development process.

*e propose the following systems development ob+ectives:

(o develop information systems that satisfies an organi*ation+s informational' operational' and management re%&irements. Note that this objective relates to the system being developed. (o develop information systems in an efficient and effective manner. Note that this objective relates more to the development process than to its outcome. . systems development methodology is a formali*ed' standardi*ed' doc&mented set of activities &sed to manage a systems development pro-ect. It sho&ld be &sed ,hen information systems are developed' ac%&ired' or maintained.

-----------------------------------------------------------------------------$igure '&' presents the systems development life cycle&

(he right side of the fig&re depicts the fo&r development phases0 systems analysis, systems design, systems implementation, and

systems operation. (he b&bbles in 1ig&re 2.3 identify the seven development steps &ndertaken to complete the fo&r phases of development. .rro,s flo,ing into each b&bble represent the inp&ts needed to perform that step' ,hereas o&t,ard!flo,ing arro,s represent the prod&ct of a step. (able 3.3 indicates the ,ays managers and other Information Systems &sers can become involved in systems development. (able 3.$ lists the key p&rposes and tasks associated ,ith the seven development steps (b&bbles) sho,n in 1ig&re 3.3. Systems development does not al,ays proceed in the orderly' se%&ential co&rse s&ggested by 1ig&re 3.3. Some s&bset of steps may be repeated over and over &ntil a satisfactory res&lt is achieved. r' ,e may &ndertake certain steps o&t of se%&ence. 1inally' systems development may be o&tso&rced to cons&ltants or vendors' and personnel from ,ithin the organi*ation ,ill be part of the development team to serve as b&siness process e/perts.

------------------------------------------------------------------------------

(able 3.4 s&mmari*es a fe, reasons ,hy organi*ations fail to achieve their systems development ob-ectives. (o overcome these and other problems' organi*ations m&st e/ec&te the systems development process efficiently and effectively.

,he -ey to achieving these ob+ectives is to control the development process&

.pparently' that is not an easy chore' or more organi*ations ,o&ld be s&ccessf&l at it. Information Systems developers enco&nter similar problems. 5iven s&ch problems' they have concl&ded that systems development m&st be caref&lly controlled and managed by follo,ing good pro-ect management principles and the organi*ation+s %&ality ass&rance frame,ork embodied in its systems development life cycle methodology.

.ro+ect Management:
. recent s&rvey of IS a&dit and control professionals fo&nd the follo,ing pro-ect

management items associated ,ith failed pro-ects0 6nderestimation of the time to complete the pro-ect Lack of monitoring by senior management 6nderestimation of necessary reso&rces 6nderestimation of si*e and scope of the pro-ect Inade%&ate pro-ect control mechanism 7hanging systems specifications Inade%&ate planning. (he pro-ect ,ork plan' incl&ding phases' ,ork to be accomplished in each' times' and cost' are often doc&mented &sing a pro-ect management tool s&ch as )icrosoft 8ro-ect. 8ro-ect management ! partic&larly the planning process and establishing the pro-ect sched&le ! &ltimately can determine the s&ccess of the pro-ect.

/uality Assurance:
8ro-ect management frame,orks apply to any pro-ect. (o ens&re that Information Systems ,ill meet the needs of c&stomers' pro-ects involving the creation or modification of Information Systems m&st incl&de elements that specifically address the %&ality of the system being developed. Quality assurance (QA) addresses the prevention and detection of errors' especially defects in soft,are that may occ&r d&ring the system development process. 9y foc&sing on the proced&res employed d&ring the systems development process' QA activities are directed at preventing errors that may occ&r. QA activities are also directed at testing developed systems to eliminate defects ! to ens&re that they meet the &sers+ re%&irements ! before systems are implemented. (,o prominent so&rces of g&idance for QA are IS at 7arnegie )ellon 6niversity. IS "###!$0 IS "###!$ is a set of standards developed by (he International rgani*ation for Standards (IS ) that describe ,hat an organi*ation m&st do to manage their soft,are development processes. (he ass&mption' as ,ith all IS prod&ct. IS defines a %&ality prod&ct as one that conforms to c&stomer re%&irements. concepts of %&ality prod&cts and processes parallel o&r ;otice that the IS standards' is that if the IS "###!$ standards are follo,ed' the development process ,ill prod&ce a %&ality soft,are "###!$ and the Capability Maturity Model (CMM) developed by the Soft,are :ngineering Instit&te (S:I)

t,o systems development ob-ectives. :/hibit 2.4 contains e/amples of the IS "###!$ standards. <evie, those e/amples and identify the elements that are common among pro-ect management' a systems development methodology' and the IS standards.

Capability Maturity Model:

(he 7apability )at&rity )odel= for Soft,are (S>!7))) is a model that helps organi*ations eval&ate the effectiveness of their soft,are development processes and identifies the key practices that are re%&ired to increase the mat&rity of those processes. (he image to the right depicts the five S>!7)) mat&r&ity levels and the key principles and practices for each. ;otice' for e/ample' that pro-ect management is a key indicator that an organi*ation has attained level ?. (he Soft,are :ngineering Instit&te believes that predictability' effectiveness' and control of an organi*ation+s soft,are processes improve as the organi*ation moves &p the five levels. @o,ever' moving from level 3 to level ? may take an organi*ation ? years or more. )oving from level ? to $ may take another ? years. . recent st&dy fo&nd that achievement of a Level $ S>!7)) mat&rity by an organi*ation' along ,ith the implementation of a str&ct&red systems development methodology' contrib&tes to the %&ality and cost!effectiveness of the soft,are development process. In fact' there ,as significant improvement on 33 of 34 meas&res after Level $ ,as attained. Improvements incl&ded comm&nication and team,ork' lo,er maintenance costs' and lo,er levels of system defects.

-----------------------------------------------------------------------------Summary
Systems development comprises the steps &ndertaken to create' modify' or maintain an organi*ation+s Information System. . term often &sed synonymo&sly ,ith systems development is systems

development life cycle or SDL7. (he term systems development life cycle (SDL7) is &sed in several ,ays.

%t can mean: '& . formal set of activities' or a process' &sed to develop and implement a ne,
or modified Information System.

(& (he doc&mentation that specifies the systems development process referred
to as the systems development standards man&al.

)& (he progression of Information Systems thro&gh the systems development

process' from birth thro&gh implementation to on!going &se. Systems development is also an important ! sometimes dominant ! component of more comprehensive organi*ational change via b&siness process reengineering.

*e propose the following systems development ob+ectives:

(o develop information systems that satisfies an organi*ation+s informational' operational' and management re%&irements. Note that this objective relates to the system being developed. (o develop information systems in an efficient and effective manner.

/uality assurance 0/A1 addresses the prevention and detection of errors'

especially defects in soft,are that may occ&r d&ring the system development process. (,o prominent so&rces of g&idance for A. are IS 7arnegie )ellon 6niversity. (he ass&mption' as ,ith all IS prod&ct. IS defines a %&ality prod&ct as one that conforms to c&stomer re%&irements. (he 7apability )at&rity )odel= for Soft,are (S>!7))) is a model that helps organi*ations eval&ate the effectiveness of their soft,are development processes and identifies the key practices that are re%&ired to increase the mat&rity of those processes. standards' is that if the IS "###!$ standards are follo,ed' the development process ,ill prod&ce a %&ality soft,are "###!$ and the 7apability )at&rity )odel (7))) developed by the Soft,are :ngineering Instit&te (S:I) at

------------------------------------------------------------------------------

2usiness process engineering

After completing this module you will be able to:

:/plain the process kno,n as b&siness process engineering. :/plain the activity kno,n as change management.

--------------------------------------------------------------------------------------

9&siness process reengineering is an activity larger in scope than systems development' as it addresses all of the processes in the organi*ation' incl&ding the information systems processes. <apid developments in the capabilities and applications of I(' s&ch as e!b&siness' present organi*ations ,ith increasingly diffic&lt b&siness opport&nitiesB challenges. (hey are being asked ! sometimes being forced in order to ens&re their very s&rvival ! to abandon long!held b&siness beliefs and ass&mptions and to rethink ,hat they are attempting to accomplish and ho, they are trying to accomplish it. 9&siness process reengineering has been likened to presenting an organi*ation+s management ,ith a blank piece of paper and asking them to reinvent the organi*ation from scratch. >hy ,o&ld management ever be motivated to engage in s&ch an &ndertakingC In many cases' they have no alternative. :/periencing the harsh realities of an increasingly competitive environment' they recogni*e that their companies m&st make mega!changes in ho, they operate' or face e/tinction. Business process reengineering (B !) is the f&ndamental rethinking and radical redesign of b&siness processes to achieve dramatic improvements in critical contemporary meas&res of performance' s&ch as cost' %&ality' service' and speed. (he emphasis on fo&r ,ords in this definition foc&ses on those fo&r key components of 98<.

'& "undamental rethinking of b&siness processes re%&ires management to challenge the basic ass&mptions &nder ,hich it operates and to ask s&ch r&dimentary %&estions as >hy do ,e do ,hat ,e doC and >hy do ,e do it the ,ay ,e do itC

>itho&t f&ndamental rethinking' technology often merely a&tomates old ,ays of doing b&siness. (he res&lt is that ,hat ,as a lo&sy ,ay of doing a -ob became simply a speeded! &p' lo&sy ,ay of doing the -ob.

(& !adical redesign relies on a fresh!start' clean!slate approach to e/amining an

organi*ation+s b&siness processes. (his approach foc&ses on ans,ers to the %&estion' If ,e ,ere a brand!ne, b&siness' ho, ,o&ld ,e operate o&r companyC (he goal is to reinvent ,hat is done and ho, it is done rather than to tinker ,ith the present system by making marginal' incremental' s&perficial improvements to ,hat+s already being done. .chieving the goal re%&ires for,ard!looking' creative thinkers ,ho are &nconstrained by ,hat no, e/ists.

)& .chieving dramatic improvements in performance meas&rements is related

to the preceding t,o elements. (he f&ndamental rethinking and radical redesign of b&siness processes are aimed to,ard making %&ant&m leaps in performance' ho,ever meas&red. >e are not talking abo&t improvement in %&ality' speed' and the like that is on the order of 3#D. Improvement of that order of magnit&de often can be accomplished ,ith marginal' incremental changes to e/isting processes. <eengineering' on the other hand' has m&ch loftier ob-ectives.

3& <eengineering foc&ses on end!to!end b&siness processes rather than on the

individ&al activities that comprise the processes.

2.# takes a holistic vie, of a b&siness process as comprising a string of activities

that c&t across traditional departmental or f&nctional lines.

2.# is concerned ,ith the res&lts of the process.

.s an e/ample' let+s look at the discrete activities that may be involved in completing a sale to a c&stomer. (hese activities might incl&de receiving and recording a c&stomer+s order' checking the c&stomer+s credit' verifying inventory availability' accepting the order' picking the goods in the ,areho&se' packing and shipping the goods' and preparing and sending the bill. <eengineering ,o&ld change o&r emphasis by breaking do,n the ,alls among the separate f&nctions and departments that might be performing these activities.

Instead of order taking' picking' shipping' and so forth' ,e ,o&ld e/amine the entire process of order f&lfilment and ,o&ld concentrate on those activities that add val&e for the c&stomer. Instead of assigning responsibility for these activities to m&ltiple individ&als and organi*ational &nits' ,e might assign one individ&al to oversee them all. .nd' -&st as important' ,e might change meas&rement of performance from the n&mber of orders processed by each individ&al to an assessment of c&stomer service indicators s&ch as delivering the right goods' in the proper %&antities' in satisfactory condition' and at the agreed &pon time and price. >hen asked to identify the critical s&ccess factors for reengineering pro-ects' a gro&p of Chief %nformation Officers 0C%Os1 cited strong pro-ect management' a visible and involved e/ec&tive sponsor' and a compelling case for change. rgani*ational resistance to change' inade%&ate e/ec&tive sponsorship and involvement' inade%&ate pro-ect management' and the lack of an effective change management program ,ere described as significant barriers to change by this same gro&p of 7I s.

-----------------------------------------------------------------------------C#ange Management
After completing this module you will be able to:
:/plain the process kno,n as b&siness process engineering :/plain the activity kno,n as change management.

-----------------------------------------------------------------------------9&siness process reengineering is an activity larger in scope than systems development' as it addresses all of the processes in the organi*ation' incl&ding the information systems processes.

<apid developments in the capabilities and applications of I(' s&ch as e!b&siness' present organi*ations ,ith increasingly diffic&lt b&siness opport&nitiesB challenges. (hey are being asked ! sometimes being forced in order to ens&re their very s&rvival ! to abandon long!held b&siness beliefs and ass&mptions and to rethink ,hat they are attempting to accomplish and ho, they are trying to accomplish it. 9&siness process reengineering has been likened to presenting an organi*ation+s management ,ith a blank piece of paper and asking them to reinvent the organi*ation from scratch. >hy ,o&ld management ever be motivated to engage in s&ch an &ndertakingC In many cases' they have no alternative. :/periencing the harsh realities of an increasingly competitive environment' they recogni*e that their companies m&st make mega!changes in ho, they operate' or face e/tinction. Business process reengineering (B !) is the f&ndamental rethinking and radical redesign of b&siness processes to achieve dramatic improvements in critical contemporary meas&res of performance' s&ch as cost' %&ality' service' and speed. (he emphasis on fo&r ,ords in this definition foc&ses on those fo&r key components of 98<.

$. 1&ndamental rethinking of b&siness processes re%&ires management to challenge the

basic ass&mptions &nder ,hich it operates and to ask s&ch r&dimentary %&estions as >hy do ,e do ,hat ,e doC and >hy do ,e do it the ,ay ,e do itC >itho&t f&ndamental rethinking' technology often merely a&tomates old ,ays of doing b&siness. (he res&lt is that ,hat ,as a lo&sy ,ay of doing a -ob became simply a speeded!&p' lo&sy ,ay of doing the -ob.

%. <adical redesign relies on a fresh!start' clean!slate approach to e/amining an

organi*ation+s b&siness processes. (his approach foc&ses on ans,ers to the %&estion' If ,e ,ere a brand!ne, b&siness' ho, ,o&ld ,e operate o&r companyC

(he goal is to reinvent ,hat is done and ho, it is done rather than to tinker ,ith the present system by making marginal' incremental' s&perficial improvements to ,hat+s already being done. .chieving the goal re%&ires for,ard!looking' creative thinkers ,ho are &nconstrained by ,hat no, e/ists.

&. .chieving dramatic improvements in performance meas&rements is related to the

preceding t,o elements. (he f&ndamental rethinking and radical redesign of b&siness processes are aimed to,ard making %&ant&m leaps in performance' ho,ever meas&red. >e are not talking abo&t improvement in %&ality' speed' and the like that is on the order of 3#D. Improvement of that order of magnit&de often can be accomplished ,ith marginal' incremental changes to e/isting processes. <eengineering' on the other hand' has m&ch loftier ob-ectives.

'. <eengineering foc&ses on end!to!end b&siness processes rather than on the individ&al
activities that comprise the processes. B ! takes a holistic vie, of a b&siness process as comprising a string of activities that c&t across traditional departmental or f&nctional lines. B ! is concerned ,ith the res&lts of the process. .s an e/ample' let+s look at the discrete activities that may be involved in completing a sale to a c&stomer. (hese activities might incl&de receiving and recording a c&stomer+s order' checking the c&stomer+s credit' verifying inventory availability' accepting the order' picking the goods in the ,areho&se' packing and shipping the goods' and preparing and sending the bill. <eengineering ,o&ld change o&r emphasis by breaking do,n the ,alls among the separate f&nctions and departments that might be performing these activities. Instead of order taking' picking' shipping' and so forth' ,e ,o&ld e/amine the entire process of order f&lfilment and ,o&ld concentrate on those activities that add val&e for the c&stomer.

Instead of assigning responsibility for these activities to m&ltiple individ&als and organi*ational &nits' ,e might assign one individ&al to oversee them all. .nd' -&st as important' ,e might change meas&rement of performance from the n&mber of orders processed by each individ&al to an assessment of c&stomer service indicators s&ch as delivering the right goods' in the proper %&antities' in satisfactory condition' and at the agreed &pon time and price. >hen asked to identify the critical s&ccess factors for reengineering pro-ects' a gro&p of C#ie( )n(ormation *((icers (C)*s) cited strong pro-ect management' a visible and involved e/ec&tive sponsor' and a compelling case for change. rgani*ational resistance to change' inade%&ate e/ec&tive sponsorship and involvement' inade%&ate pro-ect management' and the lack of an effective change management program ,ere described as significant barriers to change by this same gro&p of 7I s.

------------------------------------------------------------------------------

8eople+s concerns regarding I( and b&siness process changes center on act&al and perceived changes in ,ork proced&res and relationships' corporate c&lt&re' and organi*ational hierarchy that these changes bring. (o address these fears' systems professionals and &sers m&st collaborate on the design and implementation of the ne, system. (his collaboration m&st incl&de the system itself and the process that ,ill be follo,ed d&ring its development and installation. (he change m&st be managed' b&t not directed. <ather' &sers m&st participate in the development and change processes. <esearch and practice provide g&idance to help &s achieve s&ccessf&l change.

. recent research st&dy fo&nd that &sers ,ho effectively participated in a systems change process ,ere able to affect o&tcomes' and had a more positive attit&de and a higher involvement ,ith the ne, system.

.nd' the system ,as more s&ccessf&l. In practice' ,e find that s&ccessf&l' large I( change pro-ects ! especially those involving enterprise Systems ! m&st be driven by the b&siness processes and managed by the b&siness process o,ners. In these cases' I( assists ,ith' b&t does not drive' the change process. (echnological change is not ,elcomed if it comes as a s&rprise. 6sers at all levels m&st be bro&ght into the process early in the S+,C to enco&rage s&ggestions and disc&ssion abo&t the change. 6sers involved from the start and given a say in redesigning their -obs tend to identify ,ith the system. .s problems arise' their attit&de is more likely to be' >e have a problem' rather than' (he system makes too many mistakes. In engineering a systems change' it is cr&cial to consider the h&man element. <esistance sho&ld be anticipated and its &nderlying ca&ses addressed. 6ser commitment can be enlisted by enco&raging participation d&ring development and by &sing achievement of b&siness ob-ectives' rather than I( change' to drive the process. 8otential &sers m&st be sold on the benefits of a system and made to believe that they are capable of ,orking ,ith that system. . policy of coercion ,ill lead to s&bstandard performance.

------------------------------------------------------------------------------

9&siness process reengineering (B !) is the f&ndamental rethinking and radical redesign of b&siness processes to achieve dramatic improvements in critical contemporary meas&res of performance' s&ch as cost' %&ality' service' and speed. (here is emphasis on fo&r ,ords in the definition foc&sing on fo&r key components of 98<. 1&ndamental <adical Dramatic 8rocess 9&siness process reengineering is an activity larger in scope than systems development' as it addresses all of the processes in the organi*ation' incl&ding the information systems processes. 9&siness process reengineering has been likened to presenting an organi*ation+s management ,ith a blank piece of paper and asking them to reinvent the organi*ation from scratch. 8eople+s concerns regarding I( and b&siness process changes center on act&al and perceived changes in ,ork proced&res and relationships' corporate c&lt&re' and organi*ational hierarchy that these changes bring. (he change m&st be managed' b&t not directed. <ather' &sers m&st participate in the development and change processes.

-----------------------------------------------------------------------------Systems Survey

After completing this module you will be able to:

Describe a system s&rvey and o&tline its goals. List and e/plain the three aspects of feasibility. :/plain the need for obtaining approvals.

------------------------------------------------------------------------------

(he systems s&rvey is cond&cted to investigate Information Systems problems and to decide on a co&rse of action. ne co&rse of action ,ill be to proceed ,ith development. @o,ever' initial investigation may find that there is no problem and broader analysis is not ,arranted. >e m&st be caref&l in reaching concl&sions' beca&se problems may be ill defined and not appropriately identified by &sers. . systems s&rvey is initiated ,hen the organi*ation+s I( strategic plan prescribes the development or ,hen a &ser re%&ests the development or modification of a ne, system. In planned revie,s' systems analysts may not be a,are of any partic&lar problems. In s&ch cases' they cond&ct the systems s&rvey to see ,hether information processing problems e/ist or if they can improve an Information System.

.lanned systems development determines whether:

. system still satisfies &sers+ information needs. ;e, design ideas can be incorporated. :volving environmental changes' s&ch as competition' re%&ire system changes. ;e, types of b&siness by a firm re%&ire system changes. (he &ser re%&ests systems development ,hen a system no longer efficiently and effectively meets their goals.

4ser-re5uested systems development may occur when:

5overnment reg&lations re%&ire ne, or modified reports. 7&rrent reports do not meet decision!making needs. :rroneo&s system o&tp&ts occ&r. :scalating c&stomer or vendor complaints are received. (he information system ca&ses delays that slo, a b&siness process. ;otice that many of those reasons are rooted in a desire to leverage ne, technology for competitive advantage. (he organi*ation sho&ld have a formal process for selecting pro-ects to ens&re that they are consistent ,ith the organi*ational goals and strategies identified in the strategic plan for I(.

.otential pro+ects should be prioriti ed and approved by the %, steering committee to ensure that:
:fficient and effective &se is made of e/isting I( reso&rces. I( reso&rces are directed at achieving organi*ational ob-ectives. Information services are &sed consistently thro&gho&t the organi*ation.

------------------------------------------------------------------------------

(he systems s&rvey' often called a feasibility st&dy or preliminary feasibility st&dy' is a set of proced&res cond&cted to determine the feasibility of a potential systems development pro-ect and to prepare a systems development plan for pro-ects considered feasible. :ach step in the S+,C has goals that s&pport the systems development ob-ectives. .n organi*ation cond&cts a systems s&rvey to determine ,hether it is ,orth,hile to proceed ,ith s&bse%&ent development steps.

,he systems survey goals are as follows:

Identify the nat&re and the e/tent of systems development by determining for

each reported problem the problem+s e/istence and nat&re. Determine the scope of the problem. 8ropose a co&rse of action that might solve the problem. Determine the feasibility of any proposed development. Is there a technically' economically' and operationally feasible sol&tion to the problemC Devise a detailed plan for cond&cting the analysis step. Determine ,ho ,ill cond&ct the analysis' ,ho ,ill head the pro-ect team' ,hat tasks are re%&ired' and ,hat the development timetable is. Devise a s&mmary plan for the entire development pro-ect. (he first task in the systems s&rvey is to gather facts. In the systems s&rvey' the analyst gathers facts to achieve the systems s&rvey goals. (hat is' facts are gathered to determine the nat&re and scope of the reported problem' to perform the feasibility st&dy' and to plan the development pro-ect. (he analyst tries to determine ,hat the system does no, and ,hat ,e ,o&ld like for it to do. (o determine ,hat the system is doing' ,e look at the system+s doc&mentation and e/amine the system+s operation. (o determine ,hat the system sho&ld be doing' ,e obtain information from &sers and a&thoritative so&rces. (he e/tent of fact gathering m&st be consistent ,ith cost and time constraints imposed on the systems s&rvey. (hat is' the systems s&rvey m&st be cond&cted as %&ickly and as ine/pensively as possible' yet still accomplish its goals. If the pro-ect goes beyond the systems s&rvey' additional' more detailed facts ,ill be gathered d&ring str&ct&red systems analysis. Systems developers &se a n&mber of tools to gather facts.

------------------------------------------------------------------------------

@aving completed the task of gathering and doc&menting facts' an analyst kno,s ,hat the ne, system sho&ld do and ,hat the present system or process act&ally does. (he analyst &ndertakes the second systems s&rvey task' the preliminary feasibility st&dy' to

determine ,hether ,e can solve the problem and ,hether ,e can do so at a reasonable cost.

-#ere are t#ree aspects o( (easibility. 6 ,echnical feasibility&

. problem has a technically feasible sol&tion if it can be solved &sing available hard,are and soft,are technology.

6 Operational feasibility&
. problem has an operationally feasible sol&tion if it can be solved given the organi*ation+s available personnel and proced&res. In assessing this aspect of feasibility' the analyst sho&ld consider behavio&ral reactions to the systems change. 8ro-ects that incl&de reengineering of e/isting b&siness processes may face strong resistance beca&se personnel may envision shifts in po,er' changes in day!to!day activities' and layoffs. (iming and sched&ling may also be factors. .n organi*ation may have the available reso&rces b&t cannot or ,ill not commit them to a partic&lar pro-ect at this time. (he organi*ation may ,ish to scale do,n a pro-ect' take an alternative co&rse of action' or break the pro-ect into smaller pro-ects to better fit sched&ling needs.

6 7conomic feasibility&
Determining economic feasibility can be a bit more comple/.

A problem has an economically feasible solution if:

7osts for this pro-ect seem reasonable. 1or e/ample' the benefits e/ceed the costs. (his pro-ect compares favo&rably to competing &ses for the organi*ation+s reso&rces. Determining the costs and benefits for information systems is diffic&lt at best. .nd' estimating pro-ect costs and benefits this early in the SDL7 might seem premat&re. .fter all' ,e have done very little ,ork on the development and kno, very little abo&t the ne, system. 9&t' management m&st decide no, ,hether to proceed. (herefore' management m&st kno, the estimated costs and benefits of the development' no matter ho, ro&ghly estimated.

-----------------------------------------------------------------------------.s described earlier in the chapter' pro-ect management is an important mechanism for controlling a systems development pro-ect. 7ontrol of a pro-ect becomes more important as the risks of fail&re increase. (hese risks' many of ,hich are discovered d&ring the feasibility st&dy' incl&de0

6 .ro+ect si e ! both absol&te and compared to other I( pro-ects ! as meas&red

by staffing' costs' time' and n&mber of organi*ational &nits affected. 8ro-ects that involve reengineering andBor the installation of an enterprise system are normally larger than those that do not.

6 Degree of definition&
8ro-ects that are ,ell defined in terms of their o&tp&ts and the steps necessary to obtain those o&tp&ts are less risky than those that re%&ire &ser and developer -&dgment.

6 7!perience with technology&

<isk increases as the organi*ation+s e/perience ,ith the relevant technology decreases.

6 Organi ational readiness&

(his aspect of operational feasibility addresses the organi*ation+s e/perience ,ith management of similar pro-ects' as ,ell as management and &ser preparation for and commitment to this pro-ect. .ltho&gh pro-ect management cannot address all of these risks' it is an important element in minimi*ing their impact. If the preliminary feasibility eval&ation indicates that f&rther analysis of the problem is ,arranted' the analyst devises a pro-ect plan. . pro-ect plan is a statement of a pro-ect+s scope' timetable' reso&rces re%&ired to complete the pro-ect' and the pro-ect+s costs. (he systems s&rvey+s planning aspect is so important that the systems s&rvey is often called systems planning. (he pro-ect plan incl&des a broad plan for the entire development' as ,ell as a specific plan for str&ct&red systems analysis ! the ne/t development step.

*e develop a pro+ect plan:

/ -o pro0ide a means to sc#edule t#e use o( re1uired resources. >hat personnel and f&nds ,ill be re%&ired and ,henC / -o indicate ma2or pro2ect milestones to monitor t#e pro2ect3s progress. Is the pro-ect on sched&leC @as the pro-ect provided the re%&ired deliverablesC / -o (orecast t#e pro2ect budget, 4#ic# is used to aut#ori5e pro2ect

continuation6 5iven the pro-ect+s progress to date' sho&ld additional f&nds be e/pended for this stepC 1or the ne/t stepC / -o (urnis# guidelines (or making a go or no7go decision. .re the costs and benefits as pro-ectedC Is the &tili*ation of these reso&rces in the best interest of the organi*ation at this timeC / -o o((er a (rame4ork by 4#ic# management can determine t#e reasonableness and completeness o( t#e pro2ect3s steps. Is there a complete list of tasks' and are these tasks properly matched ,ith the re%&ired skillsC .re the proper information so&rces being investigatedC >e &se a combination of diagrams' sched&les' and other pro-ect management tools to develop and doc&ment the pro-ect plan.

------------------------------------------------------------------------------

.rior to completing the systems survey" the analyst must obtain approvals&
.s mentioned earlier' signoffs signify approval of both the development process and the system being developed. btaining systems s&rvey approvals ens&res that the feasibility doc&ment+s contents are complete' reasonable' and satisfactory to the ma-or development participants. btaining agreement on the doc&ment+s contents is a key element in the development process beca&se s&ch agreement paves the ,ay for cooperation as the pro-ect progresses. (hese approvals fall into t,o categories0 approvals from &sersBparticipants and management control point approvals. 6serBparticipant approvals verify the acc&racy of any intervie,s or observations

and the acc&racy' completeness' and reasonableness of the s&rvey doc&mentation and concl&sions. S&ch approvals red&ce resistance to the pro-ect and pave the ,ay for accepting the effectiveness of the ne, system. (he second type of signoff' called a management control point' occ&rs at a place in the systems development process re%&iring management approval of f&rther development ,ork. 6pper management control points occ&r at the end of each development phase I( management control points occ&r ,ithin phase+s pro-ect management control points occ&r at the completion of individ&al ,ork &nits. (hese ens&re management commitment to the pro-ect and the reso&rces re%&ired to bring the pro-ect to clos&re.

------------------------------------------------------------------------------

Summary
. systems s&rvey is initiated ,hen the organi*ation+s I( strategic plan prescribes the development or ,hen a &ser re%&ests the development or modification of a ne, system. (he systems s&rvey goals are as follo,s0 Identify the nat&re and the e/tent of systems development by determining for each reported problem the problem+s e/istence and nat&re. Determine the scope of the problem. 8ropose a co&rse of action that might solve the problem. Determine the feasibility of any proposed development. Is there a technically' economically' and operationally feasible sol&tion to the problemC Devise a detailed plan for cond&cting the analysis step. Determine ,ho ,ill cond&ct the analysis' ,ho ,ill head the pro-ect team' ,hat tasks are re%&ired' and ,hat the development timetable is. Devise a s&mmary plan for the entire development pro-ect.

(here are three aspects of feasibility0 (echnical feasibility. perational feasibility.

:conomic feasibility. (hese risks' many of ,hich are discovered d&ring the feasibility st&dy' incl&de0 8ro-ect si*e. Degree of definition. :/perience ,ith technology. rgani*ational readiness.

btaining agreement on the doc&ment+s contents is a key element in the development process beca&se s&ch agreement paves the ,ay for cooperation as the pro-ect progresses.

------------------------------------------------------------------------------

After completing this module you will be able to:

Describe the proced&re kno,n as Systems .nalysis. Describe ho, systems analysis can become str&ct&red. List the goals of System .nalysis. ;ame the st&dies to be carried o&t in Systems .nalysis.

------------------------------------------------------------------------------

Systems analysis is the methodical investigation of a problem and the identification and ranking of alternative sol&tions to the problem. Systems analysis is often called str&ct&red systems analysis ,hen certain

str&ct&red tools and techni%&es' s&ch as +"+s' are &sed in cond&cting the analysis. (o simplify o&r disc&ssions' ,e ,ill refer to str&ct&red systems analysis as simply systems analysis. .s a res&lt of decisions made in the systems s&rvey' ,e kno, if and ho, to proceed ,ith systems development. If ,e have decided to proceed' ,e perform the second step in systems development' str&ct&red systems analysis. >e m&st perform the proced&res in this step ,ell to have any chance of achieving the first of o&r systems development ob-ectivesEto develop systems that meet &ser needsEbeca&se it is d&ring systems analysis that ,e determine those needs. >itho&t a ,ell!&nderstood and doc&mented target (i.e.' &ser re%&irements) ,e cannot hope to have a s&ccessf&l development process. )anagement bases the decision abo&t ,hether and ho, to proceed on information gathered in the systems s&rvey and on other information. )anagement might decide to red&ce the s&ggested analysis scope in order to red&ce short!term development costs. r management might cancel' postpone' or modify f&t&re systems ,ork beca&se a ma-or modification is preferred to the maintenance approach being s&ggested. In the case of reengineering and enterprise systems' management faces some challenging decisions. 1or e/ample' an organi*ation might decide early in the development process that the installation of an enterprise system ,o&ld solve its Information Systems problems. (o ens&re a s&ccessf&l installation of an enterprise system' organi*ations m&st reengineer their b&siness processes to make them compatible ,ith the enterprise system. )anagement m&st decide ho, m&ch analysis to &ndertake before and after p&rchasing the system and ho, m&ch to change their b&siness practices (he development options in 1ig&re 2.? s&mmari*e the typical choices from ,hich organi*ations may choose. In the systems s&rvey ,e begin the get some sense of these alternatives and ,hich one looks best at the time. In the analysis step of systems development' ,e m&st e/amine each alternative and gather eno&gh information to make a choice to proceed ,ith development along one of the alternative paths.

Str&ct&red systems analysis is a set of proced&res cond&cted to generate the specifications for a ne, (or modified) Information System or s&bsystem. (he systems s&rvey assists management in determining the e/istence of a problem and in choosing a co&rse of action. Systems analysis provides more information than ,as gathered in the systems s&rvey. (he additional information describes and e/plains the problem f&lly. Sol&tions are developed and eval&ated so that management can decide ,hether to proceed ,ith development and' if so' ,hich potential sol&tion sho&ld be developed. (o &nderstand systems analysis' ,e+ll ret&rn to the analogy presented earlier in the chapter' in ,hich ,e compared systems development to b&ilding an ind&strial park.

Systems analysis goals are as follows: Define the problem precisely&

In systems analysis' ,e ,ant to kno, and &nderstand the problem in eno&gh detail to solve it.

Devise alternative designs 0solutions1&

(here is al,ays more than one ,ay to solve a problem or to design a system' and ,e ,ant to develop several sol&tions from ,hich to choose.

Choose and +ustify one of these alternative design solutions&

ne sol&tion m&st be chosen' and the choice sho&ld be -&stified &sing costBeffectiveness analysis or some other criterion' s&ch as political or legal considerations (e.g.' government reporting re%&irements).

Develop logical specifications for the selected design&

(hese detailed specifications are &sed to design the ne, system.

Develop the physical re5uirements for the selected design&

1or e/ample' ,e ,ant to define s&ch re%&irements as data storage' f&nctional layo&ts for comp&ter in%&iry screens and reports' and processing response times' ,hich lead to e%&ipment re%&irements.

Develop the budget for the ne!t two systems development phases 0systems design and systems implementation1&
(hese b&dgets are critical in determining development costs and controlling later

development activities. (he logical specifications and physical re%&irements become the criteria by ,hich the &ser ,ill accept the ne, or modified system. (he better ,e perform systems analysis' the more likely that the system ,ill meet &ser re%&irements and be accepted' implemented' and &sed effectively.

,here are two issues here&

1irst' as ,e see in 1ig&re 2.$' the opport&nity for errors is m&ch higher in earlier phases of systems development. . typical early error is fail&re to define &ser re%&irements completely. Second' as ,e see in 1ig&re 2.4' the later in the development process that an error or oversight is discovered' the more costly it is to fi/. 1or e/ample' if ,e fail to determine d&ring analysis that the &ser needs a certain piece of data on an o&tp&t screen' this data may not be easy to add to the database d&ring the implementation phase. It is especially imperative to perform a top!%&ality analysis ,hen ,e are introd&cing an enterprise system. It is d&ring the analysis step that ,e model the b&siness processes and determine the process changes that ,ill be re%&ired. 9&siness process o,ners and system &sers m&st &nderstand and accept these changes for s&ccessf&l implementation. ther,ise there may be strong resistance to the implementation that co&ld lead to the fail&re of the ne, system. .s mentioned earlier' b&siness processes m&st be reengineered to fit the enterprise system+s processes. Determination of &ser re%&irements in the analysis step can be more diffic&lt in an e!b&siness implementation. In s&ch an implementation ,e m&st determine &ser re%&irements inside and o&tside the organi*ation. >e m&st consider the f&nctional needs of c&stomers and b&siness partners' as ,ell any re%&irements for infrastr&ct&re to connect o&r internal systems to the o&tside &sers

--------------------------------------------------------------------------

-----

(he first step the analysis team performs on the road to defining the logical specification is to st&dy and doc&ment the c&rrent physical system. (he team ,ants to b&ild on the information available in the approved feasibility doc&ment and &nderstand completely the c&rrent system operations. (he team ans,ers s&ch %&estions as these. 5iven the system+s goals' ,hat sho&ld the system be doingC Sho&ld the order entry system be s&pporting c&stomer in%&iriesC >hat are the reasons the system is operating as it isC >hy are there errorsC .fter the c&rrent system has been doc&mented ,ith a physical data flo, diagram' the team derives the c&rrent logical e%&ivalent ,hile removing all the physical elements from the diagram to prod&ce a c&rrent logical data flo, diagram' a description of the c&rrent logical system. >orking ,ith the c&rrent logical system' the analysis team models the f&t&re logical system. Like the c&rrent logical +"+' the f&t&re logical +"+ describes a system+s logical feat&res. @o,ever' &nlike the c&rrent diagrams' the f&t&re diagram describes ,hat a system ,ill do rather than ,hat it presently does. (o model ,hat the ne, system ,ill do' the team adds ne, activities' remodels e/isting activities' and adds or changes control activities. >e are no, at the point to describe ho, the ne, system ,ill operate. >orking ,ith the f&t&re logical system' an analysis team co&ld devise several physical alternatives.

$. (he first step in developing a f&t&re physical system is to decide ,hich

processes ,ill be man&al and ,hich ,ill be a&tomated.

%. .s a second step in developing an alternative physical design' the analyst

m&st decide ,hich processes ,ill begin immediately &pon occ&rrence of an event and ,hich ,ill only operate periodically.

------------------------------------------------------------------------------

(he analysis team' ,orking ,ith the ne, system+s &sers' m&st no, recommend the implementation of one of the alternative physical systems. (he &ltimate selection involves t,o decisions. "irst' the analysis team m&st decide ,hich alternative system to recommend to the &sers and management. Second' given the analysis team+s recommendation' the firm+s management' &s&ally the I( steering committee' m&st decide ,hether to &ndertake f&rther development. .nd' if f&rther development is chosen' management m&st decide ,hich alternative system sho&ld be developed. (his t,o!part decision process is often an iterative process. (he analysis team may recommend one alternative' and the &sers may disagree' th&s re%&iring that the team re,ork its proposed system. .fter agreeing on the proposed system' the &serBanalyst team+s proposal is for,arded for approval by the I( steering committee. (his committee m&st decide ,hether the development effort -&stifies e/pendit&re of the firm+s cash. (o red&ce costs' for e/ample' the I( steering committee may ask for revisions to the system' th&s re%&iring yet another re,orking of the proposed system. (o facilitate selecting a f&t&re physical system' the systems analysis team cond&cts a costBeffectiveness st&dy' ,hich provides %&antitative and certain %&alitative information concerning each of the alternatives. (his information is &sed to decide ,hich alternative best meets &sers+ needs. In making this determination' the team asks t,o %&estions. "irst' >hich alternative accomplishes the &sers+ goals for the least costC (his %&estion is addressed by the costBbenefit st&dy. Second' >hich alternative best accomplishes the &sers+ goals for the system being developedC (his is the effectiveness st&dy.

------------------------------------------------------------------------------

(o complete the systems analysis' the pro-ect team m&st collect the prod&cts of the analysis and organi*e these prod&cts into the doc&mentation re%&ired for s&bse%&ent development steps. Let+s talk abo&t ho, each piece is packaged.

,he first analysis deliverable is the logical specification&

(his is &sed in systems selection to choose the appropriate soft,are to be ac%&ired from e/ternal so&rces. r' if the soft,are is developed in!ho&se' it is &sed in str&ct&red systems design to design the soft,are.

,he second analysis deliverable is the physical re5uirements specification&

(hese re%&irements are &sed in systems selection to ac%&ire comp&ter e%&ipment for the ne, system. (able 2.$ s&mmari*es typical physical re%&irements. In addition to the physical re%&irements related to hard,are' the physical re%&irements sho&ld incl&de f&nctional layo&ts of in%&iry screens and reports. .t this point' sample reports and screens are called f&nctional layo&ts beca&se they sho, the information elements that are needed ,itho&t getting into all the details of the screen or report design. .nother deliverable' implicit at the concl&sion of each systems development step' is the b&dget and sched&le doc&ment.

$. (he b&dget' estimated d&ring the costBbenefit analysis' specifies the

e/pected costs to complete the systems development.

%. Sched&les control systems development efforts by setting limits on the time

to be spent on development activities and by coordinating those activities. (he final step in completing and packaging the systems analysis doc&mentation is to obtain approvals. .s disc&ssed earlier' signoffs may be obtained from &sers' information services' management' and internal a&dit. In addition' the controller may sign off to indicate that the costBbenefit analysis is reasonable.

--------------------------------------------------------------------------

-----

Summary
Systems analysis is the methodical investigation of a problem and the identification and ranking of alternative sol&tions to the problem. Systems analysis is often called str&ct&red systems analysis ,hen certain str&ct&red tools and techni%&es' s&ch as +"+s' are &sed in cond&cting the analysis. Str&ct&red systems analysis is a set of proced&res cond&cted to generate the specifications for a ne, (or modified) Information System or s&bsystem.

Systems analysis goals are as follows:

Define the problem precisely. Devise alternative designs (sol&tions). 7hoose and -&stify one of these alternative design sol&tions. Develop logical specifications for the selected design. Develop the physical re%&irements for the selected design. Develop the b&dget for the ne/t t,o systems development phases (systems design and systems implementation). >orking ,ith the f&t&re logical system' an analysis team co&ld devise several physical alternatives.

$. (he first step in developing a f&t&re physical system is to decide ,hich

processes ,ill be man&al and ,hich ,ill be a&tomated.

%. .s a second step in developing an alternative physical design' the analyst

m&st decide ,hich processes ,ill begin immediately &pon occ&rrence of an event and ,hich ,ill only operate periodically. (o facilitate selecting a f&t&re physical system' the systems analysis team cond&cts a costBeffectiveness st&dy' ,hich provides %&antitative and certain %&alitative information concerning each of the alternatives. In making this determination' the team asks t,o %&estions. "irst' >hich alternative accomplishes the &sers+ goals for the least costC (his %&estion is addressed by the costBbenefit st&dy. Second' >hich alternative best accomplishes the &sers+ goals for the system being

developedC (his is the effectiveness st&dy.

------------------------------------------------------------------------------