Sei sulla pagina 1di 20

Prepared by: MELJUN P.

CORTES
COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

Chapter 1 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS I INTRODUCTION Software has now surpassed hardware as the success of many computer-based systems. The completeness and timeliness of information provided by software differentiate one company form its competitors. The design and human friendliness of a software product differentiate it from competing products with an otherwise similar function. It is software that can make the difference. Software Engineering is concerned with the theories methods and tools which are needed to develop the software for the computers. Software engineers model parts of the real world in software. These models are large abstract and comple! so they must be made visible in documents such as system designs user manuals and so on. Software Engineering has come far in its short lifetime" it still has far to go. II SOFTWARE CONCEPTS 2.1 Definition of Software The oftware !i"ht ta#e the fo$$owin" for!% It is an instruction or computer programs that when e!ecuted provide desired functions and performance It provided a data structure that enables the programs to ade#uately manipulate information. It has documents that describe the operation and use of the programs. 2.2 E&o$'tion of Software Table $.$ depicts the evolution of software within the conte!t of computer-based system and application areas. Ta($e 1.1 E)O*UTION OF SOFTWARE EAR*+ +EARS SECOND ERA ,-. !i/ 0.1 2 ,!i/ 0.1 $ate 3.1 2 %atch )ulti user &rientation multi programming 'imited *eal time distribution +atabase (ustom )anagement software System ,idesprea d distribution Software crisis began T4IRD ERA ,!i/ 3.1 !i/ 5.1 2 ,idesprea d growth and use of -( 'ow cost hardware (onsumer impact .lobal and 'ocal /rea 0etwork FOURT4 ERA ,!i/ 5.1 6 (e7on/2 -owerfu l desktop systems &b1ect oriented technologies E!pert systems /rtificial neural networks Softwar e crisis continued

2.2.1 The Ear$7 +ear +uring this period a batch orientation was used for most systems. It is a processing that handles the entire se#uence of 1obs together. Software on the other hand was custom-designed for each application and had a relatively limited distribution. -roduct software was in its infancy.2i.e programs developed to be sold to one or more customers3. 2.2.2 The Se8on/ Era )ultiprogramming and multi user system introduced new concepts of human-machine interaction. *eal time systems could collect analy4e and transform data from multiple sources thereby controlling processes and producing output in milliseconds. /dvances in on-line storage led to the first generation of +atabase )anagement Systems. The advent of software houses and software was developed for widespread distribution. Software companies sold hundreds or thousands copies of their programs.

Prepared by: MELJUN P. CORTES

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

In this period software crisis loomed on the hori4on.

2.2.9 The Thir/ Era This period was characteri4ed by widespread growth and use of personal computers. The use of microprocessors for intelligent products. Software product sales continued to grow since they sold their software for tens or even hundred thousands of copies. 2.2.: The Fo'rth Era &b1ect-oriented technologies were rapidly displacing more conventional software development. E!pert System and artificial intelligence software had finally moved from laboratory into practical application. /s we move into this period the software crisis continued to intensity. These are the problems5 $. 6ardware sophistication has outpaced our ability to build software to tap hardware7s potential. 8. &ur ability to build new programs cannot keep pace with the demand for new programs. 9. &ur ability to maintain e!isting programs is threatened by poor design and inade#uate resources. 2.9 Attri('te of We$$6En"ineere/ Software The attributes of a software product are the characteristics shown on Table $.8. The relative importance of these characteristics varies from system to system but these are #uality attributes which are the essence of well-engineered software. These are not the services provided by the product but rather they are concerned with product7s dynamic behavior and the use of the product. Ta($e 1.2 E entia$ attri('te of we$$6en"ineere/ oftware. PRODUCT C4ARACTERISTICS PRODUCT DESCRIPTIONS )aintainability It should be possible to evolve software to meet the changing need of customers. +ependability It includes a range of characteristics such as reliability security and safety. +ependable software should not cause physical or economic damage in the event of system failure. Efficiency Software should not make wasteful use of system resources such as memory and processor cycles. :sability Software should have an appropriate user interface and ade#uate documentation. 2.: App$i8ation of Software The following software areas indicate the potential applications. 2.:.1 S7 te! Software (ollection of programs written to service other programs. E;a!p$e % compilers editors file management utilities operating systems drivers etc. 2.:.2 Rea$6Ti!e Software )onitors analy4ed controls real world events Elements include a data gathering component that collects information from e!ternal environment an analysis component that transforms information as re#uired by application and a monitoring component that coordinates all other components so that real-time response can be maintained. E;a!p$e % /riane ; < 2space rocket belonging to the European Space /gency ; ES/ a software involved in almost all aspects of the system from the guidance of the rocket to the internal workings of its component parts.3 2.:.9 <' ine Software

