software engineering (2005-09)

8/2/2019 Software Engineering (2005-09)

1/88

I N D E X

Sr.No. TOPIC Signature

1. To study software & software engineering. Explains itscharacteristics, goals and principles.

2. To Study The Phase Development Process Of Software

3. To study SRS (Software requirements specification).Explain its need & characteristics.

4. To study DFD and calculate DFD for R.M.S value

5. To study what are the risks. Explain risk managementby different factors

6. To study the term cost estimation. Explain COCOMOmodel.

7. To study software design. Explain its fundamental anddesign methods

8. Study of Software Testing .Explain Testing fundamentaland various Techniques

9. To study the term unit testing, integration testing,validation testing, system testing and debbuging.

10. To study the term Software Maintenance. Explain itscharacteristics and Side effects


2/88

Software EngineeringPRACTICAL FILE

CSE-316 PAGE NO

GOLPURA, BARWALA CSE LAB (SE) 02

Name Roll No. Submitted to:-

EXPERIMENT :1

AIM:To study software & software engineering.Explains its characteristics,goals

and principles.

SOFTWARE:

Software is a general term for the various kinds of program s used to operate computer s

and related devices. (The term hardware describes the physical aspects of computers

and related devices.) A set of computer programs, procedures, and associated

documentation concerned with the operation of a data processing system ; e.g. ,

compilers, library routines, manuals, and circuit diagrams. Information (generally

copyrightable) that may provide instructions for computers; data for documentation; and

voice, video , and music for entertainment or education .Computer instructions or data .

Anything that can be stored electronically is software. The storage devices and display

devices are hardware .

The terms software and hardware are used as both nouns and adjectives. For

example, you can say: "The problem lies in the software," meaning that there is a

problem with the program or data, not with the computer itself. You can also say: "It's a

software problem." The distinction between software and hardware is sometimes

confusing because they are so integrally linked. Clearly, when you purchase a program,

you are buying software. But to buy the software, you need to buy the disk (hardware)

on which the software is recorded.

Software is often divided into two categories:
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci212834,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci212834,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci212834,00.htmlhttp://searchwinit.techtarget.com/sDefinition/0,,sid1_gci211829,00.htmlhttp://searchwinit.techtarget.com/sDefinition/0,,sid1_gci211829,00.htmlhttp://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci212228,00.htmlhttp://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci212228,00.htmlhttp://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci212228,00.htmlhttp://www.its.bldrdoc.gov/fs-1037/dir-033/_4806.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-033/_4806.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-008/_1184.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-008/_1184.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-025/_3691.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-025/_3691.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-010/_1439.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-010/_1439.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-036/_5255.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-036/_5255.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-007/_0963.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-007/_0963.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-019/_2720.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-019/_2720.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-039/_5785.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-039/_5785.htmhttp://www.webopedia.com/TERM/s/computer.htmlhttp://www.webopedia.com/TERM/s/computer.htmlhttp://www.webopedia.com/TERM/s/instruction.htmlhttp://www.webopedia.com/TERM/s/instruction.htmlhttp://www.webopedia.com/TERM/s/instruction.htmlhttp://www.webopedia.com/TERM/s/data.htmlhttp://www.webopedia.com/TERM/s/data.htmlhttp://www.webopedia.com/TERM/s/store.htmlhttp://www.webopedia.com/TERM/s/store.htmlhttp://www.webopedia.com/TERM/s/store.htmlhttp://www.webopedia.com/TERM/s/storage.htmlhttp://www.webopedia.com/TERM/s/storage.htmlhttp://www.webopedia.com/TERM/s/device.htmlhttp://www.webopedia.com/TERM/s/device.htmlhttp://www.webopedia.com/TERM/s/device.htmlhttp://www.webopedia.com/TERM/s/hardware.htmlhttp://www.webopedia.com/TERM/s/hardware.htmlhttp://www.webopedia.com/TERM/s/hardware.htmlhttp://www.webopedia.com/TERM/s/program.htmlhttp://www.webopedia.com/TERM/s/program.htmlhttp://www.webopedia.com/TERM/s/program.htmlhttp://www.webopedia.com/TERM/s/disk.htmlhttp://www.webopedia.com/TERM/s/disk.htmlhttp://www.webopedia.com/TERM/s/disk.htmlhttp://www.webopedia.com/TERM/s/program.htmlhttp://www.webopedia.com/TERM/s/hardware.htmlhttp://www.webopedia.com/TERM/s/device.htmlhttp://www.webopedia.com/TERM/s/storage.htmlhttp://www.webopedia.com/TERM/s/store.htmlhttp://www.webopedia.com/TERM/s/data.htmlhttp://www.webopedia.com/TERM/s/instruction.htmlhttp://www.webopedia.com/TERM/s/computer.htmlhttp://www.its.bldrdoc.gov/fs-1037/dir-039/_5785.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-019/_2720.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-007/_0963.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-036/_5255.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-010/_1439.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-025/_3691.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-008/_1184.htmhttp://www.its.bldrdoc.gov/fs-1037/dir-033/_4806.htmhttp://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci212228,00.htmlhttp://searchwinit.techtarget.com/sDefinition/0,,sid1_gci211829,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci212834,00.html


3/88


CSE-316 PAGE NO



systems software : Includes the operating system and all the utilities that enable the

computer to function.

applications software : Includes programs that do real work for users . For example,

word processors , spreadsheets , and database management systems fall under the

category of applications software.

Figure: Software

PROGRAM

OPERATINGPROCEDURES

DOCUMENTATION
http://www.webopedia.com/TERM/s/systems_software.htmlhttp://www.webopedia.com/TERM/s/systems_software.htmlhttp://www.webopedia.com/TERM/s/operating_system.htmlhttp://www.webopedia.com/TERM/s/operating_system.htmlhttp://www.webopedia.com/TERM/s/utility.htmlhttp://www.webopedia.com/TERM/s/utility.htmlhttp://www.webopedia.com/TERM/s/utility.htmlhttp://www.webopedia.com/TERM/s/software.htm##http://www.webopedia.com/TERM/s/application.htmlhttp://www.webopedia.com/TERM/s/application.htmlhttp://www.webopedia.com/TERM/s/user.htmlhttp://www.webopedia.com/TERM/s/user.htmlhttp://www.webopedia.com/TERM/s/user.htmlhttp://www.webopedia.com/TERM/s/word_processor.htmlhttp://www.webopedia.com/TERM/s/word_processor.htmlhttp://www.webopedia.com/TERM/s/spreadsheet.htmlhttp://www.webopedia.com/TERM/s/spreadsheet.htmlhttp://www.webopedia.com/TERM/s/database_management_system_DBMS.htmlhttp://www.webopedia.com/TERM/s/database_management_system_DBMS.htmlhttp://www.webopedia.com/TERM/s/database_management_system_DBMS.htmlhttp://www.webopedia.com/TERM/s/spreadsheet.htmlhttp://www.webopedia.com/TERM/s/word_processor.htmlhttp://www.webopedia.com/TERM/s/user.htmlhttp://www.webopedia.com/TERM/s/application.htmlhttp://www.webopedia.com/TERM/s/software.htm##http://www.webopedia.com/TERM/s/utility.htmlhttp://www.webopedia.com/TERM/s/operating_system.htmlhttp://www.webopedia.com/TERM/s/systems_software.html


4/88


CSE-316 PAGE NO



Documentation

Specification

Context Diagram

DFD(Data FlowDiagram)

Design

Flowchart

ER Diagrams

Implementation

Source CodeListing

Cross ReferenceListing

Test

Test Data

