Module 2 Point 4

8/17/2019 Module 2 Point 4

1/18

POINT 4

1. What is structured approach to software development?

The structured approach to software development is characterized b distinctsta!es" each sta!e is completed before the ne#t is commenced" this is necessar asteams of developers with var in! s$ills and responsibilities.

%. The sta!es in Pro!ram &evelopment ' (tructured )pproachi. defning and understanding the problem ii. planning and designing iii. implementingiv. testing and evaluating v. maintaining

DEFINING THE PRO !E"

&e*nin! the problem is the most important part of the software development c cle.If the re+uirements and the parameters of the problem are clearl understood" thenthe actual output of the development pro!ram ,process- is far more li$el to meetthe e#pected output. The *rst step in de*nin! a problem is to full understand theproblem which needs to be solved.

This includes

i. statin! the problem in other terms which !ive !reater meanin! to theproblem.

ii. e#plainin! the essential +ualities or aspects of the problemiii. decidin! the boundaries of the problem

P!#NNING #ND DE$IGNING

)t this sta!e the structures that will hold the data to be used durin! processin! aredesi!ned. The nature of processin! that will occur should be considered at this time.Well/desi!ned structures can !reatl reduce the processin! re+uired.

This includes plannin! the 0easibilit (tud

Feasibilit% $tud%

) feasibilit stud is carried out to select the best s stem that meets performancere+uirements.

The main aim of the feasibilit stud activit is to determine whether it would be*nanciall and technicall feasible to develop the product. The feasibilit studactivit involves the anal sis of the problem and collection of all relevantinformation relatin! to the product such as the di erent data items which would beinput to the s stem" the processin! re+uired to be carried out on these data" theoutput data re+uired to be produced b the s stem as well as various constraints onthe behaviour of the s stem.

& udgetar%


2/18

2conomic anal sis is the most fre+uentl used techni+ue for evaluatin! thee ectiveness of a proposed s stem. 3ore commonl $nown as ost ' 5ene*tanal sis" the procedure is to determine the bene*ts and savin!s that are e#pectedfrom a proposed s stem and compare them with costs. If bene*ts outwei!h costs" adecision is ta$en to desi!n and implement the s stem. Otherwise" further

6usti*cation or alternative in the proposed s stem will have to be made if it is tohave a chance of bein! approved. This is an out!oin! e ort that improves inaccurac at each phase of the s stem life c cle.

O& Operational

This is mainl related to human or!anizational and political aspects. The points tobe considered are

7 What chan!es will be brou!ht with the s stem?

7 What or!anizational structure are disturbed?

7 What new s$ills will be re+uired? &o the e#istin! sta members have these s$ills?If not" can the be trained in due course of time?

This feasibilit stud is carried out b a small !roup of people who are familiar withinformation s stem techni+ue and are s$illed in s stem anal sis and desi!n process.

Proposed pro6ects are bene*cial onl if the can be turned into information s stemthat will meet the operatin! re+uirements of the or!anization. This test of feasibilitas$s if the s stem will wor$ when it is developed and installed.

T& Te'hni'al

This is concerned with specif in! e+uipment and software that will successfull

satisf the user re+uirement. The technical needs of the s stem ma varconsiderabl " but mi!ht include

7 The facilit to produce outputs in a !iven time.

7 8esponse time under certain conditions.

7 )bilit to process a certain volume of transaction at a particular speed.

7 0acilit to communicate data to distant locations.

In e#aminin! technical feasibilit " con*!uration of the s stem is !iven moreimportance than the actual ma$e of hardware. The con*!uration should !ive thecomplete picture about the s stem9s re+uirements

:ow man wor$stations are re+uired" how these units are interconnected so thatthe could operate and communicate smoothl .

What speeds of input and output should be achieved at particular +ualit ofprintin!.

$& $'heduling

) pro6ect will fail if it ta$es too lon! to be completed before it is useful. T picall " thismeans estimatin! how lon! the s stem will ta$e to develop" and if it can be


3/18

