meljun cortes manual software engineering csci15

8/13/2019 MELJUN CORTES MANUAL Software Engineering CSCI15

1/20


2/20

Prepared by: ELJUN P. CORTESCOLLEGE 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 evenhundred thousands of copies.

2.2.: The Fo'rth Era

&b1ect-oriented technologies were rapidly displacing more conventional softwaredevelopment.

E!pert System and artificial intelligence software had finally moved from laboratory intopractical application.

/s we move into this period the software crisis continued to intensity. These are theproblems5

$. 6ardware sophistication has outpaced our ability to build software to taphardware7s potential.

8. &ur ability to build new programs cannot keep pace with the demand for newprograms.

9. &ur ability to maintain e!isting programs is threatened by poor design andinade#uate resources.

2.9 Attri('te of We$$6En"ineere/ SoftwareThe 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 #ualityattributes which are the essence of well-engineered software. These are not the servicesprovided by the product but rather they are concerned with product7s dynamic behavior and theuse of the product.Ta($e 1.2 Eentia$ attri('te of we$$6en"ineere/ oftware.

PRODUCT C4ARACTERISTICS PRODUCT DESCRIPTIONS

)aintainability It should be possible to evolve software to meet thechanging need of customers.

+ependability It includes a range of characteristics such as reliabilitysecurity and safety. +ependable software should not

cause physical or economic damage in the event ofsystem failure.

Efficiency Software should not make wasteful use of systemresources such as memory and processor cycles.

:sability Software should have an appropriate user interface andade#uate documentation.

2.: App$i8ation of SoftwareThe following software areas indicate the potential applications.

2.:.1 S7te! 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 componentthat collects information from e!ternalenvironment an analysis component that transforms information as re#uired byapplication and a monitoring component that coordinates all other components sothat real-time response can be maintained.

E;a!p$e%/riane ; < 2space rocket belonging to the European Space /gency ; ES/ asoftware involved in almost all aspects of the system from the guidance of the rocket tothe internal workings of its component parts.3

2.:.9


3/20


It has evolved into )anagement Information System 2)IS3 software that accessesone or more large database containing business information.

/pplication in this restructure e!isting data in away that facilitates businessoperations 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 automatedmanufacturing.

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 controlcapabilities.

E;a!p$e% keypad control for a microwave oven digital functions in automobile andbraking system etc.

2.:.0 Perona$ Co!p'ter Software

(ontinues to represent some of the most innovative human-interface designs of allsoftware.

E;a!p$e%,ord processing programs raphics Entertainment +atabase )anagementSpreadsheets etc.

2.:.3 Artifi8ia$ Inte$$i"en8e Software

)akes use of non-numerical algorithms to solve comple! problems that are notamenable to computation or straightforward analysis.