Test Result

Operating Procedures

User manaul

Operational manaul


5/88


CSE-316 PAGE NO



SOFTWARE ENGINEERING:

Definition 1:" the application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software ".

Definition 2: "an engineering discipline that is concerned with all aspects of software production"

Definition 3: "the establishment and use of sound engineering principles in order to

economically obtain software that is reliable and works efficiently on real machines"

Definition 4: Software Engineering is an approach to developing software that attempts

to treat it as a formal process more like traditional engineering than the craft that many

programmers believe it is .

Definition 5: "Software engineering employs engineering methods, processes,

techniques and measurement."

Software Engineering has come to mean at least two different things in our

industry. First of all the term "software engineer" has generally replaced the term

"programmer". So, in that sense there is a tendency to extrapolate in people's minds

that Software Engineering is merely the act of programming. Secondly, the term

"Software Engineering" has been used to describe "building of software systems whichare so large or so complex that they are built by a team or teams of engineers", as was

used in Fundamentals of Software Engineering by Ghezzi, Jazayeri, and Mandrioli.
http://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Software


6/88


CSE-316 PAGE NO



SOFTWARE VS HARDWARE:

The distinction between hardware and software is artificial. The difference between the

two is only one of scale: hardware works in the world of matter, software works in the

world of energy 1. However, whether you're manipulating atoms, or electrons, you're still

just using the 'rearranging of the physical' as a tool.

This is why it is possible for software and hardware to interact. This is why, when you

press a mechanical key on your keyboard, a 'virtual' character can appear on the

screen. This is why when a 'virtual' trigger is sprung, a physical activity can be initiated

(when a conditional statement is true, the gears in your printer will turn).Hardware and software are not two separate worlds. Rather, they are more like the

ocean and the atmosphere of Earth: two varieties of the same concept. In practical

terms, we think of the ocean as full of something, but of the atmosphere as empty.

Really, we are just swimming in an ocean of air. The ocean and atmosphere are both

fluids; one of water, one of air.

CHARACTERISTICS OF SOFTWARE ENGINEERING:

They are refined into sub-characteristics, until the attributes or measurable properties

are obtained. In this context, metric or measure is a defined as a measurement method

and measurement means to use a metric or measure to assign a value.

In order to monitor and control software quality during the development process, the

external quality requirements are translated or transferred into the requirements of

intermediate products, obtained from development activities. The translation and

selection of the attributes is a non-trivial activity, depending on the stakeholder personalexperience, unless the organization provides an infrastructure to collect and to analyze

previous experience on completed projects. The definition of the main quality

characteristics of the ISO 9126-1 standard for software quality measurement is shown

in Table below. The model should be adapted or customized to the specific application
http://actsofvolition.com/archives/2002/october/archives/2002/october/hardwareandhttp://actsofvolition.com/archives/2002/october/archives/2002/october/hardwareand


7/88


CSE-316 PAGE NO



or product domain. In this sense, for a particular software product we could have a

subset of the six characteristics.

Characteristics Description

Functionality The capability of the software product to provide functionswhich meet stated and implied needs when the softwareis used under specified conditions (what the softwaredoes to fulfil needs)

Reliability The capability of the software product to maintain its levelof performance under stated conditions for a statedperiod of time

Usability The capability of the software product to be understood,learned, used and attractive to the user, when used underspecified conditions (the effort needed for use)

Efficiency The capability of the software product to provideappropriate performance, relative to the amount ofresources used, under stated conditions

Maintainability The capability of the software product to be modified.Modifications may include corrections, improvements oradaptations of the software to changes in theenvironment and in the requirements and functionalspecifications (the effort needed to be modified)


8/88


CSE-316 PAGE NO



Portability The capability of the software product to be transferredfrom one environment to another. The environment mayinclude organizational, hardware or software environment

SOFTWARE ENGINEERING GOALS:

Software Engineering embodies many techniques that could arguably require volumes

to describe. Generally such practices as top-down design, structured programming and

design, pseudocode with iterative refinement, walk-throughs and OOP (Object Oriented

Programming) are considered to be part of this discipline. Many advanced constructs in


9/88


CSE-316 PAGE NO



modern programming languages such as C++ were incorporated to meet the Software

Engineering Goals given below.

All programming projects should begin with functional descriptions which become

the highest level pseudocode. Every module and every routine, high or low level,

should have a functional description approptiate to its level of abstraction.

Functional descriptions determine high level pseudocode should be iteratively

refined to low level pseudocode. The pseudocode becomes internal

documentation.

Pseudocode should be organized into modules, thus ultimately organizing the

project into modules.

Computer code for all routines and main programs should be generated from low

level pseudocode. The pseudocode should become internal documentation.

Module interface specifications should be created so that modules may be

created independently.

Programs should be constructed from modules.

All support routines should reside in separately compiled modules.

Each module should only contain routines whose functions are related.

Inter-module communication should be accomplished solely through passing

parameters. No global variables should be used. Parameters should be passed"by value" where required access is read-only.

Communication between routines in the same module should also only be

accomplished through parameter passing.


10/88


CSE-316 PAGE NO



Low level routines should have simple and explicit functions. For example low

level routines should not do any I/O (especially interaction with the user) unlessthat is the sole function of that routine.

Support routines should be evaluated with respect to flexibility and efficiency.

Include files should be used where required to effect inter-module independence

and consistency. For example data-type definitions should be included to attain

consistent definitions global to all modules.

Changes (such as changes to underlying data structures) in low level routines

should not require source code changes in high level routines. This is

accomplished by carefully constructing the calling interface to adhere to data

abstraction principles.

Changes (such as changes to the driving application) in high level routines

should not require source code changes in low level routines. This is

accomplished by carefully constructing the calling interface to adhere to data

abstraction principles.

Changes to high level routines should not require low level routines to be

recompiled.

Changes to low level routines should not require high level routines to be

recompiled. (This is generally very difficult to achieve.)

Modules should be constructed so that private support routines are not

accessible outside the module. This may be accomplished using submodules or

language-dependent protection mechanisms. Modules should be constructed so that internal data structures can be accessed

only through authorized routines.


11/88


CSE-316 PAGE NO



All program changes should start with a change to the highest level pseudocode

appropriate to that change. This ensures that pseudocode accurately reflects thestructure of the underlying code.

PRINCIPLES OF SOFTWARE ENGINEERING:

make quality number one priority;

high-quality software is possible;

give products to customers early;

determine the problem before writing requirements;

evaluate design alternatives;

use an appropriate process model;

use different languages for different phases;

minimize intellectual distance;

put technique before tools;

get it right before you make it faster;

inspect code;

good management is more important than good technology;


12/88


CSE-316 PAGE NO



EXPERIMENT -2.

AIM :- To Study The Phase Development Process Of Software

Software development is achieved through a collection activities that lead to the

building of a software product. Software development is traditionally divided into various

phases, which we describe briefly in the following sections. For small projects, the

phases are carried out in the order shown; for larger projects, the phases are

interleaved or even applied repetitively with gradually increasing refinement. The strict

definition and organization of these phases is called a software process.

Software development is the way by which we produce software according to the

requirements.

software specification : The functioning of software & its constraints on its operaton

must be defined

software development: software must be developed that needs the specification.

software validation : software must be validated to ensure that it performs what the

customer need .

software evaluation : software must be evolved to meet changes according tocustomer.

Study of various software development phases:

Software

specification

Software

development

Software

validation

Software

evaluation


13/88


CSE-316 PAGE NO



The different phases starting from the feasibility study to the integration & system

testing phase are known as the development phases.

The life cycle is broken down into an intuitive set of phases. The different phases are :