completed in a !iven time period usin! some methods li$e pa bac$ period.(chedule feasibilit is a measure of how reasonable the pro6ect timetable is. ;ivenour technical e#pertise" are the pro6ect deadlines reasonable? (ome pro6ects areinitiated with speci*c deadlines. It is necessar to determine whether the deadlinesare mandator or desirable.

I"P!E"ENTING

&urin! this sta!e the solution is coded in a pro!rammin! lan!ua!e. Pro!rammersare allocated speci*c modules to code. The are !iven s stem models" the natureand names of relevant data structures to!ether with al!orithms.

TE$TING #ND E(#!)#TING

5efore the solution can be used it must be thorou!hl tested.


4/18

i. The !runts of the pro6ect" pro!rammers wor$ mar$in! the desi!n thehave been !iven realit .

0. )sers as 'lientsi. >sers compile of the people whom the end product is aimed at. The

often test and report bac$ via forums etc.

1. "anagement as 'lientsi. 3ana!ement has to mana!e resources li$e the allocation of e#pertise

etc. The must also $eep all the steps in the approach in chec$.2. Team #pproa'h

i. )23 coordinates technical assistance from state" federal and local!overnment pro!rams" as well as the private sector.

PROGR#" *3*!E OF DE(E!OP"ENT

The waterfall method shows this

(O0TW)82 82 >I8232NT(Re4uirement Gathering

If the feasibilit report is positive towards underta$in! the pro6ect" ne#t phase startswith !atherin! re+uirements from the user. )nal sts and en!ineers communicatewith the client and end/users to $now their ideas on what the software shouldprovide and which features the want the software to include.

$o,t5are Re4uirement $pe'if'ation

(8( is a document created b s stem anal st after the re+uirements are collectedfrom various sta$eholders.


5/18

(8( de*nes how the intended software will interact with hardware" e#ternalinterfaces" speed of operation" response time of s stem" portabilit of softwareacross various platforms" maintainabilit " speed of recover after crashin!" (ecurit "

ualit "


6/18

8e+uirements 2licitation is the process to *nd out the re+uirements for an intendedsoftware s stem b communicatin! with client" end users" s stem users and otherswho have a sta$e in the software s stem development.

There are various 5a%s to dis'over re4uirements

Intervie5s

Interviews are stron! medium to collect re+uirements. Or!anization ma conductseveral t pes of interviews such as

(tructured ,closed- interviews" where ever sin!le information to !ather is decidedin advance" the follow pattern and matter of discussion *rml .

Non/structured ,open- interviews" where information to !ather is not decided in

advance" more =e#ible and less biased.Oral interviews

Written interviews

One/to/one interviews which are held between two persons across the table.

;roup interviews which are held between !roups of participants. The help touncover an missin! re+uirement as numerous people are involved.

$urve%s

Or!anization ma conduct surve s amon! various sta$eholders b +uer in! about

their e#pectation and re+uirements from the upcomin! s stem.

7uestionnaires

) document with pre/de*ned set of ob6ective +uestions and respective options ishanded over to all sta$eholders to answer" which are collected and compiled.

) shortcomin! of this techni+ue is" if an option for some issue is not mentioned inthe +uestionnaire" the issue mi!ht be left unattended.

Tas8 anal%sis

Team of en!ineers and developers ma anal ze the operation for which the new

s stem is re+uired. If the client alread has some software to perform certainoperation" it is studied and re+uirements of proposed s stem are collected.

Domain #nal%sis

2ver software falls into some domain cate!or . The e#pert people in the domaincan be a !reat help to anal ze !eneral and speci*c re+uirements.

rainstorming

)n informal debate is held amon! various sta$eholders and all their inputs arerecorded for further re+uirements anal sis.


7/18

Protot%ping

Protot pin! is buildin! user interface without addin! detail functionalit for user tointerpret the features of intended software product. It helps !ivin! better idea ofre+uirements. If there is no software installed at client9s end for developer9sreference and the client is not aware of its own re+uirements" the developer createsa protot pe based on initiall mentioned re+uirements. The protot pe is shown tothe client and the feedbac$ is noted. The client feedbac$ serves as an input forre+uirement !atherin!.

Observation

Team of e#perts visit the client9s or!anization or wor$place. The observe the actualwor$in! of the e#istin! installed s stems. The observe the wor$=ow at client9s endand how e#ecution problems are dealt. The team itself draws some conclusionswhich aid to form re+uirements e#pected from the software.

Data Flo5 Diagram

&ata =ow dia!ram is !raphical representation of =ow of data in an informations stem. It is capable of depictin! incomin! data =ow" out!oin! data =ow and storeddata. The &0& does not mention an thin! about how data =ows throu!h thes stem.

There is a prominent di erence between &0& and 0lowchart. The =owchart depicts=ow of control in pro!ram modules. &0&s depict =ow of data in the s stem atvarious levels. &0& does not contain an control or branch elements.

T%pes o, DFD

Data Flo5 Diagrams are either !ogi'al or Ph%si'al.

•


8/18

• Process / )ctivities and action ta$en on the data are represented b ircle or8ound/ed!ed rectan!les.

• &ata (tora!e / There are two variants of data stora!e / it can either berepresented as a rectan!le with absence of both smaller sides or as an open/sided rectan!le with onl one side missin!.

• &ata 0low / 3ovement of data is shown b pointed arrows. &ata movement isshown from the base of arrow as its source towards head of the arrow asdestination.

!evels o, DFD

•


9/18

•


10/18

invo$able from an module.

• ondition / It is represented b small diamond at the base of module. Itdepicts that control module can select an of sub/routine based on some

condition.

• Dump / )n arrow is shown pointin! inside the module to depict that the control

will 6ump in the middle of the sub/module.


11/18

•


12/18

binar value- is described" possible prede*ned values are listed" and a brief te#tualdescription is provided. This collection can be or!anized for reference into a boo$called a data dictionar .

$emanti' Data "odels 9ERD:

28/modelin! is a data modelin! techni+ue used in software en!ineerin! to producea conceptual data model of an information s stem. &ia!rams created usin! this 28/modelin! techni+ue are called 2ntit /8elationship &ia!rams" or 28 dia!rams or28&s. (o ou can sa that 2ntit 8elationship &ia!rams illustrate the lo!icalstructure of databases.

&r. Peter hen is the ori!inator of the 2ntit /8elationship 3odel. :is ori!inal paperabout 28/modelin! is one of the most cited papers in the computer software *eld.

urrentl the 28 model serves as the foundation of man s stem anal sis anddesi!n methodolo!ies" computer/aided software en!ineerin! , )(2- tools" andrepositor s stems.

The ori!inal notation for 28/&ia!rams uses rectan!les to represent entities" anddiamonds to represent relationships. )lternative notations include

• rowEs 0oot

• I&201F

There are three basic elements in 28/&ia!rams

• 2ntities are the Gthin!sG for which we want to store information. )n entit is aperson" place" thin! or event.

• )ttributes are the data we want to collect for an entiti .