E;a!p$e%E!pert Systems ames and (omputer /ided Instructions

2.- Software Pro8eIt 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 SoftwareEngineering3 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 wants2.-.: Software e&o$'tion

Software must evolve to meet changing customer needs.

2.0 Software Crii

Includes a set of problems that are encountered in the development of computersoftware.

(risis or affliction encompasses problems associated with how we can e!pect to keeppace 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: ELJUN P. CORTES 3


4/20

Undirected

Programmer


Encompasses a set of three key elements ; methods tools and procedures that enable the managerto 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 budgetpolitics etc.

The termprogrammer will be used interchangeably with the term software engineer. %oth terms mean the samekind 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 alsodefined on this page.

Fi"'re 1.1 PROGRA==ING PERSONA*ITIES

AWARENESS OFREA* WOR*D FACTORS

Other Pro"ra!!in" Perona$itie%

o Co!p'$i&e Pro"ra!!er; lack of purpose and awareness of real world factors.

o Un/ire8te/ Pro"ra!!er; aware of real world factor but no goals.

o 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 P*ANNING

/ plan defines the technical approach the length of the pro1ect and the resources re#uired for theeffort.

9.9.2 4A)ING =ET4ODS

(oncentrating on the #uality of the software7s structure evaluating the structure of data and buildingsoftware according to the format of the output are some methods that help the software engineers.

9.9.9 ORGANI?ING WOR>

Software engineers must be organi4ed so that the other can use the results of one pro1ect activity. =ore!ample identifying ma1or software development activities


Compulsive

Programmer

Serious

Programmer

SOFT!"

#

#$%&$##"

ESTABLISHED

PURPOSE


5/20


6/20


Waterfa$$ =o/e$ A8ti&itie%1. Re@'ire!ent Ana$7i an/ Spe8ifi8ation

System7s services constraints and goals are established by consultation with users.

It should be understandable by both users and development staff.

2. S7te! an/ Software Dei"n

It establishes an overall system architecture.

Involves representing the software system functions in form that may be transformed into one or moree!ecutable programs.

9. I!p$e!entation an/ Unit Tetin"

Software design is reali4ed as a set of programs. :nit testing involves verifying that each unit meets its specifications.

:. Inte"ration an/ S7te! Tetin"

rogram units are integrated and tested as a complete system to ensure that the software re#uirementshave been met.

-. Operation an/ =aintenan8e

'ongest life cycle phase.

Involves correcting errors updating enhancing the system services etc.

Pro($e! of C$ai8 *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 changeduring coding activities the subse#uent changes to design and code are not addressed by the waterfallmodel.

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 workingversion 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 sameob1ectives as an en"ineerin" protot7pe where re#uirements or design re#uire repeated investigation toensure that the developer user and customer have a common understanding both of what is needed andwhat 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 stagerather than at the more costly testing stage.

Fi"'re 1.9 PROTOT+PING =ODE*

Prepared by: ELJUN P. CORTES -


7/20

"e(uirements

%at.ering


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 thecustomers 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 withcustomers and users. The initial design is revised until developers users and customers are happy with theresult.

(onsidering design alternatives reveal a problem with the re#uirements and the developers drop back to there#uirements activities to reconsider and change the re#uirements specification.

System is coded tested and alternatives are discussed with possible iteration through re#uirements anddesign 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

Prepared by: ELJUN P. CORTES /

0&ST OF

"#&S&O$S

0&ST OF

"#&S&O$S

0&ST OF

"#&S&O$S

0&ST OF

"#&S&O$S

P"OTOTP#

"e(uirements

P"OTOTP#

+esign

P"OTOTP#

System

T#ST

System

"evise

Prototype

User

Customerrevie*

System

"e(uirements

+elivered

System

+esign

Strategy

&mplementation

4%0

Testing


8/20


Re@'ire!ent Gatherin".Ideally the customer could actually describe the re#uirements and thesewould be directly translated into an operational prototype. 6owever this is generally unworkable sincethe customer may be unsure of what e!actly is re#uired or introduce a degree of ambiguity in thesere#uirements.

Dei"n Strate"7. &ften for smaller scale software applications it is possible to move directly toimplementation using ?' 2?theneration 'anguage3 but in large scale it is necessary to developdesign strategy. The use of BT with design strategy will not cause difficulties in poor #uality poormaintainability and poor customer acceptance.

I!p$e!entation 'in" :G*. It enables the developer to represent desired results in a manner thatresults in automatic generation of code.

Tetin". +eveloper must conduct through testing develop meaningful documentation and perform allother 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.-.: Tranfor!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*

Prepared by: ELJUN P. CORTES

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

Comparere(uirements5

update

FO",!0

SP#C&F&C!T&O$

T"!$SFO", 1

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

T#ST

System

"e(uirements

+elivered System

Se(uence o) trans)ormation


9/20


Pro($e! on Tranfor!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.



10/20

So)t*are"e(uirements

!nalysis

Prepared by: ELJUN P. CORTES COLLEGE OF COMPUTER STUDIES CSCI15 SOFTWARE ENGINEERING CONCEPTS

Chapter 2REUIRE=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#uirementsanalysis 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 todesign the system. Software re#uirements work products must be reviewed for clarity completeness andconsistency.

II. Re@'ire!ent Ana$7i

Software engineering task that bridges the gap between system level re#uirements engineering and softwaredesign. 2=igure 8.$3

rovides software designer with a representation of system information function and behavior that can betranslated 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$7i a a


11/20


&riginally developed in Dapan and first used at the obe 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$7i; used to determine the relative priority of re#uirements during function information

and task deployment.

2.: Software Re@'ire!entSoftware 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 sufficientlyabstract 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 proposedsoftware to do. It represents an understanding between customer and developer of what thecustomer 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 forthe development of the software design" it is technical counterpart to the re#uirement definitiondocument and it is written by re#uirements analyst.

Si; Chara8teriti8 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 De8ription

Intro/'8tion

G$oar7S7te! =o/e$

F'n8tiona$ Re@'ire!entDefinition

Non6F'n8tiona$Re@'ire!ent Definition

S7te! E&o$'tion

It should briefly describe its functions and e!plain how it will work withother systems. It should describe how the system fits into overallbusiness or strategic ob1ectives of the organi4ation commissioning thesoftware.+efine the technical terms used in the document.This should set out one or more system models showing therelationships 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 notationsthat are understandable by customer.The constraints imposed on the software and restrictions on the freedomof the designer should be described here and related to the functionalre#uirements. Include details of specific data representation responsetime and memory re#uirements and etc.This should describe the functional re#uirements in more detail. Ifnecessary further detail may also be added to the non-functionalre#uirements for e!ample interfaces to other system may be defined.This should describe the functional re#uirements in more detail. If

17


12/20


Re@'ire!ent Spe8ifi8ation

necessary further detail may also be added to the non-functionalre#uirements for e!ample interfaces to other system may be defined.

Chapter 9

REUIRE=ENTS ANA*+SIS =ODE*

III Re@'ire!ent Ana$7i =o/e$

Definition of Re@'ire!ent Ana$7i =o/e$

'eads to a complete specification of re#uirements and a comprehensive design representation for thesoftware to be built.

Set of models that serves as a technical representation of a system.

4itor7 of Re@'ire!ent Ana$7i =o/e$

Early work in analysis modeling begun in the late $FHs 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 age-DonesK/MHL ane and SamsonK/0M8L and many others.

%y mid-$FMHs real-time e!tensions were introduced by ,ard and )ellorK,/*M


13/20


9.9.2 Entit7 Re$ationhip Dia"ra! ,ERD depicts the relationships between data ob1ects.

/ notation that is used to conduct data modeling activity.

ERD


14/20


9.9.9 Data F$ow Dia"ra! provide an identification of how data are transformed as they move through thesystem.

+epicts the functions and subfunctions that transform the data flow.

DFD


15/20


16/20


Fi"'re :.9 Re$ationhip (etween te8hni8a$ an/ !ana"e!ent ape8t of /ei"n

:.9 Data Dei"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 hasalways 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$ Dei"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 betweenmodules.

It combines program structure and data structure thus defining interfaces that will enable data to flow throughout theprogram.

:.- Uer Interfa8e Dei"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 Uer Interfa8e Dei"n Prin8ip$e

)ust take into account the needs e!perience and capabilities of the system user.

a. Uer Fa!i$iarit7; should use terms and concepts which are familiar to the anticipated class of user.b. Coniten87; should be appropriately consistent.c. =ini!a$ 'rprie; user should not be surprised by the system.d. Re8o&era(i$it7 should include some mechanism which allows users to recover from their errors.e. Uer "'i/an8e interface skills incorporate some form of user guidance.

:.-.2 Graphi8a$ Uer Interfa8e

:ser interface which rely on windows iconic representation with entities pull-own or pop-up menus andpointing 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 Chara8teriti8 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

Preliminary Design

Detail Design

+ata +esign

!rc.itectural +esign

Procedural +esign

&nter)ace +esign

,anagement

!spects

Tec.nical!spects


17/20


:.-.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(ae/ interfa8e for a t'/ent re"itration 7te!

:.-.: 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 panelwhich is a graphical representation of system commands.

:.-.:.1 >in/ of entit7 whi8h !a7 (e repreente/ in a 8ontro$ pane$


18/20


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 Dip$a7

(olor is a powerful tool but it is easy to misuse it to produce displays which are error prone and disturbingto 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 Uer G'i/an8e

6elp systems are one facet of a general part of user interface design namely the provisions of userguidance which covers three areas5a. 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$ Dei"n

/lso called component design occurs after data architectural and interface designs have beenestablished.

The ob1ective is to transform structural components into a procedural description of the software.

:.0.1 Pro"ra! Dei"n *an"'a"e ,PD*

/lso called Structured English or pseudocode.

:sed as a generic reference for design language.

E;a!p$e%

+isplay )ain Screen+isplay )enuW N HV N 9*epeat

If 2!X


19/20


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

Fi"'re :.0 F$ow8hart Contr'8t

IF T4EN6E*SE

REPETITION DO W4I*E

REPETITION REPEAT UNTI*

CASE CONDITION

1'

0OOP T!S

condition

#0S#part

T;#$part

+o

.il

e0OOP T!S

T"U# F!0S#

"epeatUntil

F!0S# T"U#

C!S#

Condition

C!S#Conditio

n

T

T

F


20/20


Chapter -SOFTWARE TESTING

Software testing is a critical element of software #uality assurance and represents the ultimate review of specification design code generation.

Tetin" Pro8e

The most widely used testing process consists of five stages as shown in figure

meljun cortes manual software engineering csci15

Documents