feasibility study, requirements analyses and specifications, design, coding and unit

testing, integration & system testing, & maintenance.

Feasibility study

Requirements analysis

and specifications

Design

Coding and

Unit testing

Integration and

System testing

Maintenance


14/88


CSE-316 PAGE NO



Each phase of the life cycle has well-defined starting & ending criteria which typically

need to be documented in the form of text description. So it is known when to stop andstart a phase. Good software development organizations normally document all the

information regarding the outputs to be produced at the end of different phases.

FEASIBILITY STUDY:

The main aim of this activity is to determine whether it would be financially and

technically feasible to develop the product. The feasibility study activity involves the

analysis of the

problem and collecting the relevant information regarding the product. The collected

data are analyzed to arrive at the following:

An abstract problem definition which is a rough description of the problem

which considers only the imp. Requirements and ignores the rest.

Formulation of the different solution strategies.

Analysis of alternative solution strategies to compare their benefits and

shortcomings. This usually requires making approximate estimates of the

resources required, cost of development, and development time for each of

the options. Once the best solution is identified, all the later phases of

development are carried out as per this solution. Therefore during feasibility

study it may come to light that none o the solution is feasible due to high cost

and some technical reasons.


15/88


CSE-316 PAGE NO



REQUIREMENTS ANALYSIS AND SPECIFICATION:

The goal of this phase is to understand the exact requirements of customer and to

document them properly. This activity is usually executed together with the

customer. As the goal is to documents all function performance and interfacing

requirement for the software. The requirements describe the what of system this

phase produce a large document contains a description of what the system will do

without describing how it will be done. The resultant document is known as software

requirement specification document. The SRS documents may acts as contract

between developer and customer.

The customer requirements identified during the requirements gathering and

analysis activity are organized into SRS document. The imp. Components are the

functional and non-functional requirements, and the goals of implementation. The

SRS document is written using the end-user terminology which makes the document

understandable by the customer.

DESIGN:

The goal of design phase is to transform the requirements specified in the SRS

document into a structure that is suitable for implementation in some programming

language. Here overall S/W architecture is defined and the high level and detail

design work is performed. This work is documented and known as the software

design description document.

CODING AND UNIT TESTING:


16/88


CSE-316 PAGE NO



During this phase design is implemented if the SDD is complete. The

implementation proceeds smoothly because all the information is needed by S/Wdeveloper is contained in SDD.

A coding standard addresses issues such as the standard ways of

laying out the program codes, the template for laying out the function and module

headers, commenting guidelines, the maximum no. of source lines permitted in each

module.

During this phase, each module is unit tested to determine the correct working of all

individual modules. It involves testing each module in isolation as this is most

efficient way to debug the errors identified at this stage. Unit testing also involves a

precise definition of test cases, testing criteria, and management of test cases.

INTEGRATION AND SYSTEM TESTING :

This is very important phase. Effective testing will contribute to the delivery of higher

quality S/W product is more satisfied users lower maintenance cost and more accurate

and very expensive.

Integration is normally carried out incrementally over a number of steps. During each

integration step, the partially integrated system is tested and a set of previously planned

modules are added to it. Finally, when all the modules have been successfully

integrated and tested, system testing is carried out. After the requirements specification

phase, a system test plan can be prepared which documents the plan for system

testing.


17/88


CSE-316 PAGE NO



MAINTENANCE:

Software maintenance is a task that every development group has to face when the

S/W is delivered to customers site installed and is operational. S/W maintenance is

very broad activity that includes error correction enhancement of capability, and

optimization

Maintenance of a typical software product requires much more effort than the effort

necessary to develop the product itself. Maintenance involves performing any one or

more of the following three kinds of activities.

Corrective maintenance: correcting errors that were not discovered during the

product development phase.

Perfective maintenance: improving the implementation of the system, and

enhancing the functionalities of the system according to the customers

requirements.

Adaptive maintenance: porting the software to work in a new environment.


18/88


CSE-316 PAGE NO



EXPERIMENT:-3

Aim:- To study software requirement and specification. Explain the needs, goalsand characteristics of SRS.

Software Requirements Specification (SRS )

An SRS is basically an organization's understanding (in wri ting) of a customer or

potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurancepolicy that assures that both the client and the organization understand the othersrequirements from that perspective at a given point intimae.

The SRS document itself states in precise and explicit language those functionsand capabilities a software system(i.e., a software application, an eCommerce Web site,and soon) must provide, as well as states any required constraints by which the systemmust abide. The SRS also functions as blueprint for completing a project with as littlecost growths possible. The SRS is often referredthe"parent"document because allsubsequent project management documents, such as design specifications, statementsof work, software architecture specifications, testingand validation plans, anddocumentation plans, are related to it. Its important to note that an SRS containsfunctional and nonfunctional requirements only; it doesn't offer design suggestions,possible solutions to technology or business issues, or any other information other thanwhat the development team understands the customers system requirements to be.

Requirement Gathering:-

Requirement gathering is usually the first part of any software product. This stagestarts when you are thinking about developing software. In this phase, you meetcustomers or prospective customers, analyzing market requirements and features that


19/88


CSE-316 PAGE NO



are in demand. You also find out if there is a real need in the market for the softwareproduct you are trying to develop. In this stage, marketing and sales people or peoplewho have direct contact with the customers do most of the work. These people talk tothese customers and try to understand what they need. A

comprehensive understanding of the customers n eeds and writing down features of theproposed software product are the keys to success in this phase. This phase is actuallya base for the whole development effort. If the base is not laid correctly, the product willnot find a place in the market. If you develop a very good software product which is notrequired in the market, it does not matter how well you build it. You can find manystories about software products that failed in the market because the customers did notrequire them.

Requirement Analysis:-

Requirement analysis is basically an organization's understanding (in writing) of acustomer or potential client's system requirements prior to any actual design ordevelopment work. Good requirement analysis practices reduce project risk and helpthe project running smoothly.

Having seen so many projects delivered, we understand how to do the projectrequirement analysis to provide better outcome of the project. Link provides therequirement analysis document for the representation of the softw are for the customersreview and approval. We will help you identify your problems even if you dont knowclearly what you really want.


20/88


CSE-316 PAGE NO



From the above diagram, analyst is the technical person. Scoping contains theBusiness entities, stake holders and actors. Stake holders and actors are businessdecision makers and influencers. Influencers will interconnect the client and the serviceprovider like iLink. The Requirement analysis document contains both functional andnon-functional requirements.

Non-Functional requirements are usability, scalability, extensibility, performance,security and maintainability. They are all very important for a project but not non-functional requirements.

Tools of requirement Analysis:-
http://www.ilink-systems.com/http://www.ilink-systems.com/http://www.ilink-systems.com/http://www.ilink-systems.com/http://www.ilink-systems.com/http://www.ilink-systems.com/


21/88


CSE-316 PAGE NO



1. Data flow diagram(DFD)2. Data dictionary(DD)3. Entity-Relationship diagrams (E-R diagrams).

Software Requirements Specification

There are many good definitions of System and Software Req uirements Specifications

that will provide us a good basis upon which we can both define a great specificationand help us identify deficiencies in our past efforts. There is also a lot of great stuff onthe web about writing good specifications. The problem is not lack of knowledge abouthow to create a correctly formatted specification or even what should go into thespecification. The problem is that we don't follow the definitions out there.

We have to keep in mind that the goal is not to create great specifications but to creategreat products and great software. Can you create a great product without a greatspecification? Absolutely! You can also make your first million through the lottery butwhy take your chances? Systems and software these days are so complex that to