• 8elationships describe the relations between the entities.

28&s show entities in a database and relationships between tables within thatdatabase. It is essential to have 28/&ia!rams if ou want to create a !ood databasedesi!n. The dia!rams help focus on how the database actuall wor$s.

$o,t5are Re4uirements *hara'teristi's

;atherin! software re+uirements is the foundation of the entire softwaredevelopment pro6ect. :ence the must be clear" correct and well/de*ned.

# 'omplete $o,t5are Re4uirement $pe'if'ations must be6


13/18

1. lear%. orrect@. onsistent4. oherentA. omprehensibleH. 3odi*able

. Jeri*ableK. PrioritizedL. >nambi!uous1C.Traceable11. redible source

Ob/e't "odelling

http6;;555.slideshare.net;guest


14/18

• >pper ase Tools / >pper )(2 tools are used in plannin!" anal sis and

desi!n sta!es of (&< .•


15/18

mana!ement tools help in storin! and sharin! pro6ect information in real/timethrou!hout the or!anization. 0or e#ample" reative Pro OMce" Trac Pro6ect"5asecamp.

Do'umentation Tools&ocumentation in a software pro6ect starts prior to the software process" !oesthrou!hout all phases of (&< and after the completion of the pro6ect.

&ocumentation tools !enerate documents for technical users and end users. Technical users are mostl in/house professionals of the development team whorefer to s stem manual" reference manual" trainin! manual" installation manualsetc. The end user documents describe the functionin! and how/to of the s stemsuch as user manual. 0or e#ample" &o# !en" &r2#plain" )dobe 8obo:elp fordocumentation.

#nal%sis Tools

These tools help to !ather re+uirements" automaticall chec$ for an inconsistenc "inaccurac in the dia!rams" data redundancies or erroneous omissions. 0ore#ample" )ccept @HC" )ccompa" ase omplete for re+uirement anal sis" Jisible)nal st for total anal sis.

Design Tools

These tools help software desi!ners to desi!n the bloc$ structure of the software"which ma further be bro$en down in smaller modules usin! re*nement techni+ues.

These tools provides detailin! of each module and interconnections amon!modules. 0or e#ample" )nimated (oftware &esi!n

*onfguration "anagement Tools

)n instance of software is released under one version. on*!uration 3ana!ementtools deal with