Prepared by: MELJUN P. CORTES

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

It has evolved into )anagement Information System 2)IS3 software that accesses one or more large database containing business information. /pplication in this restructure e!isting data in away that facilitates business operations and management decision ; making. E;a!p$e % -ayroll System /ccounting System Inventory System etc. 2.:.: En"ineerin" an/ S8ientifi8 Software (haracteri4ed by number crunching algorithms /pplication range from astronomy to volcanology from automotive stress analysis to space shuttle orbital dynamics and from molecular biology to automated manufacturing. E;a!p$e % (/+ 2(omputer /ided +esign3 2.:.- E!(e//e/ Software *esides in read-only memory and is used to control products. (an perform very limited functions or provide significant functions and control capabilities. E;a!p$e % keypad control for a microwave oven digital functions in automobile and braking system etc. 2.:.0 Per ona$ Co!p'ter Software (ontinues to represent some of the most innovative human-interface designs of all software. E;a!p$e % ,ord processing programs .raphics Entertainment +atabase )anagement Spreadsheets etc. 2.:.3 Artifi8ia$ Inte$$i"en8e Software )akes use of non-numerical algorithms to solve comple! problems that are not amenable to computation or straightforward analysis. E;a!p$e % E!pert Systems .ames and (omputer /ided Instructions 2.- Software Pro8e It is a set of activities and associated results which produce a software product. These activities are mostly carried out by software engineers. (/SE 2computer /ided Software Engineering3 tools may use to help with some process activities. The f'n/a!enta$ pro8e % 2.-.1 Software pe8ifi8ation =unctionality of the software and constraints on its operation must be defined. 2.-.2 Software /e&e$op!ent Software must be produced to meet the software specification. 2.-.9 Software &a$i/ation Software must be validated to ensure that it does what the customer wants 2.-.: Software e&o$'tion Software must evolve to meet changing customer needs. 2.0 Software Cri i Includes a set of problems that are encountered in the development of computer software. (risis or affliction encompasses problems associated with how we can e!pect to keep pace with a growing demand for more software. Software De&e$op!ent Pro($e! % $. Schedule and cost estimates are often grossly inaccurate. 8. -roductivity of the software development people has not kept pace with the demand for their services. 9. >uality of software is sometimes less than inade#uate. III. SOFTWARE ENGINEERING CONCEPTS 9.1 Definition of Software En"ineerin" -rocess of developing useful software +iscipline for developing high-#uality software for computer based systems.

Prepared by: MELJUN P. CORTES

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

Encompasses a set of three key elements ; methods tools and procedures that enable the manager to control the process of software development and provide the practitioner with a foundation for building high #uality software in a productive manner.

9.2 The Software En"ineer / software engineer has both defined purpose and an awareness of real world factors such as schedule budget politics etc. The term programmer will be used interchangeably with the term software engineer. %oth terms mean the same kind of person ; serious and aware. :nderstanding software engineering principles alone will not make one software engineer. =rom figure $.$ it summari4es the programming personalities including the software engineer. &ther programmers are also defined on this page. Fi"'re 1.1 PROGRA==ING PERSONA*ITIES AWARENESS OF REA* WOR*D FACTORS

Undirected Programmer

SOFT !" # #$%&$##" ESTABLISHED PURPOSE

Compulsive Programmer

Serious Programmer

Other Pro"ra!!in" Per ona$itie % o o o Co!p'$ i&e Pro"ra!!er ; lack of purpose and awareness of real world factors. Un/ire8te/ Pro"ra!!er ; aware of real world factor but no goals. Serio' Pro"ra!!er ; have a clearly established goal but may decide to ignore real world factors.

9.9 >e7 to Software En"ineerin" In order for the software engineer to achieve their goals solve problems in a simple and controlled manner" these are the following keys to a good software engineering. 9.9.1 9.9.2 9.9.9 P*ANNING / plan defines the technical approach the length of the pro1ect and the resources re#uired for the effort. 4A)ING =ET4ODS (oncentrating on the #uality of the software7s structure evaluating the structure of data and building software according to the format of the output are some methods that help the software engineers. ORGANI?ING WOR> Software engineers must be organi4ed so that the other can use the results of one pro1ect activity. =or e!ample identifying ma1or software development activities

Prepared by: MELJUN P. CORTES

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

9.9.?

C*EAR CO==UNICATION. (lear communication among the participants of a software development team is fundamental to successful software engineering. Information written in an understandable and directly usable form will communicate best.

9.: Software En"ineerin" E$e!ent 9.:.1 =etho/ Encompass a broad array of tasks that include5 pro1ect planning and estimation system and software re#uirements analysis design of data structure coding testing and maintenance. 9.:.2 Too$ -rovide automated or semi-automated support for methods :sed (omputer /ided Software Engineering 2(/SE3 a system support of software development. It combines software hardware and a software engineering database to create a software engineering environment. 9.:.9 Pro8e/'re .lue that holds methods and tools together. Enable rational and timely development of computer software. 9.- Software Pro8e =o/e$ +etailed software process models are still the sub1ects of research but it is now clear that there are a number of different general models or paradigms of software development. 9.-.1 C$a i *ife C78$e /lso called the ,aterfall )odel @iews the software process as being made up of a number of stages +emands a systematic se#uential approach to software development that begins at the system level and progresses through analysis design coding testing and maintenance as shown in =igure $.8.

Fi"'re 1.2 T4E WATERFA** =ODE*

"e(uirements !nalysis and Speci)ication

System and So)t*are +esign

&mplementation and Unit Testing

&ntegration and System Testing

Prepared by: MELJUN P. CORTES

'

Operation and ,aintenance

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

Waterfa$$ =o/e$ A8ti&itie % 1. Re@'ire!ent Ana$7 i an/ Spe8ifi8ation System7s services constraints and goals are established by consultation with users. It should be understandable by both users and development staff. 2. S7 te! an/ Software De i"n It establishes an overall system architecture. Involves representing the software system functions in form that may be transformed into one or more e!ecutable programs. I!p$e!entation an/ Unit Te tin" Software design is reali4ed as a set of programs. :nit testing involves verifying that each unit meets its specifications. Inte"ration an/ S7 te! Te tin" -rogram units are integrated and tested as a complete system to ensure that the software re#uirements have been met.

9.

:.

-.

Operation an/ =aintenan8e 'ongest life cycle phase. Involves correcting errors updating enhancing the system services etc.

Pro($e! of C$a i8 *ife C78$e The model provides no guidance to managers and developers on how to handle changes to products and activities that are likely to occur during development. =or instance when re#uirements change during coding activities the subse#uent changes to design and code are not addressed by the waterfall model. It also tell us nothing about the typical back-and forth activities that lead to creating a final product. Iterations by itself always produce problems. The customer has to wait for a really long time before he even gets feel of the real pro1ect i.e working version of prototype is not available early in the cycle. 9.-.2 Protot7pin" =o/e$ /llows all or part of a system to be constructed #uickly to understand and clarify issues it has the same ob1ectives as an en"ineerin" protot7pe where re#uirements or design re#uire repeated investigation to ensure that the developer user and customer have a common understanding both of what is needed and what is proposed. &verall goal is reducing risk and uncertainty in development. E;a!p$e% +evelopers may build a system to implement a small portion of some key re#uirements to ensure the re#uirements are consistent feasible and practical" if not revisions are made at the re#uirements stage rather than at the more costly testing stage. Fi"'re 1.9 PROTOT+PING =ODE*

Prepared by: MELJUN P. CORTES

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

0&ST OF "#1&S&O$S "evise Prototype User3 Customer revie*

0&ST OF "#1&S&O$S

0&ST OF "#1&S&O$S

0&ST OF "#1&S&O$S

P"OTOT2P# "e(uirements

P"OTOT2P# +esign

P"OTOT2P# System

T#ST System

System "e(uirements

+elivered System
Set re#uirements supported by the customers and users. Then alternatives are e!plored by having interested parties look at possible screens tables reports and other system output that are used directly by the customers and users. /s the users and customers decide on what they want the re#uirements are revised. +evelopers move on to design and again alternative designs are e!plored often with consultation with customers and users. The initial design is revised until developers users and customers are happy with the result. (onsidering design alternatives reveal a problem with the re#uirements and the developers drop back to the re#uirements activities to reconsider and change the re#uirements specification. System is coded tested and alternatives are discussed with possible iteration through re#uirements and design again.

Pro($e! in Protot7pin" It is often rushed and long-term aspects of overall software #uality and maintainability not considered. +eveloper often makes implementation promises in order to get prototype working #uickly. 9.-.9 Fo'rth Generation Te8hni@'e =ocuses on the ability to specify software to a machine at a level that is close to natural language. Feat're of :GT Too$ % +atabase >uery *eport .eneration +ata )anipulation Screen Interaction (ode .eneration .raphicsASpreadsheets Fi"'re 1.: Fo'rth Generation Te8hni@'e

"e(uirements %at.ering

+esign Strategy

&mplementation 4%0
Prepared by: MELJUN P. CORTES

/ Testing

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

Re@'ire!ent Gatherin". Ideally the customer could actually describe the re#uirements and these would be directly translated into an operational prototype. 6owever this is generally unworkable since the customer may be unsure of what e!actly is re#uired or introduce a degree of ambiguity in these re#uirements. De i"n Strate"7. &ften for smaller scale software applications it is possible to move directly to implementation using ?.' 2?th .eneration 'anguage3 but in large scale it is necessary to develop design strategy. The use of B.T with design strategy will not cause difficulties in poor #uality poor maintainability and poor customer acceptance. I!p$e!entation ' in" :G*. It enables the developer to represent desired results in a manner that results in automatic generation of code. Te tin". +eveloper must conduct through testing develop meaningful documentation and perform all other transition activities that are also re#uired in other software engineering paradigm.

Pro($e! on :GT% It is limited to business information system applications especially in information analysis and reporting that is keyed to large databases. -reliminary data collected and the amount of design and analysis seem to indicate that time re#uired to produce software 6owever the use of ?.T for large software development efforts demands more analysis design and testing. 9.-.: Tran for!ationa$ =o/e$ %la4er7s transformational model tries to reduce the opportunity for errors by eliminating several ma1or development steps. The specification is transformed through a series of correctness-preserving ; means that you can be sure that the developed program meets its specification.

Fi"'re 1.- TRANSFOR=ATIONA* =ODE*

Compare re(uirements5 update

FO",!0 +#1#0OP,#$T "#CO"+

Se(uence o) trans)ormation

FO",!0 SP#C&F&C!T&O$ System "e(uirements

T"!$SFO", $ T"!$SFO", 2 T"!$SFO", 1

T#ST

+elivered System

Prepared by: MELJUN P. CORTES

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE AND SOFTWARE ENGINEERING CONCEPTS

Pro($e! on Tran for!ationa$ =o/e$% (hoosing which transformation to apply is a skilled task and proving the correspondence of transformations is difficult. It will ever be adopted for large systems development.

Prepared by: MELJUN P. CORTES

COLLEGE OF COMPUTER STUDIES

Prepared by: MELJUN P. CORTES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

Chapter 2 REAUIRE=ENTS ANA*+SIS AND CONCEPTS I. O&er&iew Software engineers need to look at the role if the software in the proposed system. Software re#uirements analysis is necessary to avoid creating a software product that fails to meet the customer7s needs. +ata functional and behavioral re#uirements are elicited fro the customer and refined to create a specification that can be used to design the system. Software re#uirements work products must be reviewed for clarity completeness and consistency. II. Re@'ire!ent Ana$7 i Software engineering task that bridges the gap between system level re#uirements engineering and software design. 2=igure 8.$3 -rovides software designer with a representation of system information function and behavior that can be translated to data architectural and component-level designs. E!pect to do a little bit of design during analysis and a little bit of analysis during design. Fi"'re 2.1 Re@'ire!ent Ana$7 i a a <ri/"e

System System #ngineering #ngineering

So)t*are "e(uirements !nalysis

So)t*are So)t*are +esign +esign

2.2.1 Software Re@'ire!ent Ana$7 i Pha e /ccording to %rian 'awrence ,e spend a lot of time the ma1ority of total pro1ect time not implementing or testing but trying to decide what to build. Pro($e! Re8o"nition ; know the basic problem elements as perceived by the customer A users. E&a$'ation an/ 7nthe i ; upon evaluating current problems and desired information 2input and output3 the analysts begins to synthesi4e one or more solutions. =ocus is on what not how. ,hat does the system produce and consume what functions must perform what constraints applyC Etc. =o/e$in" ; serves as a foundation of software design and as a basis for the creation of specifications. (reate a model of the system that will enable to have better understanding of data and control flow. Spe8ifi8ation ; a representation of software that can be reviewed and approved by the customer. / 1oint effort of the developer and the customer. *eview conducted also by customer and developer where results in modifications to functions performance constraints information representations etc.

2.9 Software Re@'ire!ent Co!!'ni8ation Te8hni@'e (ustomer meetings are the most commonly used techni#ue. :se conte!t free #uestions to find out customer7s goals and benefits identify stakeholders gain understanding of problem determine customer reactions to proposed solutions and assess meeting effectiveness If many users are involved be certain that a representative cross section of users is interviewed. 2.9.1 Fa8i$itate/ A8tion Te8hni@'e ,FAST2 =/ST encourages working together mentality rather than working individually. )eeting held at neutral site attended by both software engineers and customers. *ules established for preparation and participation. /genda suggested to cover important points and to allow for brainstorming. )eeting controlled by facilitator 2customer developer or outsider3. +efinition mechanism 2flip charts stickers electronic device etc.3 is used. .oal is to identify problem propose elements of solution negotiate different approaches and specify a preliminary set of solution re#uirements. 2.9.2 A'a$it7 F'n8tion Dep$o7!ent ,AFD2

COLLEGE OF COMPUTER STUDIES

Prepared by: MELJUN P. CORTES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

&riginally developed in Dapan and first used at the Eobe Shipyard of )itsubishi 6eavy Industries 'td. in the early $FGH. Translates customer needs into technical software re#uirements. +efines re#uirements in away that ma!imi4es customer satisfaction. :ses customer interviews observation surveys and historical data for re#uirements gathering. F'n8tion /ep$o7!ent ; used during customer meetings to determine the value of each function re#uired for system. Infor!ation /ep$o7!ent ; identifies data ob1ects and events produced and consumed by the system. Ta # /ep$o7!ent ; e!amines the behavior of product within its environment. )a$'e ana$7 i ; used to determine the relative priority of re#uirements during function information and task deployment.

2.: Software Re@'ire!ent Software re#uirements should set out what the system should do rather how this is done. The process of determining the re#uirements for a software-based system is very important to define its needs in a sufficiently abstract way. 2.:.2 Software Re@'ire!ent Do8'!ent Sometimes called the software re#uirements specification 2S*S3 &fficial statement of what is re#uired of the system developers %asis of contract between the client and contractor (ombination of re#uirements definition and re#uirements specification. Two >in/ of Re@'ire!ent Do8'!ent Re@'ire!ent /efinition ; a complete listing of everything the customer e!pects the proposed software to do. It represents an understanding between customer and developer of what the customer needs or wants and it is usually written 1ointly by the customer and developer. Re@'ire!ent pe8ifi8ation ; restates the re#uirement definition in technical terms appropriate for the development of the software design" it is technical counterpart to the re#uirement definition document and it is written by re#uirements analyst. Si; Chara8teri ti8 of a Software Re@'ire!ent Do8'!ent Specify e!ternal system behavior Specify constraints on the implementation Easy to change *eference tool for system maintainers *ecord forethought amount life cycle of the software (haracteri4e acceptable responses to undesired events. Ta($e 2.1 Str'8t're of a Re@'ire!ent Do8'!ent Chapter Intro/'8tion De 8ription It should briefly describe its functions and e!plain how it will work with other systems. It should describe how the system fits into overall business or strategic ob1ectives of the organi4ation commissioning the software. +efine the technical terms used in the document. This should set out one or more system models showing the relationships between the system components and its environment. The services provided for the user should be described in this section. This description may use natural language diagrams or other notations that are understandable by customer. The constraints imposed on the software and restrictions on the freedom of the designer should be described here and related to the functional re#uirements. Include details of specific data representation response time and memory re#uirements and etc. This should describe the functional re#uirements in more detail. If necessary further detail may also be added to the non-functional re#uirements for e!ample interfaces to other system may be defined. This should describe the functional re#uirements in more detail. If

G$o ar7 S7 te! =o/e$ F'n8tiona$ Definition Re@'ire!ent

Non6F'n8tiona$ Re@'ire!ent Definition S7 te! E&o$'tion

17

COLLEGE OF COMPUTER STUDIES

Prepared by: MELJUN P. CORTES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

necessary further detail may also be added to the non-functional re#uirements for e!ample interfaces to other system may be defined. Re@'ire!ent Spe8ifi8ation Chapter 9 REAUIRE=ENTS ANA*+SIS =ODE* III Re@'ire!ent Ana$7 i =o/e$ Definition of Re@'ire!ent Ana$7 i =o/e$ 'eads to a complete specification of re#uirements and a comprehensive design representation for the software to be built. Set of models that serves as a technical representation of a system. 4i tor7 of Re@'ire!ent Ana$7 i =o/e$ Early work in analysis modeling begun in the late $FIHs and early $FGHs JStructured analysis7 originally coined by +ouglas *oss was populari4ed by +e)arcoK+E)GFL. In his book on the sub1ect +e)arco introduced and named the key graphical symbols. In the years that followed variations of the structured analysis approach were suggested by -ageDonesK-/.MHL .ane and SamsonK./0M8L and many others. %y mid-$FMHs real-time e!tensions were introduced by ,ard and )ellorK,/*M<L and later by 6atley and -irbhaiK6/TMGL. This e!tensions resulted in a more robust analysis method. 9.9 Co!!on$7 U e/ Ana$7 i =o/e$ ,Data =o/e$in"2 9.9.1 Data Di8tionar7 a repository that contains descriptions of all ob1ects consumed or produced by software. - It is an organi4ed listing of all data elements that are pertinent to the system with precise rigorous definitions so that both user and system analyst will have common understanding of inputs outputs components of stores and intermediate calculations. Content De 8ription for Data Di8tionar7 Data Con tr'8t Notation N Se#uence O Selection KPL *epetition Q R0 23 SS E;a!p$e of Content De 8ription of the Data Di8tionar7% C' to!er Na!e N 2)r. P )s.3 O legal characters A//re B 2street no.3 O town P city O country code O country Street no N T O H..F Town C 8it7 N legal characters Co'ntr7 Co/e N Sany four number stringS Co'ntr7 B legal characters *e"a$ Chara8ter B K /..U P a..4 P P . P - L =eanin" Is composed of /nd Either-or 0 repetitions of &ptional data +elimits comments

11

COLLEGE OF COMPUTER STUDIES

Prepared by: MELJUN P. CORTES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

9.9.2 Entit7 Re$ation hip Dia"ra! ,ERD2 depicts the relationships between data ob1ects. / notation that is used to conduct data modeling activity. ERD <ASIC S+=<O*S% DATA O<EDCT ; can be an e!ternal enity a thing an occurrence or event a role a place or an organi4ation.

RE*ATIONS4IP ; indicate the manner in which data ob1ects are connected to one another.

T+PES OF RE*ATIONS4IP% 1. Unar7

,an
2. <inar7

)arrie s ,oman

)an
9. Ternar7

)arrie s

Teacher

teache s

Sub1ect

Student
:. S'(t7pe

(ar

/merican
-. Car/ina$it7

/sian

)anufacturer

%uild s

(ar

0.

=o/a$it7

12

COLLEGE OF COMPUTER STUDIES

Prepared by: MELJUN P. CORTES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

(ustomer

Is provide d with

*epair /ction

9.9.9 Data F$ow Dia"ra! provide an identification of how data are transformed as they move through the system. +epicts the functions and subfunctions that transform the data flow. DFD <ASIC S+=<O*S% E;terna$ Entit7 specifies either the source or the destination of data. It shows where data originates outside a system or where it will be transmitted after processing always outside the system. Pro8e represents the transformation or processing of information within a system. The process symbol shows those places in a system where calculations are made or where information is changed in character. Data Store is a point in a system where information is permanently or temporarily stored or held. T7pe of DFD% 1. 2. Conte;t Data F$ow Dia"ra! shows the entire system as one general element. It is the most overall view we can obtain of a system. /ll sources and sinks of data are linked to this one entity using flowlines or pipes. E;p$o/e/ Data F$ow Dia"ra! since conte!t diagrams do not show detail it is necessary to draw additional diagrams to refine or e!pand individual elements. E!plosion is a method by which a group of related charts e!plain an operation in increasingly more detailed levels.

13

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

Chapter : SOFTWARE DESIGN The importance of software design can be stated with a single word ; >:/'ITV. +esign is the place where the #uality is fostered in software engineering. +esign provides us with representations of software that can be assessed for #uality. +esign is the only way that we can accurately translate a customer7s re#uirements into a finished software product or system. :.1 Software De i"n Definition / process through which re#uirements are translated into a representation of software. Serves as the foundation for all software engineering and software maintenance steps that follow. ,ithout design we risk building an unstable system ; one that will fail when small changes are made" one that may be difficult to test" one whose #uality cannot be assessed. 2*efer on =igure ?.$3 Fi"'re :.1 Software De i"n a Fo'n/ation for a$$ Software En"ineerin"

,!&$T#$!C# T#ST &,P0#,#$T!T&O$ +#S&%$


WIT4 DESIGN :.2

,!&$T#$!$C# T#ST &,P0#,#$T!T&O$


WIT4OUT DESIGN

De i"n Pro8e / se#uence of steps that enable the designer to describe all aspects of the software to be built. It is not simply like a cookbook therefore creative skill past e!perience a sense of what makes good software and an overall commitment to #uality are necessary. Involves adding formality as design progresses with constant backtracking to correct earlier and less formal design 2=igure ?.83. The designer starts with a very informal picture then refines by adding information to make the design more formal until it reached the finished design. Fi"'re :.2 The Pro8e of De i"n

&n)orm al design outline

&n)ormal design

,ore )ormal design

Finis.ed +esign

Fro! the proEe8t !ana"e!ent &iew% Software design is conducted in two steps5 a. b. Pre$i!inar7 /e i"n ; concerned with the transformation of re#uirements into data and software architecture. Detai$ /e i"n ; focuses on refinements to the architectural representation that lead to detailed data structure and algorithmic representations for software.

,ithin the conte!t of preliminary and detail design a number of different design activities occur. %esides the three main activities such as data design architectural design and procedural design there is also the interface design which establishes the layout and interaction mechanism for human-machine interaction. The relationship between the technical and management aspects if design is shown in figure ?.9.

11

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

Fi"'re :.9 Re$ation hip (etween te8hni8a$ an/ !ana"e!ent a pe8t of /e i"n

,anagement !spects Tec.nical !spects

Preliminary Design Detail Design +ata +esign !rc.itectural +esign Procedural +esign &nter)ace +esign

:.9 Data De i"n Sometimes referred to as data architecting. (reates a model of data and A or information that is represented at the customer7s or user7s view of data. The ob1ective of data design is to transform the information domain into data structures. The structure of data has always been an important part of software design. /t the procedural design the data structure and the associated algorithms re#uired to manipulate them is essential to the creation of high #uality creations. :.: Ar8hite8t'ra$ De i"n )elds program structure and data structure defining interfaces that enable data to flow throughout the program. The primary ob1ective is to develop a modular program structure and represent the control relationships between modules. It combines program structure and data structure thus defining interfaces that will enable data to flow throughout the program. :.- U er Interfa8e De i"n The most important element of a computer-based system or product. Serve as the yardstick to the user which the software is 1udged. Software engineers must often take responsibility for the user interface design. :.-.1 U er Interfa8e De i"n Prin8ip$e )ust take into account the needs e!perience and capabilities of the system user. a. b. c. d. e. U er Fa!i$iarit7 ; should use terms and concepts which are familiar to the anticipated class of user. Con i ten87 ; should be appropriately consistent. =ini!a$ 'rpri e ; user should not be surprised by the system. Re8o&era(i$it7 should include some mechanism which allows users to recover from their errors. U er "'i/an8e interface skills incorporate some form of user guidance.