embark on the design before knowing what you are going to build is foolish and risky.

Needs of a SRS:-

Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to beperformed by the software specified in the SRS will assist the potential users to

determine if the software specified meets their needs or how the software must bemodified to meet their needs. [NOTE: We use it as the basis of our contract with ourclients all the time].

Reduce the development effort. The preparation of the SRS forces the variousconcerned groups in the customers organization to consider rigorously all of therequirements before design begins and reduces later redesign, recoding, and retesting.


22/88


CSE-316 PAGE NO



Careful review of the requirements in the SRS can reveal omissions,misunderstandings, and inconsistencies early in the development cycle when theseproblems are easier to correct.

Provide a basis for estimating costs and schedules. The description of the productto be developed as given in the SRS is a realistic basis for estimating project costs andcan be used to obtain approval for bids or price estimates. [NOTE: Again, we use theSRS as the basis for our fixed price estimates]

Provide a baseline for validation and verification. Organizations can develop theirvalidation and Verification plans much more productively from a good SRS. As a part of

the development contract, the SRS provides a baseline against which compliance canbe measured. [NOTE: We use the SRS to create the Test Plan].

Characteristics of a SRS:-

a) Correct

b) Unambiguous

c) Complete

d) Consistent

e) Ranked for importance and/or stability

f) Verifiable

g) Modifiable

h) Traceable

Correct - This is like motherhood and apple pie. Of course you want the specification tobe correct. No one writes a specification that they know is incorrect. We like to say -"Correct and ever correcting." The discipline is keeping the specification up to datewhen you find things that are not correct.


23/88


CSE-316 PAGE NO



Unambiguous - An SRS is unambiguous if, and only if, every requirement statedtherein has only one interpretation. Again, easier said than done. Spending time on thisarea prior to releasing the SRS can be a waste of time. But as you find ambiguities - fixthem.

Complete - A simple judge of this is that is should be all that is nee ded by the softwaredesigners to create the software.

Consistent - The SRS should be consistent within itself and consistent to its reference

documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" inanother.

Ranked for Importance - Very often a new system has requirements that are reallymarketing wish lists. Some may not be achievable. It is useful provide this information inthe SRS .

Verifiable - Don't put in requirements like - "It should provide the user a fast response."Another of my favorites is - "The system should never crash." Instead, provide aquantitative requirement like: "Every key stroke should provide a user response within100 milliseconds."

Modifiable - Having the same requirement in more than one place may not be wrong -but tends to make the document not maintainable .

Traceable - Often, this is not important in a non-politicized environment. However, inmost organizations, it is sometimes useful to connect the requirements in the SRS to ahigher level document. Why do we need this requirement?


24/88


CSE-316 PAGE NO



Goals of SRS:-

Awell-designed,well-writtenSRSaccomplishesfourmajorgoals:

1. It provides feedback to the customer. An SRS is thecustomer's assurance thatthe development organizationunderstands the issues or problems to be solvedand thesoftware behavior necessary to address those problems.Therefore, theSRS should be written in natural language(versus a formal language, explainedlater in thisarticle), in an unambiguous manner that may also includecharts,

tables, data flow diagrams, decision tables, and soon.

2. It decomposes the problem into component parts. Thesimple act of writingdown software requirements in awell-designed format organizes information,places bordersaround the problem, solidifies ideas, and helps break downtheproblem intoits component parts in an orderlyfashion.

3. It serves as an input to the design specification. Asmentioned previously, theSRS serves as the parent documentto subsequent documents, such as thesoftware designspecification and statement of work. Therefore, the SRSmust contain sufficientdetail in the functional systemrequirements so that a design solution can bedevised.

4. It serves as a product validation check. The SRS alsoserves as the parentdocument for testing and validationstrategies that willbapplietotherequirementsforverification.


25/88


CSE-316 PAGE NO



EXPERIMENT-4

AIM- To study DFD and draw dfd to calculate rms value.

Data Flow Diagram(DFD):-

A data flow diagram (DFD) is a graphical representation of the "flow" of data throughan information system. A data flow diagram can also be used for the visualization ofdata processing (structured design). It is common practice for a designer to draw acontext-level DFD first which shows the interaction between the system and outsideentities. This context-level DFD is then "exploded" to show more detail of the system

being modeled.

It is also known as Bubble Chart

. Data flow diagrams (DFDs) are one of the three essential perspectives of StructuredSystems Analysis and Design Method. The sponsor of a project and the end users willneed to be briefed and consulted throughout all stages of a system's evolution. With adataflow diagram, users are able to visualize how the system will operate, what thesystem will accomplish, and how the system will be implemented. The old system'sdataflow diagrams can be drawn up and compared with the new system's dataflowdiagrams to draw comparisons to implement a more efficient system. Dataflow

diagrams can be used to provide the end user with a physical idea of where the datathey input ultimately has an effect upon the structure of the whole system from order todispatch to restock how any system is developed can be determined through a dataflowdiagram.

Developing a DFD helps in identifying the transaction data in the data model.

Top-Down Approach

1. The system designer makes a context level DFD, which shows the interaction(data flows) between the system (represented by one process) and the system

environment (represented by terminators).2. The system is decomposed in lower level DFD (Zero) into a set of processes,data stores, and the data flows between these processes and data stores.

3. Each process is then decomposed into an even lower level diagram containingits subprocesses.

4. This approach then continues on the subsequent subprocesses, until anecessary and sufficient level of detail is reached which is called the primitiveprocess (aka chewable in one bite).
http://en.wikipedia.org/wiki/Information_systemhttp://en.wikipedia.org/wiki/Visualizationhttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/System_context_diagramhttp://en.wikipedia.org/wiki/Transaction_datahttp://en.wikipedia.org/wiki/Data_modelhttp://en.wikipedia.org/wiki/Data_modelhttp://en.wikipedia.org/wiki/Transaction_datahttp://en.wikipedia.org/wiki/System_context_diagramhttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/Visualizationhttp://en.wikipedia.org/wiki/Information_system


26/88


CSE-316 PAGE NO



Roll. No-2205218

Purpose/Objective:

The purpose of data flow diagrams is to provide a semantic bridge between users andsystems developers. The diagrams are:

graphical, eliminating thousands of words; logical representations, modeling WHAT a system does, rather than physical

models showing HOW it does it; hierarchical, showing systems at any level of detail; and jargon less, allowing user understanding and reviewing.

The goal of data flow diagramming is to have a commonly understood model of asystem. The diagrams are the basis of structured systems analysis. Data flow diagramsare supported by other techniques of structured systems analysis such as data structured iagrams, data dictionaries, and procedure-representing techniques such as decisiontables, decision trees, and structured English.

Data flow diagrams have the objective of avoiding the cost of:

user/developer misunderstanding of a system, resulting in a need to redosystems or in not using the system.

having to start documentation from scratch when the physical system changessince the logical system, WHAT gets done, often remains the same whentechnology changes.

systems inefficiencies because a system gets "computerized" before it gets"systematized".

being unable to evaluate system project boundaries or degree of automation,resulting in a project of inappropriate scope.


27/88


CSE-316 PAGE NO



Symbols of DFD

Diagram element Graphical presentation

Process

External Entity

Data Store

Data Flow

There are essentially four different types of symbols used to construct DFDs. Theseprimitive symbols are depicted in fig. 1. The meaning of each symbol is explainedbelow:

Function symbol. This symbol is called a process or a bubble. Bubbles are annotatedwith the names of the corresponding functions.


28/88


CSE-316 PAGE NO