• Jersion and revision mana!ement

• 5aseline con*!uration mana!ement

• han!e control mana!ement

)(2 tools help in this b automatic trac$in!" version mana!ement and release

mana!ement. 0or e#ample" 0ossil" ;it" )ccu 82J.*hange *ontrol Tools

These tools are considered as a part of con*!uration mana!ement tools. The dealwith chan!es made to the software after its baseline is *#ed or when the software is*rst released. )(2 tools automate chan!e trac$in!" *le mana!ement" codemana!ement and more. It also helps in enforcin! chan!e polic of the or!anization.

Programming Tools


16/18

These tools consist of pro!rammin! environments li$e I&2 ,Inte!rated &evelopment2nvironment-" in/built modules librar and simulation tools. These tools providecomprehensive aid in buildin! software product and include features for simulationand testin!. 0or e#ample" scope to search code in " 2clipse.

Protot%ping Tools

(oftware protot pe is simulated version of the intended software product. Protot peprovides initial loo$ and feel of the product and simulates few aspect of actualproduct.

Protot pin! )(2 tools essentiall come with !raphical libraries. The can createhardware independent user interfaces and desi!n. These tools help us to build rapidprotot pes based on e#istin! information. In addition" the provide simulation ofsoftware protot pe. 0or e#ample" (erena protot pe composer" 3oc$up 5uilder.

=eb Development Tools

These tools assist in desi!nin! web pa!es with all allied elements li$e forms" te#t"script" !raphic and so on. Web tools also provide live preview of what is bein!developed and how will it loo$ after completion. 0or e#ample" 0ontello" )dobe 2d!eInspect" 0oundation @" 5rac$ets.

7ualit% #ssuran'e Tools

ualit assurance in a software or!anization is monitorin! the en!ineerin! processand methods adopted to develop the software product in order to ensureconformance of +ualit as per or!anization standards. ) tools consist ofcon*!uration and chan!e control tools and software testin! tools. 0or e#ample"(oapTest" )ppsWatch" D3eter.

"aintenan'e Tools

(oftware maintenance includes modi*cations in the software product after it isdelivered. )utomatic lo!!in! and error reportin! techni+ues" automatic error tic$et!eneration and root cause )nal sis are few )(2 tools" which help softwareor!anization in maintenance phase of (&< . 0or e#ample" 5u!zilla for defecttrac$in!" :P ualit enter.

$o,t5are Re4uirements

We should tr to understand what sort of re+uirements ma arise in the re+uirementelicitation phase and what $inds of re+uirements are e#pected from the softwares stem.

roadl% so,t5are re4uirements should be 'ategori>ed in t5o 'ategories6

Fun'tional Re4uirements

8e+uirements" which are related to functional aspect of software fall into thiscate!or .

The de*ne functions and functionalit within and from the software s stem.


17/18

E?#"P!E$

1. (earch option !iven to user to search from various invoices.%. >ser should be able to mail an report to mana!ement.@. >sers can be divided into !roups and !roups can be !iven separate ri!hts.4. (hould compl business rules and administrative functions.

A. (oftware is developed $eepin! downward compatibilit intact.Non&Fun'tional Re4uirements

8e+uirements" which are not related to functional aspect of software" fall into thiscate!or . The are implicit or e#pected characteristics of software" which usersma$e assumption of.

Non/functional re+uirements include /

1. (ecurit%.


18/18

) s stem is said be !ood if it provides means to use it eMcientl . >ser interfacere+uirements are brie= mentioned below /

1. ontent presentation%. 2as Navi!ation@. (imple interface

4. 8esponsiveA. onsistent >I elementsH. 0eedbac$ mechanism

. &efault settin!sK. Purposeful la outL. (trate!ical use of color and te#ture.1C.Provide help information11.>ser centric approach1%.;roup based view settin!s.

Module 2 Point 4

Documents

Transcript of Module 2 Point 4