:.-.2 Graphi8a$ U er Interfa8e :ser interface which rely on windows iconic representation with entities pull-own or pop-up menus and pointing devices are now common place on personal computers and workstations. ,I)- 2,indows Icons )enus and -ointing +evice3 is the term use before .:I. :.-.2.1 GUI Chara8teri ti8 Win/ow ; multiple windows allow different information to be displayed simultaneously on the user7s screen. I8on icons represent different types of information such as files processes. =en' commands are selected from a menu rather than in a common language. Pointin" a pointing device like mouse is used fro selecting choices from a menu or indicating items of interest in a window. Graphi8 graphics elements can be mi!ed with te!t on the same display.

12

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

:.-.2.2 A/&anta"e of GUI Easy to learn and use :ser has multiple screens for system interaction =ast full screen interaction is possible rather than line-oriented interaction re#uired by command interface. :.-.9 Dire8t =anip'$ation -resent users with a model of their information space and they modify their information by direct action. E!ample5 ,ord processor or screen editors. :.-.9.1 A/&anta"e :sers feel in control of the computer and are not intimidated by it. Typical user learning time is short. :sers get immediate feedback on their actions so mistakes can be detected and corrected very #uickly. &ne of the simplest and easiest to understand direct manipulation interface is form-based interface. 2*efer =igure ?.? for sample3 Fi"'re :.: For!6(a e/ interfa8e for a t'/ent re"i tration 7 te!