External entity symbols . A rectangle represents an external entity such as a librarian,a library member, etc. The external entities are essentially those physical entities whichare external to the software system and interact with the system by inputting data to thesystem or by consuming the data produced by the system.

Data Flow Symbol. A directed arc or an arrow is used as a data flow symbol. A dataflow symbol represents the data flow occurring between two processes or between anexternal entity and a process in the direction of the data flow arrow. Data flow symbolsare usually annotated with the corresponding data names.

Data store symbol . Open boxes are used to represent data stores. A data storerepresents a logical file, a data structure or a physical file on disk.

How to draw the DFD :-

1. Identify all the external entities which act as sources or sinks for the system.2. Draw a toplevel, single process, dataflow diagram which shows the above

external entities.

3. The context diagram is refined by decomposing the single process into severalmore, maintaining the dataflows with the external enitites.4. Repeat the above step for each diagram produced.5. Starting from the sources, ask "What process needs this input?"6. Draw that process, then ask, "What output does this process produce?" This will

give a clue as to the next processes in the chain.7. Repeat the first question to give the identity of the next process. Connect the

processes by a dataflow.8. Make chains in the graph. Use the previous questions to produce some chains,

the common links (processes, flows and entities) in the chain can then becollapsed to produce a directed graph.

9. Do Not draw a single layer with more than approximately 5-7 processes.10. DO Not connect a source directly to a sink

DFD Principles

The general principle in Data Flow Diagramming is that a system can bedecomposed into subsystems, and subsystems can be decomposed into lowerlevel subsystems, and so on.


29/88


CSE-316 PAGE NO



Each subsystem represents a process or activity in which data is processed. Atthe lowest level, processes can no longer be decomposed.

Each 'process' (and from now on, by 'process' we mean subsystem and activity)in a DFD has the characteristics of a system.

Just as a system must have input and output (if it is not dead), so a process musthave input and output.

Data enters the system from the environment; data flows between processeswithin the system; and data is produced as output from the system

Leveling of the DFD :-

Context Diagram (Level 0 DFD) :-

The context diagram is the most abstract data flow representation of a system. It

represents the entire system as a single bubble. This bubble is labeled acc to the main

function of the system. The various external entities with whi9ch the system interacts

and the data flows occurring between the system and the external entities are also

represented. The data input to the system and the data output from the system are

represented as incoming and outgoing arrows. These data flow arrows should be

annotated with the corresponding data names. The name context diagram is well

justified because it represents the context in which the system is to exist, i.e. the

external entities (users) who would interact with the system and the specific data itemsthey would be supplying to the system and the data items they would be receiving fromthe system. The context diagram is also called the level 0 DFD.

To develop the context diagram of the system, we have to analyze the SRS

document to identify the different types of users who would be using the system and thekinds of data they would be inputting to the system and the data they would be receivingfrom the system. Here, the term users of the system also includes the external systemswhich supply data to or receive data from the system.

The bubble in the context diagram is annotated with the name of the software

system being developed (usually a noun). This is in contrast with the bubbles in all other


30/88


CSE-316 PAGE NO



levels which ar4e annotated with verbs. This is to expect since the purpose of the

context diagram is to expected since the purpose of the context diagram is to capture

the context of the system rather than its functionality.

Level 1 DFD :-

To develop the level 1 DFD, examine the high-level functional requirements. Ifthere are between three to seven high-level functional requirements, then these can bedirectly represented as bubbles in the level 1 DFD. We can then examine the input datato these functions and the data output by these functions and represent themappropriately in the diagram.

If a system has more than seven high-level requirements, then some of therelated requirements have to be combined and represented in the form of a bubble inthe level 1 DFD. These can be split in the lower DFD levels. If a system has less thanthree high-level functional requirements, then some of the high-level requirements needto be split into their sub functions so that we have roughly about five to seven bubbleson the diagram.

DFD for the RMS value :-


31/88


CSE-316 PAGE NO




32/88


33/88


CSE-316 PAGE NO



STEPS IN RISK MANAGEMENT PROCESS

ESTABLISH THE TEXT

1. Planning the remainder of the process.2. Mapping out the following: the scope of the exercise, the identity and

objectives of stakeholders, and the basis upon which risks will beevaluated.

3. Defining a framework for the process and an agenda for identification. 4. Developing an analysis of risk involved in the process

RISK IDENTIFICATION

After establishing the context, the next step in the process of managing risk is toidentify potential risks. Risks are about events that, when triggered, causeproblems. Hence, risk identification can start with the source of problems, or withthe problem itself.

Risk

Identification

Risk Risk Risk

Monitorin

List of potentialrisks

Prioritized Risk avoidance &contingency plans

Risk


34/88


CSE-316 PAGE NO



Source analysis Risk sources may be internal or external to the systemthat is the target of risk management. Examples of risk sources are:stakeholders of a project, employees of a company or the weather over anairport.

Problem analysis Risks are related to identify threats. For example: thethreat of losing money, the threat of abuse of privacy information or thethreat of accidents and casualties. The threats may exist with variousentities, most important with shareholder, customers and legislative bodiessuch as the government.

When either source or problem is known, the events that a source may trigger or

the events that can lead to a problem can be investigated. For example:stakeholders withdrawing during a project may endanger funding of the project;privacy information may be stolen by employees even within a closed network;lightning striking a Boeing 747 during takeoff may make all people onboardimmediate casualties.

The chosen method of identifying risks may depend on culture, industry practiceand compliance. The identification methods are formed by templates or the

development of templates for identifying source, problem or event. Common riskidentification methods are:

Objectives-based risk identification Organizations and project teamshave objectives. Any event that may endanger achieving an objectivepartly or completely is identified as risk. Objective-based risk identificationis at the basis of COSO's Enterprise Risk Management - IntegratedFramework

Scenario-based risk identification In scenario analysis different

scenarios are created. The scenarios may be the alternative ways toachieve an objective, or an analysis of the interaction of forces in, forexample, a market or battle. Any event that triggers an undesired scenarioalternative is identified as risk - see Futures Studies for methodology usedby Futurists.

Taxonomy-based risk identification The taxonomy in taxonomy-basedrisk identification is a breakdown of possible risk sources. Based on thetaxonomy and knowledge of best practices, a questionnaire is compiled.


35/88


CSE-316 PAGE NO



The answers to the questions reveal risks. Taxonomy-based risk

identification in software industry can be found in CMU/SEI-93-TR-6. Common-risk Checking In several industries lists with known risks are

available. Each risk in the list can be checked for application to a particularsituation. An example of known risks in the software industry is theCommon Vulnerability and Exposures list found at http://cve.mitre.org.

Risk Charting This method combines the above approaches by listingResources at risk, Threats to those resources Modifying Factors whichmay increase or reduce the risk and Consequences it is wished to avoid.Creating a matrix under these headings enables a variety of approaches.One can begin with resources and consider the threats they are exposedto and the consequences of each. Alternatively one can start with thethreats and examine which resources they would affect, or one can beginwith the consequences and determine which combination of threats andresources would be involved to bring them about

Categories of risks:

Schedule Risk: Project schedule get slip when project tasks and schedule release risks are notaddressed properly.Schedule risks mainly affect on project and finally on company economy andmay lead to project failure.Schedules often slip due to following reasons:

Wrong time estimation Resources are not tracked properly. All resources like staff, systems, skills ofindividuals etc.

Failure to identify complex functionalities and time required to develop thosefunctionalities.

Unexpected project scope expansions.

Budget Risk:

Wrong budget estimation. Cost overruns Project scope expansion

Operational Risks: Risks of loss due to improper process implementation, failed system or some


36/88


CSE-316 PAGE NO



external events risks.

Causes of Operational risks:

Failure to address priority conflicts Failure to resolve the responsibilities Insufficient resources No proper subject training No resource planning No communication in team.

Technical risks: Technical risks generally leads to failure of functionality and performance.Causes

of technical risks are:

Continuous changing requirements No advanced technology available or the existing technology is in initial stages. Product is complex to implement. Difficult project modules integration.

Programmatic Risks: These are the external risks beyond the operational limits. These are alluncertain risks are outside the control of the program.These external events can be:

Running out of fund. Market development Changing customer product strategy and priority Government rule changes.

Project risk

In the advanced capital budgeting topics, the total risk associated with aninvestment project. Sometimes referred to as stand-alone project risk. Inadvanced capital budgeting, project risk is partitioned into systematic and un-

systematic project risk.

Business risk

The uncertainty associated with a business firm's operating environment andreflected in the variability of earnings before interest and taxes (EBIT). Since thisearnings measure has not had financing expenses removed, it reflect the risk


37/88


CSE-316 PAGE NO



associated with business operations rather than methods of debt financing. This

risk is often discussed in General Business Management courses.

RISK ASSESSMENT

Once risks have been identified, they must then be assessed as to their potentialseverity of loss and to the probability of occurrence. These quantities can beeither simple to measure, in the case of the value of a lost building, or impossible

to know for sure in the case of the probability of an unlikely event occurring.Therefore, in the assessment process it is critical to make the best educatedguesses possible in order to properly prioritize the implementation of the riskmanagement plan.

The fundamental difficulty in risk assessment is determining the rate ofoccurrence since statistical information is not available on all kinds of pastincidents. Furthermore, evaluating the severity of the consequences (impact) is

often quite difficult for immaterial assets. Asset valuation is another question thatneeds to be addressed. Thus, best educated opinions and available statistics arethe primary sources of information. Nevertheless, risk assessment shouldproduce such information for the management of the organization that theprimary risks are easy to understand and that the risk management decisionsmay be prioritized. Thus, there have been several theories and attempts toquantify risks. Numerous different risk formulae exist, but perhaps the mostwidely accepted formula for risk quantification is:

Rate of occurrence X the impact of the event = risk

Later research has shown that the financial benefits of risk management are lessdependent on the formula used but are more dependent on the frequency andhow risk assessment is performed.


38/88


CSE-316 PAGE NO



In business it is imperative to be able to present the findings of risk assessmentsin financial terms. Robert Courtney Jr. (IBM, 1970) proposed a formula forpresenting risks in financial terms. The Courtney formula was accepted as theofficial risk analysis method for the US governmental agencies. The formulaproposes calculation of ALE (annualised loss expectancy) and compares theexpected loss value to the security control implementation costs (cost-benefitanalysis).

POTENTIAL RISK TREATMENTS

Once risks have been identified and assessed, all techniques to manage the riskfall into one or more of these four major categories: (Dorfman, 1997)

Tolerate (aka retention)Treat (aka mitigation)Terminate (aka elimination)Transfer (aka buying insurance)

Ideal use of these strategies may not be possible. Some of them may involvetrade-offs that are not acceptable to the organization or person making the riskmanagement decisions.

RISK AVOIDANCE

This includes not performing an activity that could carry risk. An example wouldbe not buying a property or business in order to not take on the liability thatcomes with it. Another would be not flying in order to not take the risk that theairplane were to be hijacked. Avoidance may seem the answer to all risks, but


39/88


CSE-316 PAGE NO



avoiding risks also means losing out on the potential gain that accepting

(retaining) the risk may have allowed. Not entering a business to avoid the risk ofloss also avoids the possibility of earning profits.

RISK REDUCTION

Involves methods that reduce the severity of the loss. Examples includesprinklers designed to put out a fire to reduce the risk of loss by fire. This methodmay cause a greater loss by water damage and therefore may not be suitable.Halon fire suppression systems may mitigate that risk, but the cost may beprohibitive as a strategy.

Modern software development methodologies reduce risk by developing anddelivering software incrementally. Early methodologies suffered from the fact thatthey only delivered software in the final phase of development; any problemsencountered in earlier phases meant costly rework and often jeopardized thewhole project. By developing in iterations, software projects can limit effortwasted to a single iteration. A current trend in software development,

spearheaded by the Extreme Programming community, is to reduce the size ofiterations to the smallest size possible, sometimes as little as one week isallocated to an iteration.

RISK RETENTION

Involves accepting the loss when it occurs. True self insurance falls in this

category. Risk retention is a viable strategy for small risks where the cost ofinsuring against the risk would be greater over time than the total lossessustained. All risks that are not avoided or transferred are retained by default.This includes risks that are so large or catastrophic that they either cannot beinsured against or the premiums would be infeasible. War is an example sincemost property and risks are not insured against war, so the loss attributed by waris retained by the insured. Also any amounts of potential loss (risk) over the


40/88


CSE-316 PAGE NO



amount insured are retained risk. This may also be acceptable if the chance of a

very large loss is small or if the cost to insure for greater coverage amounts is sogreat it would hinder the goals of the organization too much.

RISK TRANSFER

Means causing another party to accept the risk, typically by contract or byhedging. Insurance is one type of risk transfer that uses contracts. Other times it

may involve contract language that transfers a risk to another party without thepayment of an insurance premium. Liability among construction or othercontractors is very often transferred this way. On the other hand, taking offsettingpositions in derivatives is typically how firms use hedging to financially managerisk.

Some ways of managing risk fall into multiple categories. Risk retention pools aretechnically retaining the risk for the group, but spreading it over the whole group

involves transfer among individual members of the group. This is different fromtraditional insurance, in that no premium is exchanged between members of thegroup up front, but instead losses are assessed to all members of the group.

CREATE THE PLAN

Decide on the combination of methods to be used for each risk. Each riskmanagement decision should be recorded and approved by the appropriate levelof management. For example, a risk concerning the image of the organizationshould have top management decision behind it whereas IT management wouldhave the authority to decide on computer virus risks.


41/88


CSE-316 PAGE NO



The risk management plan should propose applicable and effective security

controls for managing the risks. For example, an observed high risk of computerviruses could be mitigated by acquiring and implementing anti virus software. Agood risk management plan should contain a schedule for control implementationand responsible persons for those actions.

According to ISO/IEC 27001, the stage immediately after completion of the RiskAssessment phase consists of preparing a Risk Treatment Plan, which shoulddocument the decisions about how each of the identified risks should be handled.

Mitigation of risks often means selection of Security Controls, which should bedocumented in a Statement of Applicability, which identifies which particularcontrol objectives and controls from the standard have been selected, and why.

IMPLEMENTATION

Follow all of the planned methods for mitigating the effect of the risks. Purchase

insurance policies for the risks that have been decided to be transferred to aninsurer, avoid all risks that can be avoided without sacrificing the entity's goals,reduce others, and retain the rest.

REVIEW AND EVALUATION OF THE PLAN

Initial risk management plans will never be perfect. Practice, experience, andactual loss results will necessitate changes in the plan and contribute informationto allow possible different decisions to be made in dealing with the risks beingfaced.

Risk analysis results and management plans should be updated periodically.There are two primary reasons for this:


42/88


CSE-316 PAGE NO



1. to evaluate whether the previously selected security controls are stillapplicable and effective, and

2. to evaluate the possible risk level changes in the business environment.For example, information risks are a good example of rapidly changingbusiness environment

Limitations

If risks are improperly assessed and prioritized, time can be wasted in dealing