STUDENT PERSONAL INFORMATION Student number: Student $ame: !ddress: 8irt. +ate: "eligion: +ate: Course: 8irt.place: Status: Citi9ens.ip:

:.-.: Interfa8e =o/e$ /nalogous to some real world model familiar to the user. :sually used in desktop metaphor where user7s screen represent a desktop Systems maintain the desktop metaphor to some e!tent but supplement this by adding a control panel which is a graphical representation of system commands. :.-.:.1 >in/ of entit7 whi8h !a7 (e repre ente/ in a 8ontro$ pane$ <'tton pocking a button always causes a single action to be initiated. Swit8he it may be set at a number of positions to configure a system or to move a system from one state to another. =en' collections of buttons or switches which may be made visible and selected. *i"ht 6 activated to show actions taking place. Di p$a7 areas of the panel where graphical or te!tual information may be displayed. They have a name and a value. The user interface designer may control whether or not may be edited. S$i/er are input devices used to set a specific input value. The user drags the slider along the scale to set the re#uired value.

:.-.- =en' S7 te!

13

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

In a menu interface users select one of a number of possibilities to issue a command to the machine.

:.-.:.1 A/&anta"e :sers do not need to know command names. Typing effort is minimal. Some kinds of user error are avoided. (onte!t-dependent help can be provided. :.-.0 Co$or Di p$a7 (olor is a powerful tool but it is easy to misuse it to produce displays which are error prone and disturbing to the user. :.-.0.1 G'i/e$ine for the effe8ti&e ' e of 8o$or +on7t use many colors. :se color-coding to support task which users are trying to perform be consistent. +esign for monochrome display then add color later. (areful about color pairings. :se color change to show change in system status. :.-.3 U er G'i/an8e 6elp systems are one facet of a general part of user interface design namely the provisions of user guidance which covers three areas5 a. The messages produced by the system in response to user actions. b. The on-line help system. c. The documentation provided with the system. :.0 Pro8e/'ra$ De i"n /lso called component design occurs after data architectural and interface designs have been established. The ob1ective is to transform structural components into a procedural description of the software. :.0.1 Pro"ra! De i"n *an"'a"e ,PD*2 /lso called Structured English or pseudocode. :sed as a generic reference for design language. E;a!p$e% +isplay )ain Screen +isplay )enu WNH VN9 *epeat If 2!X<3 then +o while 2yXH3 (ompute 4 N ! O y (ompute y N y ; $ End+o Else (ase ( $5 -erform -rocedure /dd 85 -erform -rocedure Edit End(ase EndIf (ompute ! N ! O $ :ntil 2! N <3 :.0.2 Graphi8a$ De i"n Notation :se graphical tools such flowchart or bo! diagram provide useful poictorial patterns that readily depict procedural detail. :.0.1.1 F$ow8hart 8on tr'8t

14

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

>uite simple pictorially. %&W ; used to indicate processing +I/)&0+ ; represents logical condition and /**&,S ; show the flow of control.

Fi"'re :.0 F$ow8hart Con tr'8t IF T4EN6E*SE

conditio n

#0S# part

T;#$ part

REPETITION DO W4I*E

T"U# +o .il e

F!0S#

0OOP T!S:
REPETITION REPEAT UNTI*

F!0S# "epe at Until

T"U#

0OOP T!S:
CASE CONDITION

T
C!S# Conditio n

T
C!S# Conditio n

1'

Prepared by: MELJUN P. CORTES


COLLEGE OF COMPUTER STUDIES

CSCI15 SOFTWARE ENGINEERING CONCEPTS

Chapter SOFTWARE TESTING Software testing is a critical element of software #uality assurance and represents the ultimate review of specification design and code generation. -.1 Te tin" Pro8e The most widely used testing process consists of five stages as shown in figure <.$. Fi"'re -.1 Te tin" Pro8e

Unit Testing ,odule Testing Sub< system Testing

System Testing !cceptanc e Testing

Te $. 8. 9.

tin" Pro8e % Unit te tin" ; individual components are tested to ensure that they operate correctly. =o/'$e te tin" ; a module encapsulates related components so can be tested without other system modules. S'(6 7 te! involves testing collections of modules which have been integrated into sub-systems. The sub-system test process should concentrate on the detection of interface errors. ?. S7 te! te tin" the sub-system are integrated to make up the entire system. It is also concerned with validating that the system meets its functional and non-functional re#uirements. <. A88eptan8e te tin" may reveal errors and omissions in the system re#uirements definition because the real data e!ercises the system in different ways from the test data. It may also reveal re#uirements problems where the system7s facilities do not really meet the user7s needs or the system performance is unacceptable. -.2 Te tin" Strate"ie Is a general approach to the testing process rather than a method of devising particular system or component tests. 1. Top6/own te tin" ; testing starts with the high levels of a system before testing its detailed components. 2. <otto!6'p te tin" ; involves testing the modules at the lower levels in the hierarchy and then working up the hierarchy of modules until the final module is tested. 9. Threa/ te tin" ; a testing strategy which was devised from testing real-time systems. It maybe be used after processes or ob1ects have been individually tested and integrated into sub-system. :. Stre te tin" 6 relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with overload situations. -. <a8#6to6(a8# te tin" ; may be used when more than one version of a system is available for testing. The same tests are presented to both versions of the system and the test results compared.

1-