with risk of losses that are not likely to occur. Spending too much time assessingand managing unlikely risks can divert resources that could be used moreprofitably. Unlikely events do occur but if the risk is unlikely enough to occur itmay be better to simply retain the risk and deal with the result if the loss does infact occur.

Prioritizing too highly the risk management processes could keep an organizationfrom ever completing a project or even getting started. This is especially true ifother work is suspended until the risk management process is consideredcomplete.

It is also important to keep in mind the distinction between risk and uncertainty. Risk can be measured by impacts x probability.
http://en.wikipedia.org/wiki/Riskhttp://en.wikipedia.org/wiki/Uncertaintyhttp://en.wikipedia.org/wiki/Uncertaintyhttp://en.wikipedia.org/wiki/Risk


43/88


CSE-316 PAGE NO



Experiment-6

AIM : To Study the term cost estimation explain COCOMO MODEL.

Introduction

Software cost estimation is the process of predicting the amount of effort requiredto build a software system. Cost estimates are needed throughout the softwarelifecycle. Preliminary estimates are required to determine the feasibility of aproject. Detailed estimates are needed to assist with project planning. The actualeffort for individual tasks is compared with estimated and planned values,enabling project managers to reallocate resources when necessary.

Analysis of historical project data indicates that cost trends can be correlated withcertain measurable parameters. This observation has resulted in a wide range ofmodels that can be used to assess, predict, and control software costs on a real-time basis. Models provide one or more mathematical algorithms that computecost as a function of a number of variables.

Size

Size is a primary cost factor in most models. There are two common ways tomeasure software size: lines of code and function points .

Lines of Code

The most commonly used measure of source code program length is the numberof lines of code (LOC) (Fenton, 1997). The abbreviation NCLOC is used torepresent a non-commented source line of code. NCLOC is also sometimesreferred to as effective lines of code (ELOC). NCLOC is therefore a measure ofthe uncommented length.

The commented length is also a valid measure, depending on whether or not linedocumentation is considered to be a part of programming effort. The abbreviationCLOC is used to represent a commented source line of code (Fenton, 1997).

By measuring NCLOC and CLOC separately we can define:

total length (LOC) = NCLOC + CLOC


44/88


CSE-316 PAGE NO



KLOC is used to denote thousands of lines of code.

Function Points

Function points (FP) measure size in terms of the amount of functionality in asystem. Function points are computed by first calculating an unadjusted function point count (UFC). Counts are made for the following categories (Fenton, 1997):

External inputs those items provided by the user that describe distinctapplication-oriented data (such as file names and menu selections)

External outputs those items provided to the user that generate distinctapplication-oriented data (such as reports and messages, rather than theindividual components of these)

External inquiries interactive inputs requiring a response External files machine-readable interfaces to other systems Internal files logical master files in the system

THE COCOMO MODEL

A number of algorithmic models have been proposed as the basis for estimatingthe effort, schedule and costs of a software project. These are conceptuallysimilar but use different parameter values.

In 1981, Barry Boehm designed COCOMO to give an estimate of the number ofman-months it will take to develop a software product.

References to this model typically call it COCOMO 81 . In 1990, a new modelcalled COCOMO II appeared. Generally, references to COCOMO before 1995refer to the original COCOMO model, references after 1995 refer to COCOMO II.The need for the new model came as software development technology moved

from mainframe and overnight batch processing to desktop development, codereusability and the use of off-the-shelf software components.

This " COnstructive COst MOdel " drew on a study of about sixty projects atTRW, a Californian automotive and IT company, that Northrop Grummanacquired in late 2002. The study examined programs ranging in size from 2000 to100,000 lines of code, and programming languages ranging from assembly toPL/I.
http://en.wikipedia.org/wiki/Barry_Boehmhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Computer_softwarehttp://en.wikipedia.org/wiki/TRWhttp://en.wikipedia.org/wiki/Northrop_Grummanhttp://en.wikipedia.org/wiki/Lines_of_codehttp://en.wikipedia.org/wiki/Assemblyhttp://en.wikipedia.org/wiki/PL/Ihttp://en.wikipedia.org/wiki/PL/Ihttp://en.wikipedia.org/wiki/Assemblyhttp://en.wikipedia.org/wiki/Lines_of_codehttp://en.wikipedia.org/wiki/Northrop_Grummanhttp://en.wikipedia.org/wiki/TRWhttp://en.wikipedia.org/wiki/Computer_softwarehttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Barry_Boehm


45/88


CSE-316 PAGE NO



COCOMO consists of a hierarchy of three increasingly detailed and accurateforms.

Basic COCOMO - is a static, single-valued model that computes softwaredevelopment effort (and cost) as a function of program size expressed inestimated lines of code.

Intermediate COCOMO - computes software development effort asfunction of program size and a set of "cost drivers" that include subjectiveassessment of product, hardware, personnel and project attributes.

Detailed COCOMO - incorporates all characteristics of the intermediateversion with an assessment of the cost driver's impact on each step(analysis, design, etc.) of the software engineering process.

Basic cocomo

Basic COCOMO is a form of the COCOMO model. COCOMO applies to threeclasses of software projects:

Organic projects - are relatively small, simple software projects in whichsmall teams with good application experience work to a set of less thanrigid requirements.

Semi-detached projects - are intermediate (in size and complexity)software projects in which teams with mixed experience levels must meeta mix of rigid and less than rigid requirements.

Embedded projects - are software projects that must be developed withina set of tight hardware, software, and operational constraints.

The basic COCOMO equations take the form

E=a b(KLOC) b b

D=c b(E)db

P=E/D

where E is the effort applied in person-months, D is the development time inchronological months, KLOC is the estimated number of delivered lines of codefor the project (expressed in thousands), and P is the number of people required.The coefficients a b , b b , c b and d b are given in the following table.


46/88


CSE-316 PAGE NO



Software project a b b b c b d b

Organic 2.4 1.05 2.5 0.38Semi-detached 3.0 1.12 2.5 0.35Embedded 3.6 1.20 2.5 0.32

Basic COCOMO is good for quick, early, rough order of magnitude estimates ofsoftware costs, but it does not account for differences in hardware constraints,personnel quality and experience, use of modern tools and techniques, and otherproject attributes known to have a significant influence on software costs, whichlimits its accuracy.

COCOMO 81 assumed that the software would be developed according to awaterfall process using standard imperative programming languages such as Cor FORTRAN. However, there have been radical changes to softwaredevelopment since this initial version was proposed. Prototyping and incrementaldevelopment are commonly used process models. Software is now oftendeveloped by assembling reusable components with off-the-shelf systems andgluing them together with scripting language. Data-intensive systems aredeveloped using a database programming language such as SQL and acommercial database management system.

Existing software is re-engineered to create new software. CASE tool support formost software process activities is now available.

Intermediate cocomo

The Intermediate COCOMO is an extension of the Basic COCOMO model, andestimates the programmer time to develop a software product. This extensionconsiders a set of four "cost driver attributes", each with a number of subsidiaryattributes:

Product attributeso Required software reliabilityo Size of application databaseo Complexity of the product

Hardware attributeso Run-time performance constraintso Memory constraintso Volatility of the virtual machine environment
http://en.wikipedia.org/wiki/Basic_COCOMOhttp://en.wikipedia.org/wiki/Basic_COCOMO


47/88


CSE-316 PAGE NO



o Required turnabout time Personnel attributes

o Analyst capabilityo Software engineer capabilityo Applications experienceo Virtual machine experienceo Programming language experience

Project attributeso Use of software toolso Application of software engineering methodso Required development schedule

Example estimate using the intermediate COCOMO IMode is organic Size = 200KDSICost drivers :

Low reliability => .88

High product complexity => 1.15

Low application experience => 1.13

High programming language experience => .95

Other cost drivers assumed to be nominal => 1.00

C = .88 * 1.15 * 1.13 * .95 = 1.086

Effort = 3.2 * ( 200 1.05 ) * 1.086 = 906 MM

Development time = 2.5 * 906 0.38

Advantages of COCOMO I

i. COCOMO is transparent, you can see how it works unlike other models such asSLIM.

ii. Drivers are particularly helpful to the estimator to understand the impact ofdifferent factors that affect project costs.

Drawbacks of COCOMO I


48/88


CSE-316 PAGE NO



i. It is hard to accurately estimate KDSI early on in the project, when most effortestimates are required.

ii. KDSI, actually, is not a size measure it is a length measure.iii. Extremely vulnerable to mis-classification of the development modeiv. Success depends largely on tuning the model to the needs of the organization,

using historical data which is not always available

COCOMO II

To take these changes into account, the COCOMO II model recognizes differentapproaches to software development such as prototyping, development bycomponent composition and use of database programming. COCOMO II

supports a spiral model of development and embeds several sub-models thatproduce increasingly detailed estimates. These can be used in successiverounds of the development spiral. Figure below shows COCOMO II sub-modelsand where they are used.

The sub-models that are part of the COCOMO II model are:

1. An application-composition model This assumes that systems arecreated from reusable components, scripting or database programming. It

is designed to make estimates of prototype development. Software sizeestimates are based on application points, and a simple size/productivityformula is used to estimate the effort required. Application points are thesame as object points discussed in Section 26.1, but the name waschanged to avoid confusion with objects in object-oriented development.

2. An early design model This model is used during early stages of thesystem design after the requirements have been established. Estimatesare based on function points, which are then converted to number of linesof source code. The formula follows the standard form discussed abovewith a simplified set of seven multipliers.

3. A reuse model This model is used to compute the effort required to

integrate reusable components and/or program code that is automaticallygenerated by design or program translation tools. It is usually used inconjunction with the post-architecture model.

4. A post-architecture model Once the system architecture has beendesigned, a more accurate estimate of the software size can be made.Again this model uses the standard formula for cost estimation discussedabove. However, it includes a more extensive set of 17 multipliersreflecting personnel capability and product and project characteristics.


49/88


CSE-316 PAGE NO



Of course, in large systems, different parts may be developed usingdifferent technologies, and you may not have to estimate all parts of thesystem to the same level of accuracy. In such cases, you can use theappropriate sub-model for each part of the system and combine theresults to create a composite estimate.

THE COCOMO II MODELS


50/88


CSE-316 PAGE NO



EXPERIMENT 7

AIM : To study the software design . Explain design fundamentals anddesign methods .

Software design

Software design deals with transformation of the customers requ irement which isdescribed in SRS into a structure that will be implemented using someprogramming language. The design phase consists of

1. Identify different modules required for designing

2. Control relationship among the identify modules

3. Interface among the different modules

4. Data structure of the individual module

5. Algorithm required implementing the module

In this the SRS document is the input for the designing phase. SRS will tell whatthe system does without knowing how it will be done.

What How

D

E

S

I


51/88


52/88


CSE-316 PAGE NO



1. Top down approach(modular design)2. Design and conquer principal3. Graphical representation using DFD

Structure Design:-

The main aim of the structure design is to transform theresult of the structure analysis into software chart. A structure chartrepresentation the software architecture. Which consist of number of modulesthat are used to create a system, a module dependency and the parameter thatare passed among the different modules, The structure chart representation can

be easily implemented using some programming language

Structure Design tools:-

1. DFD(Data flow diagram)2. DD(Data dictionary)3. Structure chart4. pseudo code

Data flow diagram (DFD) is a graphical representation of the "flow" of datathrough an information system. A data flow diagram can also be used for thevisualization of data processing (structured design). It is common practice for adesigner to draw a context-level DFD first which shows the interaction betweenthe system and outside entities. This context-level DFD is then "exploded" toshow more detail of the system being modeled.

It is also known as Bubble Chart . Data flow diagrams (DFDs) are one of thethree essential perspectives of Structured Systems Analysis and Design Method.The sponsor of a project and the end users will need to be briefed and consultedthroughout all stages of a system's evolution. With a dataflow diagram, users areable to visualize how the system will operate, what the system will accomplish,and how the system will be implemented. The old system's dataflow diagramscan be drawn up and compared with the new system's dataflow diagrams to drawcomparisons to implement a more efficient system. Dataflow diagrams can beused to provide the end user with a physical idea of where the data they inputultimately has an effect upon the structure of the whole system from order to


53/88


CSE-316 PAGE NO



dispatch to restock how any system is developed can be determined through adataflow diagram.

Rules for DFD:-

1. All the name should be uniqe2. It doest contain the decision box 3. It doest tell the event of order 4. It will show the flow of information with in system

Data dictonary are used to store information about all the data items defined inthe DFD. It is an organized lists of all the data items so that data dictonary is likeother dictionary that containes the names of the data elements or items anddiscription about that elements.

Information include in data dictonary :-

1. Name of the data item2. Other name of the data item3. Discription of the purpose4. Related data items5. Range of values6. Data structure definition

Structure chart : - The Structure chart one of the most commonly used methodfor system design. In this the system is divided into module. These modules areknown as the black box. Black means the functionality of known to the userwithout the knowledge of internal design input are given to black box andappropriate output are generated by the black box these concept reduce thecomplexity of the design system are easy to construct.

In the Structure chart hierarchy modules are top level can all the modules at thelower level. The connections between the modules are represented by solid lineare arrow head. Modules are number to understand the structure chart. The

modules can pass the parameter to each other and they can call the modules todifferent levels.


54/88


CSE-316 PAGE NO



1.Module

2.Control

3. Data

4. 5.

6. 7.

Repetitive call Conditional call

PhysicalLibrary

Module


55/88


CSE-316 PAGE NO



Pseudo code : - notation can be used in both the preliminary and detaileddesign likely flow chart pseudo code can be used at any desire level ofabstraction. Using this code designer describe the system char by using thedifferent keywords such as BEGIN and if then else, while, do while etc. this keywords represents the processing actions. These code can be replace flow charand reduce the amount of external documentation requires to describe thesystem.

Relationship between Object Oriented Analysis (OOA) & Object OrientedDesign (OOD) : -

Analysis

Design

Object oriented approach of the software development consists of OOA andOOD. When we combine the feature of these tools then we get a method OOAD(Object oriented analysis design).

The fundamental different between OOA and OOD is that the OOA models theproblem domain, leading to an understanding and specification of the problemwhereas OOD models the solution of that problem. In other words, the objectsduring OOA focus on the problem domain and the objects during OOD focus onthe solution domain. So analysis deals with the specification and understandingof the problem in the form of objects while design deals with the solution of thatproblem using object oriented concept. The solution domain representationcreates by OOD contains much of the representation created by OOA. Theobject used in the problem domain are called semantic object and the solution

Problem


56/88


CSE-316 PAGE NO



domain consists of sementic object as well as three other object that is interface,application and utility.

The interface object deals with the user interfaceThe application objects specify the control mewchanism for the purposedsolutionUtility objectare those which are needed to support the services of thesemantic object or to implement them efficiently . For example trees ,queues, table, stack, array etc.

The basic goal of OOA and OOD is to produce the objectdesign for the system that is represented by object diagram.

Object Oriented design : - Basic conceptsb of the OOD or feature of OOD are

1. Objects :- Objects are the basic run-time ent

software engineering (2005-09)

Documents