IMTS MCA (Advertising software engineering) by IMTS INSTITUTE

I ns t i t ut eo fMa na g e me nt & Te c hni c a lSt udi e s

ADVERTI SI NGSOFTWARE

ENGI NEERI NG

Ma s t e ro fCo mput e rAppl i c a t i o n www. i mt s i ns t i t ut e . c o m

IMTS (ISO 9001-2008 Internationally Certified) ADVERTISING SOFTWARE ENGINEERING

ADVERTISING SOFTWARE ENGINEERING

FOR

Advertising Software Engineering Unit 1 Introduction to Software Engineering

01-14

Unit 2 Software Engineering Approach

15-23

Unit 3 The Process, Design Concepts and Models

24-44

Unit 4 Project Scheduling and Tracing

45-61

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Unit 1 Introduction To Software Engineering Structure 1.1

Chapter Objective

1.2

Introduction of software

1.3

The evolving role of software

1.4

Software characteristic

1.5

Types of software

1.6

Software application

1.7

What is software engineering

1.8

Software engineering concepts

1.9

What does software engineering involve

1.10

Importance of software engineering

1.11

Principles of software engineering

1.12

Summary

1.13

Self test

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 1.1

Chapter Objective After completion of this chapter, you should be able to understand :

1.2



Basic concepts and role of Software



Software characteristic and types



Software engineering basic concepts



Importance and principles of Software engineering

Introduction Of Software Software is the collectionï¿½ of computer programs, procedures, rules , associated documentation and data which are collected for specific purpose.Software is the various kinds of programs used to operate computers and related devices. A program is a sequence of instructions that tells a computer what operations to perform. Programs can be built into the hardware itself, or they may exist independently in a form known as software. Hardware describes the physical components of computers and related devices.

According to IEEE ï¿½ï¿½software is a collection of computer programs, procedures, rules and associated documentation and data.ï¿½

Software is often divided into two categories, system software or industrial strength software and Application software or simple software. Application software is a simple program that is usually designed, developed, used and maintained by the same person. No systematic approach is required for such type of softwareï¿½s. System software use some systematic approach called programming systems. Different users in different platform use these softwareï¿½s and the complexity is high. System software includes operating systems and any program that supports application software.

1.3

The Evolving Role Of Software The industry originated with the entrepreneurial computer software and services companies of the 1950s and 1960s, grew dramatically through the 1970s and 1980s to become a market force rivaling that of the computer hardware companies, and by the 1990s had become the supplier of technical know-how that transformed the way people worked, played and communicated every day of their lives. The following are the different erasï¿½ of software engineering:

The Pioneering Era (1955-1965)

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

The most important development was that new computers were coming out almost every year or two, rendering existing ones obsolete. Software people had to rewrite all their programs to run on these new machines. Jobs were run by signing up for machine time or by operational staff by putting punched cards for input into the machine's card reader and waiting for results to come back on the printer. The field was so new that the idea of management by schedule was non-existent. Making predictions of a project's completion date was almost impossible. Computer hardware was application-specific. Scientific and business tasks needed different machines. Hardware vendors gave away systems software for free as hardware could not be sold without software. A few companies sold the service of building custom software but no software companies were selling packaged software.

The Stabilizing Era (1965-1980) The whole job-queue system had been institutionalized and so programmers no longer ran their jobs except for peculiar applications like on-board computers. To handle the jobs, an enormous bureaucracy had grown up around the central computer center. The major problem as a result of this bureaucracy was turnaround time, the time between job submission and completion. At worst it was measured in days. Then came the IBM 360. It signaled the beginning of the stabilizing era. This was the largest software project to date. The 360 also combined scientific and business applications onto one machine. The job control language (JCL) raised a whole new class of problems. The programmer had to write the program in a whole new language to tell the computer and OS what to do. JCL was the least popular feature of the 360. "Structured Programming" burst on the scene in the middle of this era. PL/I, introduced by IBM to merge all programming languages into one, failed. Most customized applications continued to be done in-house.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

The Micro Era (1980-Present) The price of computing has dropped dramatically making ubiquitous computing possible. Now every programmer can have a computer on his desk. The old JCL has been replaced by the user-friendly GUI. The software part of the hardware architecture that the programmer must know about, such as the instruction set, has not changed much since the advent of the IBM mainframe and the first Intel chip. ï¿½The most-used programming languages today are between 15 and 40 years old. The Fourth Generation Languages never achieved the dream of "programming without programmers" and the idea is pretty much limited to report generation from databases. There is an increasing clamor though for more and better software research.

1.4

Software Characteristic For a better understanding of the software, it is important to examine the characteristics of software that make it different from other things that human beings build. When hardware is built, the human creative process (analysis, design, construction, testing) is ultimately translated into a physical form. If we build a new computer, our initial sketches, formal design drawings, and bread boarded prototype evolve into a physical product (chips, circuit boards, power supplies, etc.). Since software is purely logical rather than a physical therefore,

system has

element,

characteristics

that are entirely different than those of hardware: 1.

Software is developed or engineered but it is not manufactured in the classical sense: Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. The relationship, often called the "bathtub curve," indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some period of time. As time passes, however, the failure rate rises again as

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

hardware components suffer from the cumulative affects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. 2.

Consider the manner in which the control hardware for a computer-based product is designed and built: The design engineer draws a simple schematic of the digital circuitry, does some fundamental analysis to assure that proper function will be achieved, and then goes to the shelf where catalogs of digital components exist. A software component should be designed and implemented so that it can be reused in different programs since it is a better approach, according to finance and manpower. In the 1960s, we built scientific subroutine libraries that were reusable in a broad array of engineering and scientific applications. These subroutine libraries reused well-defined algorithms in an effective manner but had a limited domain of application. Today, we have extended our view of reuse to encompass not only algorithms but also data structure. Modern reusable components encapsulate both data and the processing applied to the data, enabling the software engineer to create new applications from reusable parts.

1.5

Types Of Software The two main types of software are system software and application software. Application software is programs that do work users are directly interested in. System software includes operating systems and any program that supports application software.

System software System software controls a computer's internal functioning, mainly through an operating System (OS), and also controls such peripherals (attached devices) as monitors, printers, and storage devices. The operating system allows all of the hardware and software systems to work together. It manages the computer's operations, controlling devices and overseeing other programs, called applications. An operating system consists of programs and routines that coordinate operations and processes, translate the data from various input and output devices, regulate data storage in memory, allocate tasks to various processors, and provide functions that help programmers to write software. In some specialized, or embedded, computers the operating instructions are contained in their circuitry; common examples are the microcomputers found in calculators, wristwatches, automobile engines, and microwave ovens.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Application software Application software directs the computer to execute commands given by the user and may be said to include any program that processes data for a user. Application software includes: 

Games.



CAD/CAM software.



Database management.



Presentation software.



Inventory and payroll programs.



Specialized scientific applications.



Graphics software for graphic designers.



Productivity software, such as word processors, spreadsheets, and tools for use by most computer users.



Vertical market or industry-specific software (for example, for banking, insurance, retail, and manufacturing environments).

Distribution of Software: Software can be purchased or acquired as

1.6



public domain software (free with no restrictions),



liteware (shareware with some capabilities disabled),



freeware (free software but with copyright restrictions),



shareware (usually intended for sale after a trial period),



free software (software whose users agree not to limit its further distribution).

Software Application Information determinacy refers to the predictable of the order and timing of information. An engineering analysis program accepts data that have a predefine order, execute the analysis algorithm(s) without interruption, and produce resultant data in report or graphical format. It is sometime difficult to develop meaningful generic categories for software application. As software complexity grows, neat compartmentalization disappears. The fallowing software areas indicate the breadth of potential application. 1.

System Software: - System Software is a collection of programs written to service other programs. Some system Software (eg. Compiler, editor)

Real-Time software : -software that monitor/analyzes/controls real-world events as they occur is called real-time.

Business Software : - Business information processing is the largest single software application area.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 4.

Engineering and Scientific Software : - Engineering and Scientific software application area.

Artificial Intelligence Software: - Artificial Intelligence software makes use of nonnumerical algorithm to solve complex problem that are not amenable to computation or straightforward analysis.

1.7

What is Software Engineering The need for systematic approaches to development and maintenance of computer software systems became apparent in the 1960ï¿½s.During that decade, third-generation computing hardware was inverted, and the software techniques of multiprogramming and time-sharing were developed. To develop a software system, initially, the user needs and constraints are identified.

Software engineering is the field of computer science that deals with the building of software systems, which are large and complex. It is a systematic, disciplined, quantifiable approach to the development, maintenance of the software to ensure the best solution most economically.

Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates. Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.

Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.

The practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them. - Boehm

Software engineering is the application of principles, skills, and art to the design and construction of programs and systems of programs. - Dennis

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Software engineering is the technological and managerial discipline concerned with the systematic production and maintenance of software products that are developed and modified on time and within cost estimates. - Fairley

Software engineering is the practical application of scientific knowledge for the economical production and use of high-quality software. ï¿½ï¿½- Pomberger and Blaschek

1.8

Software Engineering Concepts The primary reason for this is that approaches to software development are frequently ad hoc and programming-centered. The ad hoc or programming-centered approach in developing is software a programming exercise and it may work for small projects, but for the problem domain that we are interested in, these approaches generally do not work. If we have to control this software crisis, some methodical approach is needed for software development. This is where software engineering comes in. Software engineering is defined as the systematic approach to the development, operation, maintenance, and retirement of software. Software engineering and traditional engineering disciplines share the similar approach to development and maintenance of technological artifacts. The fundamental sources of these differences are the lack of physical laws for software, the lack of product visibility, and obscurity in the interfaces between software modules. Software engineering differs from traditional computer programming in terms of engineering like techniques used to specify, design, implement, validate and maintain software within the time and budget constraints established for the project. Another definition from the economic and human perspective is given by combining the dictionary's definition of engineering with its definition of software. This definition states: Software Engineering is the application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation. The use of the terms systematic approach of mathematics and science for the development of software means that software engineering provides methodologies for developing software as close to the scientific method as possible. That is, these methodologies are repeatable, and if different people apply these methodologies, similar software will be produced. In essence, the goal of software engineering is to take software development closer to science and away from being an art. Note also that the

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

focus of software engineering is not developing software per se, but methods for developing software. That is, the focus is on developing methods that can be used by various software projects. The phrase useful to man emphasizes the needs of the user and the software's interface with the user. This definition implies that user needs should be given due importance in the development of software, and the final program should give importance to the user interface. With this definition of software engineering, let us now discuss a few fundamental problems that software engineering faces.

1.9

What does Software Engineering Involve? It involves the elicitation of the systemï¿½s requirements, the specification of the system, its architectural and detailed design. In addition, the system needs to be verified and validated, a set of activities that commonly take more than 50% of all development resources. Testing techniques and tools, at different levels (unit, integration, system) are needed. Software development being a human intensive process, management and quality control techniques are also required to run successful projects and construct quality systems.

1.10

Importance of Software Engineering In most systems, including telecommunication systems, software is the overriding component in terms of cost and complexity. Good software engineering practices and tools can therefore make a substantial difference, even to the extent that they may be the driving force of the project success.

1.11

Principle of software Engineering Because the product of software engineering is not physical, physical laws do not form a suitable foundation. Instead, software engineering has had to evolve its principles based solely on observations of thousands of projects. The following are probably the 15 most important principles: 

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

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

1.12



Put technique before tools



Get it right before you make it faster



Inspect code



Good management is more important than good technology



People are the key to success



Follow hype with care



Take responsibility

Summary Software is group of instructions that tell a computer what to do. Software is the entire set of programs, procedures, and routines associated with the operation of a computer system, including the operating system. The term differentiates these features from hardware, the physical components of a computer system. Two main types of software are system software, which controls a computer's internal functioning, and application software, which directs the computer to execute commands that solve practical problems. A third category is network software, which coordinates communication between computers linked in a network. Software is written by programmers in any number of programming languages. This information, the source code, must then be translated by means of a compiler into machine language, which the computer can understand and act on.

Software Engineering is the process of manufacturing software systems. A software system consists of executable computer code and the supporting documents needed to manufacture, use, and maintain the code. For example, a word processing system consists of an executable program (the word processor), user manuals, and the documents, such as requirements and designs, needed to produce the executable program and manuals.

Software engineering is ever more important as larger, more complex, and life-critical software systems proliferate. The rapid decline in the costs of computer hardware means that the software in a typical system often costs more than the hardware it runs on. Large software systems may be the most complex things ever built. This places great demands on the software engineering process, which must be disciplined and controlled.

To meet this challenge, software engineers have adapted many techniques from older engineering fields, as well as developing new ones. For example, divide and conquer, a

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

well-known technique for handling complex problems, is used in many ways in software engineering. The software engineering process itself, for example, is usually divided into phases. The definition of these phases, their ordering, and the interactions between the phases specify a software life-cycle model. The best-known life-cycle model is the waterfall model consisting of a requirements definition phase, a design phase, a coding phase, a testing phase, and a maintenance phase. The output of each phase serves as the input to the next.

The purpose of the requirements phase is to define what a system should do and the constraints under which it must operate. This information is recorded in a requirements document. A typical requirements document might include a product overview; a specification of the development, operating, and maintenance environment for the product; a high-level conceptual model of the system; a specification of the user interface; specification of functional requirements; specification of nonfunctional requirements; specification of interfaces to systems outside the system under development; specification of how errors will be handled; and a listing of possible changes and enhancements to the system. Each requirement, usually numbered for reference, must be testable.

In the design phase, a plan is developed for how the system will implement the requirements. The plan is expressed using a design method and notation. Many methods and notations for software design have been developed. Each method focuses on certain aspects of a system and ignores or minimizes others. This is similar to viewing a building with an architectural drawing, a plumbing diagram, an electrical wiring diagram, and so forth.

The coding phase of the software life-cycle is concerned with the development of code that will implement the design. This code is written is a formal language called a programming language. Programming languages have evolved over time from sequences of ones and zeros directly interpretable by a computer, through symbolic machine code, assembly languages, and finally to higher-level languages that are more understandable to humans.

Most coding today is done in one of the higher-level languages. When code is written in a higher-level language, it is translated into assembly code, and eventually machine code, by a compiler. Many higher-level languages have been developed, and they can be categoriged as functional languages, declarative languages, and imperative languages.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Following the principle of modularity, code on large systems is separated into modules, and the modules are assigned to individual programmers. A programmer typically writes the code using a text editor. Sometimes a syntax-directed editor that ï¿½knowsï¿½ about a given programming language and can provide programming templates and check code for syntax errors is used. Various other tools may be used by a programmer, including a debugger that helps find errors in the code, a profiler that shows which parts of a module spend most time executing, and optimizers that make the code run faster.

Testing is the process of examining a software product to find errors. This is necessary not just for code but for all life-cycle products and all documents in support of the software such as user manuals. The software testing process is often divided into phases. The first phase is unit testing of software developed by a single programmer. The second phase is integration testing where units are combined and tested as a group. System testing is done on the entire system, usually with test cases developed from the system requirements. Acceptance testing of the system is done by its intended users.

The basic unit of testing is the test case. A test case consists of a test case type, which is the aspect of the system that the test case is supposed to exercise; test conditions, which consist of the input values for the test; the environmental state of the system to be used in the test; and the expected behavior of the system given the inputs and environmental factors.

When software is changed to fix a bug or add an enhancement, a serious error is often introduced. To ensure that this does not happen, all test cases must be rerun after each change. The process of rerunning test cases to ensure that no error has been introduced is called regression testing.

Walkthroughs and inspections are used to improve the quality of the software development process. Consequently, the software products created by the process are improved. A quality system is a collection of techniques whose application results in continuous improvement in the quality of the development process. Elements of the quality system include reviews, inspections, and process audits.

Large software systems are not static; rather, they change frequently both during development and after deployment. Maintenance is the phase of the software life-cycle after deployment. The maintenance phase may cost more than all of the others combined

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

and is thus of primary concern to software organizations. The Y2K problem was, for example, a maintenance problem.

Maintenance consists of three activities: adaptation, correction, and enhancement. Enhancement is the process of adding new functionality to a system. This is usually done at the request of system users. This activity requires a full life-cycle of its own. That is, enhancements demand requirements, design, implementation, and test. Studies have shown that about half of maintenance effort is spent on enhancements.

Adaptive maintenance is the process of changing a system to adapt it to a new operating environment, for example, moving a system from the Windows operating system to the Linux operating system. Adaptive maintenance has been found to account for about a quarter of total maintenance effort. Corrective maintenance is the process of fixing errors in a system after release. Corrective maintenance takes about 20% of maintenance effort.

Since software systems change frequently over time, an important activity is software configuration management. This consists of tracking versions of life-cycle objects, controlling changes to them, and monitoring relationships among them. Configuration management activities include version control, which involves keeping track of versions of life-cycle objects; change control, an orderly process of handling change requests to a system; and build control, the tracking of which versions of work products go together to form a given version of a software product.

1.13

Self Test 1

Define software engineering and its principles. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------------

Explain software engineering as a problem solving paradigm ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------

Is Software a product or a process? Justify your answer.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------4

What are the major differences between Software engineering and manufacturing? -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Unit 2 Software Engineering Approaches, Problems, Crisis And Myths Structure 2.1

Objective

2.2

Software Engineering Approach

2.3

Software Engineering Problem

2.4

Causes of the problem

2.5

Software Crisis

2.6

Software Myths

2.7

Management Myths

2.8

Customer Myths

2.9

Practitioner誰s Myths

2.10

Formal Software Development Process

2.11

Summary

2.12

Self Test

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

2.1

Objective After completion of this chapter, you should be able to understand :

2.2



Basic approaches in Software Engineering



Software engineering problems



Software crisis concept



Myths related to SE and Management



Myths related to customer, practitioner etc.



Formal Software Development Process

Software Engineering Approach Software Engineering is the discipline providing methods and tools for the construction of quality software with a limited budget and a given deadline, in the context of constant requirements change. The IEEE definition is: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. It is called "engineering" because early practitioners wanted to call it "software physics," but that term was already in use. They wanted to call it software physics because they believed that the process of producing software could be formalized with such rigor that it would be on all fours with physics. Indeed, texts from the '80s are populated with theories, derivations, tables, graphs, equations and formulae, apparently in an attempt to appear mathematical and scientific in nature. Exactly what those engineering methods, processes, techniques and measurements are never stated, and the books never refer to them after the introduction. Of course SE is an artificial science, whereas physics and chemistry are natural sciences. Software projects and programmers vary enormously, and some require vastly different approaches than others. Supposing that all software programs can fit under the same umbrella is a mistake akin to thinking that mechanical, electrical and chemical engineering can be lumped together. To be sure, there are many areas of software research that are properly called scientific.

2.3

Software Engineering Problem Modern society and modern economies rely on infrastructures for communication, finance,

energy

distribution,

and

transportation.

These

infrastructures

depend

increasingly on networked information systems. Attacks against these systems can threaten the economical or even physical well being of people and organizations. There

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

is widespread interconnection of information systems via the Internet, which is becoming the world's largest public electronic marketplace, while being accessible to untrusted users. Attacks can be waged anonymously and from a safe distance. If the Internet is to provide the platform for commercial transactions, it is vital that sensitive information (like credit card numbers or cryptographic keys) is stored and transmitted securely.

Developing secure software systems correctly is difficult and error-prone. Many flaws and possible sources of misunderstanding have been found in protocol or system specifications, sometimes years after their publication (for example, the observations in (Lowe 1995) were made 17 years after the concerned well-known protocol had been published in (Needham, Schroeder 1978). Much vulnerability in fielded security-critical systems have been exploited, sometimes leading to spectacular attacks. For example, as part of a 1997 exercise, an NSA hacker team demonstrated how to break into U.S. Department of Defense computers and the U.S. electric power grid system, among other things simulating a series of rolling power outages and 911 emergency telephone overloads in Washington, D.C., and other cities (Schneider 1999).

The problems that afflict software development can be characterized from a number of different perspectives, but managers responsible for software development tend to focus on bottom line issues: Schedule and cost estimates are often grossly inaccurate; the productivity of software people hasn't kept pace with the demand for software; the quality of software is sometimes less than adequate. These problems are the most visible manifestations of other software difficulties: we have not taken time to collect data on the software development process. With little historical data, estimation has been produced in haste with predictably poor results; customer dissatisfaction with the completed system is encountered too frequently. Software development projects are frequently undertaken with only a vague indication of the customer requirements -communication between the customer and the developer is often poor; software quality is often suspect. We have only recently begun to understand the importance of systematic, technically complete software testing. The software development community is only just taken up quality assurance principles; existing software can be difficult to maintain. Software maintenance is the most expensive part of software development yet future maintainability has not been emphasized as an important criteria for software acceptance. So, that is the bad news. The good news is that each of these problems can be corrected. A structured approach to the development

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

of software, together with continuing improvement of the techniques and tools employed in the software development process, provides the key.

2.4

Causes of the Problems Problems associated with the software crisis have been caused by the characteristics of software itself and by the failings of the people charged with software development responsibility. However, it is possible that we have expected too much in a short space of time - after all our experience is only some 40 years old ! The major causes include: ï¿½the logical nature of software provides a challenge to the people who develop it. The intellectual challenge of software development is considerable - we can not expect individuals to always get the logic process correct; human error is inevitable, we usually communicate with the machine through the keyboard and not all typing errors will be picked up; middle and upper-level managers with no background in software are often given the responsibility for software development. There is an old management axiom that states: 'A manager can manage any project'. We should add: '...if they are willing to learn the milestones that can be used to measure progress, apply effective methods of control, disregard mythology, and become conversant in a rapidly changing technology'. The manager must communicate with all those involved in the software development: customers, software developers, support staff, etc.;

software developers have little formal training in techniques for software development. In some organizations anarchy still reigns. Each individual approaches the task of writing programs with experience derived from past efforts. Some people develop an orderly and efficient approach to software development by trial and error, but others develop bad habits that result in poor software quality and maintainability; we all resist change, it is ironic however, that while computing hardware experiences enormous change, the software people responsible for tapping that potential often resist change when it is introduced.

First reason for causes of problem is security requirements are intrinsically subtle, because they have to take into account interaction of the system with motivated adversaries that act independently. Thus some security mechanisms, for example security protocols, are notoriously hard to design correctly, even for experts. Also, a system is only as secure as its weakest part or aspect. Secondly, risks are very hard to calculate because of a positive reinforcement in the failure occurrence rates over repeated system executions: security-critical systems are characterized by the fact that the occurrence of a failure (that is, a successful attack) at

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

one system execution dramatically increases the likelihood that the failure will occur at any following execution of a system with the same part of the design. For some attacks (for example against web sites), this problem is made worse by the existence of a mass communication medium that is currently largely uncontrolled and enables fast distribution of exploit information (again, the Internet).

Thirdly, many problems with security-critical systems arise from the fact that their developers, who employ security mechanisms, do not always have a strong background in computer security. This is problematic since in practice, security is compromised most often not by breaking dedicated mechanisms such as encryption or security protocols, but by exploiting weaknesses in the way they are being used.

Thus it is not enough to ensure correct functioning of used security mechanisms; they cannot be "blindly" inserted into a security-critical system, but the overall system development must take security aspects into account. In the context of computer security, "an expansive view of the problem is most appropriate to help ensure that no gaps appear in the strategy".

Lastly, while functional requirements are generally analyzed carefully in systems development, security considerations often arise after the fact. Adding security as an afterthought, however, often leads to problems (Gasser 1988, Anderson 2001). Also, security engineers get few feedbacks about the secure functioning of the developments in practice, since security violations are often kept secret in fear of harm for a company's reputation.

It has remained true over the last 25 years that "no complete method applicable to the construction of large general-purpose systems exists yet" (Saltzer, Schroeder 1975) that would ensure security, in spite of very active research and many useful results addressing particular subgoals (Schneider 1999). Ad hoc development has lead to many deployed systems that do not satisfy relevant security requirements. Thus a sound methodology supporting secure systems development is needed.

2.5

Software Crisis The term software crisis has been frequently coined, the Oxford English Dictionary defines crisis as: 'a decisive moment, a time of danger or great difficulty, a turning point'

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

yet for the software industry this crisis has been with us for nearly 30 years - this is a contradiction. Authors have instead proposed the term chronic affliction . Specifically, the adjective chronic suggests longevity and reoccurrence - there are no miracle cures, rather there are ways that we can reduce the pain as we try to find a cure. Regardless of whether we use the term software crisis or software affliction, the term alludes to a set of problems that are encountered in the development of computer software. The problems are not limited to software that doesn't function properly. Rather, the affliction encompasses problems associated with:

how we develop software; how we maintain the growing volume of existing software

how we keep pace with the growing demand for software; how we manage the software development process.

2.6

Software Myths Myth is the most popular of all story forms, but it comes with many hidden pitfalls. Myth uses the journey structure, which is a very different kind of plotting technique than the one found in some other genres where the hero has to dig under the surface to get to the truth. Or writers think you can just rewrite the old myths. But the old myths grew out of a local environment and a point of view unique to that place and time.

2.7

Management Myths Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality.

Myth: We already have a book that's full of standards and procedures for building software. Won't that provide my people with everything they need to know?

Reality: The book of standards may exist, but is it used? Are software developers aware that it exists? Does it reflect modern software development practice? Is it complete? In many cases the answer to these questions is no.

Myth: My people have the latest software development tools; after all we do buy them the latest computers.

Reality: It takes more than the latest computer to do high quality software development. Computer-aided software engineering (CASE) tools are more important than hardware

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

for achieving good quality and productivity, yet the majority of software developers still do not use them.

Myth: If we get behind schedule we can add more programmers and catch up.

Reality: Software development is not a mechanistic process like manufacturing. In the words of Brook: '..Adding people to a late software project makes it later'. As new people are added, those who were originally working on it must spend time educating the newcomers. People can be added but only in a planned and well co-ordinated manner.

2.8

Customer Myths Customers may not understand the nature of software development; false expectations must be eliminated at the start. Communication is essential.

Myth: A general statement of objectives is sufficient to start writing programs - we can fill in the details later.

Reality: Poor up-front definition is the major cause of failed software efforts. A formal and detailed description of the information domain, function, performance, interfaces, design constraints and validation criteria is essential. These characteristics can be determined only after thorough communication between customer and developer.

Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.

Reality: It is true that requirements do change, but the impact of change varies with the time that it is introduced - the later in the software development process, the more difficult change is to accommodate.

2.9

Practitioner's Myths Old ways and attitudes die-hard. Myth: Once we write a program and get it to work, our job is done.

Reality: The majority of effort expended on a program will be after the program has been delivered for the first time- maintenance.

Myth: Until I get the program running I have no way of assessing its quality.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Reality: One of the most effective software quality assurance mechanisms is the formal technical review. These can be undertaken long before the program is running.

Myth: The only deliverable for a successful project is the working program.

Reality: A working program is only one of the elements of the project. Other elements include: project plans, requirements specifications, system designs, test specifications, support documentation etc. Documentation forms the foundation for successful development and, more importantly, provides the foundation for the software maintenance task.

2.10

Formal Software Development Process Taking a high level view, we aim to transform our problem domain from a complex, messy, irrational mass to a simple, ordered model. Entities which may be modeled: organizations plus their environment and strategy; business processes and business data; systems development process.

Modeling the Real World Using the analogy of house building, we transform our conceptual image of our required house into the physical product via the process of creating a model (the various drawings), having a plan to determine how the project is going to be managed and method for how the plan is going to be implemented.

A model is a representation of part (or all) of a system; at a given level of abstraction from a given perspective.ï¿½

2.11

Summary Theï¿½ Software engineering process comes with a lot of problems attached to it. Many of them have been discussed here in this chapter. A software engineer has to deal with customers who may not be exposed to technology and hence can not be expected to understand the problems faced during the SDLC.

A lot of myths come from all the parties involved in SDLC. These points have been discussed in this chapter.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Taking care of all the myths and realities, the chapter in the last section has presented a formal way of proceeding with SDLC.

2.12

Self test 1

Explain software crisis and cause of software crisis. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Write a short note on: 誰Management myths Customer myths Role of software -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Present a short note on Formal method of SDLC. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

What are the reasons of failure of software according to you? ---------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Unit 3 The Process, Design Concepts And Models Structure 3.1

Chapter Objective

3.2

Software Process

3.3

Characteristics of Software Process

3.4

Software Process, Projects & Products

3.5

Design Concept and Modeling

3.6

Concepts

3.7

Design Objectives

3.8

Design Principles

3.9

Software Engineering Process Models

3.10

Waterfall Model, characteristics

3.11

Its Advantages and Limitations

3.12

Prototype Model

3.13

Itï¿½s Advantages and Limitations

3.14

Prototype effect on Software development cost

3.15

Iterative Enhancement Model

3.16

Spiral Model

3.17

COCOMO Model

3.18

Summary

3.19

Self Test

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 3.1

Chapter Objective After completion of this chapter, you should be able to understand :

3.2



Software Process characteristics



Software design concept



Software design objectives



Popular models in SE



Waterfall, prototype models



Models comparative evaluation

Software Process

The concept of process is the main step in the software engineering approach. The process means "a particular method of doing something, generally involving a number of steps or operations." In software engineering, the phrase software process refers to the method of developing software. A software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced. The desired result is, as stated earlier, highquality software at low cost. The process that deals with the technical and management issues of software development is called a software process.

For any system, the development process revolves around a life cycle that begins with the recognition of user needs. The life cycle is not procedure that deals with hardware and software. It is building computer-based systems to help the users to operate a business or make decisions effectively and manage an enterprise successfully. The software life cycle encompasses all activities required to define, develop, test, deliver, operate and maintain a software system.

The Software Engineering Institute has developed the Team Software Process (TSP) SM to help integrated engineering teams more effectively develop software-intensive products. Testing is generally expensive and time consuming, and often followed by many months of user testing before the products are fully usable.

The TSP has been used with pure software teams and with mixed teams of 2 to 20 hardware and software engineers and it has been shown to sharply reduce the total cost of development and acquisition. TSP has been used for both new development and enhancement and with both commercial and imbedded real-time systems. A number of organizations are using the TSP and this talk describes some of their experiences. Below is a simple software production model using system dynamics, and next is the output of a Raleigh-curve simulation of a software project.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING Many

persons

work

producing

26 software

systems

for

many

users.

The task description and the requirements frequently change even during the program design phase, and their continue to change even after the software system has long since been in use. The major problems encountered in development of large software systems were: 

Correctness



Efficiency



Mastery of complexity



Interface specification



Reliability



Flexibility



Documentation



Maintainability



Project organization.

Inadequate theoretical foundation and too few methodological aids were known in both the technical and the organizational realm. Programmersï¿½ qualifications did not suffice to adequately solve the problems. The concept of process is the main step in the software engineering approach. The process means "a particular method of doing something, generally involving a number of steps or operations." In software engineering, the phrase software process refers to the method of developing software. Software process teaches us how we can manage our planning according to the constraints and Boundaries. A software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced. The desired result is, as stated earlier, high-quality software at low cost. Clearly, a process does not scale up i.e., cannot handle large software projects or cannot produce good-quality software i.e., good-quality software is not the outcome is not a suitable process. In an organization whose major business is software development, there are typically many processes simultaneously executing. Many of these do not concern software engineering, though they do impact software development. These could be considered non-software engineering process models. Business process models, social process models, and training models, are all examples of processes that come under this. These processes also affect the software development activity but are beyond the purview of software engineering.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

The process that deals with the technical and management issues of software development is called a software process. Clearly, many different types of activities need to be performed to develop software. As different type of activities are being performed, which are frequently done by different people, it is better to view the software process as consisting of many in component processes, each consisting of a certain type of activity. Each of these component processes typically has a different objective, though these processes obviously cooperate with each other to satisfy the overall software engineering objective.

We know that in development process we have to pass through various phases, and after each phase we expect some defined and designed output. There are certain rules and logic and we must follow them step by step. The phases are performed in an order specified by the process model being followed. The main reason for having a phased process is that it breaks the problem of developing software into successfully performing a set of phases, each handling a different concern of software development. This ensures that the cost of development is lower than what it would have been if the whole problem was tackled together. Furthermore, a phased process allows proper checking for quality and progress at some defined points during the development (end of phases). Without this, one would have to wait until the end to see what software has been produced. Clearly, this will not work for large systems. Hence, for managing the complexity, project tracking, and quality, all the development processes consist of one set of phases. A phased development process is central to the software engineering approach for solving the software crisis.

3.3

Characteristics of a Software Process The fundamental objectives of a process are the same as that of software engineering namely, optimality and scalability. Optimality means that the process should be able to produce high-quality software at low cost, and scalability means that it should also be applicable for large software projects. To achieve these objectives, a process should have some properties.

1) Predictability Predictability of a process determines how accurately the outcome of following a process in a project can be predicted before the project is completed. Predictability can be considered a fundamental property of any process. Effective project management is essential for the success of a project, and effective project management revolves around the project plan. A project plan typically contains cost and schedule estimates for the

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

project, along with plans for quality assurance and other activities. Any estimation about a project is based on the properties of the project, and the capability or past experience of the organization. For example, a simple way of estimating cost could be to say, "this project X is very similar to the project Y that we did 3 years ago, hence X's cost will be very close to Y's cost." However, even this simple method implies that the process that will be used to develop project X will be same as the process used for project Y, and the process is such that following the process the second time will produce similar results as the first time. That is, this assumes that the process is predictable. If it was not predictable, then there is no guarantee that doing a similar project the second time using the process will incur a similar cost. It should be clear that if we want to use past experience to control costs and ensure quality, we must use a process that is predictable. With low predictability, the experience gained through projects is of little value. A predictable process is also said to be under statistical control. A process is under statistical control if following the same process produces similar results.

2) Process Improvement Process is also not a static entity it means we have to regularly improve the process according to the need. Improving the quality and reducing the cost of products are fundamental goals of any engineering discipline. In the context of software, as the productivity and quality are determined largely by the process, to satisfy the engineering objectives of quality improvement and cost reduction, the software process must be improved. Having process improvement as a basic goal of the software process implies that the software process used is such that it supports its improvement. This requires that there be means for evaluating the existing process and understanding the weaknesses in the process. Only when support for these activities is available can process improvement be undertaken. And, as in any evaluation, it is always preferable to have a quantifiable evaluation rather than a subjective evaluation. Hence, it is important that the process provides data that can be used to evaluate the current process and its weaknesses. Having process improvement as a fundamental objective requires that the software process be a closed-loop process. That is, the process must learn from previous experiences, and each project done using the existing process must feed information back into the process itself, which can then use this information for self-improvement. As stated earlier, this activity is largely done by the process management component of the software process. However, to support this activity, information from various other

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

processes will have to flow to the process management process. In other words, to support this activity, other processes will also have to take an active part.

3.4

Software Processes, Projects and Products: A software process specifies a method of developing software. A software project, on the other hand, is a development project in which a software process is used.ï¿½ Software products are the outcomes of a software project. Each software development project starts with some needs and (hopefully) ends with some software that satisfies those needs. A software process specifies the abstract set of activities that should be performed to go from user needs to the final product. The actual act of executing the activities for some specific user needs is a software project. And all the outputs that are produced while the activities are being executed are the products (one of which is the final software). One can view the software process as an abstract type, and each project is done using that process as an instance of this type. In other words, there can be many projects for a process i.e., many projects can be done using a process, and there can be many products produced in a project. This relationship is shown in the following figure The sequence of activities specified by the process is typically at an abstract level because they have to be usable for a wide range of projects. Hence, "implementing" them in a project is not straightforward. To clarify this, let us take the example of traveling. A process for traveling to a destination will be something like this: Set objectives for the travel (tourism, business, meeting friends, etc.), determine the optimal means of traveling which will depend on the objective, if driving is best determine what type of vehicle is most desired; car, truck, or camper, get a detailed map to reach the destination, plan details of the trip, get sufficient money, rent the car, etc. If flying to the destination is best, then book flights, reserve a car at the destination if needed, etc. In a sense, the process provides a "checklist," with an ordering constraint e.g., renting a car as a first step is sub optimal. If one has to go from New York to California (a specific project), then even with this process, a considerable effort is required to reach California. And this effort is not all passive; one has to be alert and active to achieve this goal e.g., preparing a map and following the map are not passive or trivial tasks.

3.5

Design Concept and Modeling Design, it is a meaningful representation of something that is to be built. It is based on user requirement as well as the quality of the design should be good against some predefined criteria analysed during software requirement specification. Design provides a structured and refined view to the software specification. Software requirement specification is a mean of translating the ideas in the minds of the clients into

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

a formal document. The preparation of software requirement specification forces rigorous specification of the requirement before the design begins. It also provide flexibility to design. Design begins with the requirement model. During design the requirement model transforms into four levels of design detail ï¿½ the data structure, the system architecture, the interface representation and the component level detail. During each design activity basic design concepts and principles are applied that gives high quality software.

3.6

Concepts A design methodology is a systematic approach to creating a design by application of a set of techniques and guidelines. The design process often have two levels, at the first level the focus is one deciding which modules are needed for the system, the specification of these modules and how these module should be interconnected. This is called System Design or Top Level Design. At the second level, the internal design of the modules that is how the specification of the module can be satisfied is decided upon. The design level is often called Detailed Design or Logic Design. A set of basic software design concepts evolved over the past decades. Every concept provides the designer a base to produce good quality software. It also provide the necessary framework for ï¿½getting it rightï¿½ that is how a software proved to be right.

3.7

Design Objectives The beginning of the design phase marks a transaction from describing what the solution looks like, ï¿½specificationsï¿½ to how the problem is going to be solved.ï¿½ The design document that we will develop during this phase is the blueprint of the software.ï¿½ It describes how the solution to the customer problem is to be built. Since solution to complex problems isnï¿½t usually found in the first try, iterations are most likely required.ï¿½ This is true for software design as well.ï¿½ For this reason, any design strategy, design method, or design language must be flexible and must easily accommodate changes due to iterations in the design. Complex problems arenï¿½t usually solved in one step.ï¿½ Rather, they are solved using the principle of ï¿½divide and conquer,ï¿½ where the problem is divided into a set of sub-problems that are solved more easily. The partial solutions are than combined to become an overall problem solution.ï¿½ Any technique or design needs to support and guide the partitioning process in such a way that the resulting sub-problems are as independent as possible from each other and can be combined easily for the solution to the overall problem. Sub-problem independence and easy combination of their solutions

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

reduces the complexity of the problem. This is the objective of the partitioning process. Partitioning or decomposition during design involves three types of decisions: Define the boundaries along which to break; Determine into how money pieces to break; and Identify the proper level of detail when design should stop and implementation should start. Basic design principles that enable the software engineer to navigate the design process suggest a set of principles for software design, which have been adapted and extended in the following list: Free from the suffer from "tunnel vision." A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job. The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model. The design should not repeat the same thing. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist. The design should "minimize the intellectual distance" between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain. The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components. The design activity begins when the requirements document for the software to be developed is available. This may be the SRS for the complete system, as is the case if the waterfall model is being followed or the requirements for the next "iteration" if the iterative enhancement is being followed or the requirements for the prototype if the prototyping is being followed. While the requirements specification activity is entirely in the problem domain, design is the first step in moving from the problem domain toward

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

the solution domain. Design is essentially the bridge between requirements specification and the final solution for satisfying the requirements. The design of a system is essentially a blueprint or a plan for a solution for the system. We consider a system to be a set of components with clearly defined behavior that interacts with each other in a fixed defined manner to produce some behavior or services for its environment. A component of a system can be considered a system, with its own components. In a software system, a component is a software module. The design process for software systems, often, has two levels. At the first level, the focus is on deciding which modules are needed for the system, the specifications of these modules, and how the modules should be interconnected. This is what is called the system design or top-level design. In the second level, the internal design of the modules, or how the specifications of the module can be satisfied, is decided. This design level is often called detailed design or logic design. Detailed design essentially expands the system design to contain a more detailed description of the processing logic and data structures so that the design is sufficiently complete for coding. Because the detailed design is an extension of system design, the system design controls the major structural characteristics of the system. The system design has a major impact on the testability and modifiability of a system, and it impacts its efficiency. Much of the design effort for designing software is spent creating the system design. The input to the design phase is the specifications for the system to be designed. Hence, a reasonable entry criteria can be that the specifications are stable and have been approved, hoping that the approval mechanism will ensure that the specifications are complete, consistent, unambiguous, etc. The output of the top-level design phase is the architectural design or the system design for the software system to be built. This can be produced with or without using a design methodology. A reasonable exit criteria for the phase could be that the design has been verified against the input specifications and has been evaluated and approved for quality. A design can be object-oriented or function-oriented. In function-oriented design, the design consists of module definitions, with each module supporting a functional abstraction. In object-oriented design, the modules in the design represent data abstraction (these abstractions are discussed in more detail later). In the functionoriented methods for design and describe one particular methodology the structured design methodology in some detail. In a function- oriented design approach, a system is viewed as a transformation function, transforming the inputs to the desired outputs. The purpose of the design phase is to specify the components for this transformation function,

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

so that each component is also a transformation function. Hence, the basic output of the system design phase, when a function oriented design approach is being followed, is the definition of all the major data structures in the system, all the major modules of the system, and how the modules interact with each other. 3.8

Design Principles The design process is a sequence of steps that enables the designer to describe all aspects of the software to be built upon. Basic design principles enable the software engineer to navigate the design process. The principles adopted for software design are: 

The design should be uniform that is rules and format should be defined for a design team before design begins.



A design should be integrated so that if the individual component or modules are combined then they should meet the user requirement. The interfaces between the component should be defined carefully.



The design should minimize the intellectual distance between the software and the problem as it exists in the real world.



The design should be traceable to the analysis model.



The design should be reviewed to minimize the conceptual error.



The design should be assessed for quality as it is being created, not after the fact.



The design should be structured to degrade gently, even when aberrant data, events or operating conditions are encountered.



The design should be flexible enough to accommodate the changes.



When all the design principles are properly applied, the software engineer creates a design that exhibits both external and internal quality factor.

3.9

Software engineering process models Process model is a strategy which is used by software engineer or a team of engineers that encompasses the process, methods, and tools. Various models used in industry are:

3.10



Water fall model



Prototype model



Iterative enhancement model



Spiral model

Water fall model This model was popularized in the 1970ï¿½s. The essence of this model is that the process of software development consists of a set of distinct phases. This phased model segments the software life cycle into a series of successive activities.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING a)

Requirement and Analysis - This stage includes a detailed study of the business needs of the organization and gathers the requirements for the system. Since every problem has it誰多遜s specific nature and for solving it, we have to analyze the problem in a certain manner so that we can get the correct solution. Requirements analysis is done in order to understand the problem the software system has to solve. The problem could be automating an existing manual process, developing a new automated system, or a combination of the two. For large systems that have many features, and that need to perform many different tasks, understanding the requirements of the system is a major task. The emphasis in requirements analysis is on identifying what is needed from the system, not how the system will achieve its goals. Involvement of end users is typically passive and principally in the analysis stage.

Design - The purpose of the design phase is to plan a solution of the problem specified by the requirements document. In this phase we have to make sure that the steps designed for getting the solution are complete and can achieve the goal. This focuses on high level design (what programs are we going to need and how are they going to interact), low level design (how the individual programs are going to work), interface design (what are the interfaces going to look like) and data design (what data are we going to need). The output of this phase is the design document. At the end of system design all the major data structures, file formats, output formats, and the major modules in the system and their specifications are decided.

Implementation (Coding) - The designs are translated into code. Computer programs may be written using a conventional programming language to a fourth generation language (4GL) or an application generator. The goal of the coding phase is to translate the design of the system into code in a given programming language. For a given design, the aim in this phase is to implement the design in the best possible manner. During coding the focus should be on developing programs that are easy to read and understand, and not simply on developing programs that are easy to write. Simplicity and clarity should be strived for during the coding phase.

誰#Testing - Normally programs are written as a series of individual modules. These should be subject to separate and detailed test. The system is then tested as a whole - the separate modules are brought together and tested as a complete system. Testing is a process to maintain the quality control measure used during

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

software development. Its basic function is to detect errors in the software. Testing is a process to maintain the quality control measure used during software development. Its basic function is to detect errors in the software. The system needs to be tested to ensure that interfaces between modules work, the system works on the intended platform and with the expected volume of data and that the system does what the user requires.

3.11

Characteristics of Waterfall model Specific activities, techniques and outcomes are associated with each stage; Progression between stages is orderly and proceeds in a linear fashion; Viewed to be a process driven by technicians; Monitoring and control takes place at the end of each stage;

3.12

Advantages and Limitations of Waterfall Model Easy to explain the advantage to the user Stages and activities are well defined Ensures that information required is obtained as and when it needs to be used Helps to plan and schedule project Verification at each stage ensures early detection of errors / misunderstanding Minimize the cost of rectifying errors. Limitation of waterfall model: This model is suitable to automate for which all requirements are known before the design starts. The waterfall model does not accommodate times. Waterfall model is document driven. It does not incorporate any kind of risk assessment.

3.13

Prototype Model It is also known as evolutionary model. Prototyping is the process of developing scaled down version of a system. It begins with requirements gathering. Developers and client meet and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. The prototype is a working model that can be used for several purposes such as: Validating the userï¿½s requirements Performing a feasibility study of a complex system Arriving at the functional specifications of a system Establishing a starting point of further evolution

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

The goal of a prototyping-based development process is to counter the limitations of the waterfall model. The basic idea is that instead of freezing the requirements before any design or coding can proceed, a throwaway prototype is built to help understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding, and testing, but each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an actual feel of the system, because the interactions with the prototype can enable the client to better understand the requirements of the desired system. This results in more stable requirements that change less frequently. The development of the prototype starts when the preliminary version of the requirements specification document has been developed. At this stage, there is a reasonable understanding of the system and its needs and of which needs are unclear or likely to change. After the prototype has been developed, the end users and clients are given an opportunity to use the prototype and use it. Based on their experience, they provide feedback to the developers regarding the prototype: what is correct, what needs to be modified, what is missing, what is not needed, etc. Based on the feedback, the prototype is modified to incorporate some of the suggested changes that can be done easily, and then the users and the clients are again allowed to use the system. This cycle repeats until, in the judgment of the prototypers and analysts, the benefit from further changing the system and obtaining feedback is outweighed by the cost and time involved in making the changes and obtaining the feedback. Based on the feedback, the initial requirements are modified to produce the final requirements specification, which is then used to develop the production quality system. It is well suited for projects where requirements are hard to determine and the confidence in obtained requirements is low. In such projects, a waterfall model will have to freeze the requirements in order for the development to continue, even when the requirements are not stable.

3.14

Advantages and Limitations It is a technique that allow for a reduced functionality or limited performance It serves as a mechanism for identifying software requirements. It is well suited for projects where the requirements are hard to determine. It is an excellent technique for reducing risks associated with a project.

Limitations: 

Limited functional capabilities



Low reliability



Untested performance

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 

3.15

Prototyping tools are expensive

Prototypeï¿½s effect on software development cost It reduces the cost of later phases of the product development. The final system developed will be more closer to the actual requirement because the user and developer gets involved in refining the system. Requirement obtained after having the working experience with the prototype tends to be more stable.

3.16

Iterative Enhancement Model The iterative model combines the features of both waterfall and prototype model. It supports the incremental building of the new system. This model can be useful if the core of the application is well understood and increments can be easily defined and negotiated .In client-oriented projects, it is an advantage to the client can pay to the projects in installments .The potential danger of this method is that the iteration may never end the user may never really get the "final" product. The basic idea of this model is that the software should be developed in increments, each increment adding some functional capability to the system until the full system is implemented. At each step, extensions and design modifications can be made. An advantage of this approach is that it can result in better testing because testing each increment is likely to be easier than testing the entire system as in the waterfall model. Furthermore, as in prototyping, the increments provide feedback to the client that is useful for determining the final requirements of the system. In the first step of this model, a simple initial implementation is done for a subset of the overall problem. This subset is one that contains some of the key aspects of the problem that are easy to understand and implement and which form a useful and usable system. A project control list is created that contains, in order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system. Each step consists of removing the next task from the list, designing the implementation for the selected task, coding and testing the implementation, performing an analysis of the partial system obtained after this step, and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase, and analysis phase. The process is iterated until the project control list is empty, at which time the final implementation of the system will be available. One effective use of this type of model is of product development, in

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

which the developers themselves provide the specifications and therefore have a lot of control on what specifications go in the system and what stay out.

3.17

Spiral Model This model proposed by Barry Boem in 1988.It incorporates the elements of the prototype driven approach along with the classic software life cycle. The four major activities of each spiral are represented by the four quadrants: PLANNING determination of objectives, alternatives and constraints. RISK ANALYSIS analysis of alternatives andï¿½ identification/resolving of risks. ENGINEERING - Development of the next level product CUSTOMER EVALUTION - Assessment of the result of re-engineering.

The radial dimension represents the cumulative cost incurred in accomplishing the steps done so far, and the angular dimension represents the progress made in completing each cycle of the spiral. Each cycle in the spiral begins with the identification of objectives for that cycle the different alternatives that are possible for achieving the objectives, and the constraints that exist. This is the first quadrant of the cycle (upper-left quadrant). The next step in the cycle is to evaluate these different alternatives based on the objectives and constraints. The focus of evaluation in this step is based on the risk perception for the project. Risks reflect the chances that some of the objectives of the project may not be met. The next step is to develop strategies that resolve the uncertainties and risks. This step may involve activities such as benchmarking, simulation, and prototyping. Next, the software is developed, keeping in mind the risks. Finally the next stage is planned.

The risk-driven nature of the spiral model allows it to accommodate any mixture of a specification-oriented, prototype-oriented, simulation-oriented, or some other type of approach. An important feature of the model is that each cycle of the spiral is completed by a review that covers all the products developed during that cycle, including plans for the next cycle. The spiral model works for development as well as enhancement projects.

3.18

Cocomo Model Instead of having resource estimates as a function of one variable, resources estimates can depend on many different factors, giving rise to multivariable models. One approach for building multivariable models is to start with an initial estimate determined by using the static single-variable model equations, which depend on size, and then adjusting the estimates based on other variables. This approach implies that size is the primary factor

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

for cost; other factors have a lesser effect. Here we will discuss one such model called the Constructive Cost Model (COCOMO). This model also estimates the total effort in terms of person-months of the technical project staff. The effort estimate includes development, management, and support tasks but does not include the cost of the secretarial and other staff that might be needed in an organization. The basic steps in this model are: 1. Obtain an initial estimate of the development effort from the estimate of thousands of delivered lines of source code (KDLOC). 2. Determine a set of 15 multiplying factors from different attributes of the project. 3. Adjust the effort estimate by multiplying the initial estimate with all the multiplying factors.

The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single-variable models, using KDLOC as the measure of size. To determine the initial effort Ei in person-months the equation used is of the type Ei = a * (KDLOC)b.

The value of the constants a and b depend on the project type. In COCOMO, projects are categorized into three types -- organic, semidetached, and embedded. Organic projects are in an area in which the organization has considerable experience and requirements are less stringent. A small team usually develops such systems. Examples of this type of project are simple business systems, simple inventory management systems, and data processing systems. Projects of the embedded type are ambitious and novel; the organization has little experience and stringent requirements for such aspects as interfacing and reliability. These systems have tight constraints from the environment (software, hardware, and people). Examples are embedded avionics systems and realtime command systems. The semidetached systems fall between these two types. Examples of semidetached systems include developing a new operating system (OS), a database management system (DBMS), and a complex inventory management system. The constants a and b for different systems are given in Table 1.1.

There are 15 different attributes, called cost driver attributes, that determine the multiplying factors. These factors depend on product, computer, personnel, and technology attributes (called project attributes). Examples of the attributes are required software reliability (RELY), product complexity (CPLX), analyst capability (ACAP), application experience (AEXP), use of modern tools (TOOL), and required development schedule (SCHD). Each cost driver has a rating scale, and for each rating, a multiplying

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

factor is provided. For example, for the product attribute RELY the rating scale is very low, low, nominal, high, and very high (and in some cases extra high). The multiplying factors for these ratings are .75, .88, 1.00, 1.15, and 1.40, respectively. So, if the reliability requirement for the project is judged to be low then the multiplying factor is .75, while if it is judged to be very high the factor is 1.40. The attributes and their multiplying factors for different ratings are shown in Table 1.2. The COCOMO approach also provides guidelines for assessing the rating for the different attributes.

Table 1.1: Constants for different project types

System

Organic

3.2

1.05

Semidetached

3.0

1.12

Embedded

2.8

1.20

Table 1.2: Effort multipliers for different cost drivers.

The multiplying factors for all 15 cost drivers are multiplied to get the effort adjustment factor (EAF). The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF:

E = EAF * Ei As we discussed earlier, the value of the constants for a cost model depend or the process and thus have to be determined from past data about the usage of that process. COCOMO has instead provided "global" constant values. This might work because it requires some characteristics about the process (e.g., it is well managed) and it provides some means to fine-tune the estimate for a particular process. For example, if the process relies less on tools, the estimate can be "corrected" for this type of process by suitably choosing the value for the TOOL attribute.

Still, there is little data to support that these constants are globally applicable, and to apply COCOMO in an environment, these may need to be tailored for the specific environment. One way is to start with the COCOMO-supplied constants until data for some completed projects is available. With this data, by keeping the exponent in the

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

equations for initial effort estimate fixed, the value of the other constant can be determined through regression analysis so that the data best fits the equation. This will be a simpler regression analysis as only one constant has to be determined rather than two in the standard regression line fitting discussed earlier. With more data, the value of the exponent can also be fine-tuned. Changing both constants together requires a lot more data for regression analysis to be significant. For a particular process or environment, all the attributes might not be significant, and it might be possible to merge some of them into a single attribute.

By this method, the overall cost of the project can be estimated. For planning and monitoring purposes, estimates of the effort required for the different phases are also desirable. In COCOMO, effort for a phase is considered a defined percentage of the overall effort. The percentage of total effort spent in a phase varies with the type and size of the project. The percentages for an organic software project are given in Table 1.3.

Using this table, the estimate of the effort required for each phase can be determined from the total effort estimate. For example, if the total effort estimate for an organic software system is 20 PM, then the percentage effort for the coding and unit testing phase will be 40 + (38 -40)/(32 -8) * 20 -39%. The estimate for the effort needed for this phase is 7.8 PM. This table does not list the cost of requirements as a percentage of the total cost estimate because the project plan (and cost estimation) is being done after the requirements are complete. In COCOMO the detailed design and code and unit testing are sometimes combined into one phase called the programming phase.

For the other two types of software systems, the percentages are slightly different, with the percentage for product design and integration and testing increasing slightly and the percentage of coding decreasing slightly. COCOMO provides three levels of models of increasing complexity: basic, intermediate, and detailed. The model described earlier is the intermediate COCOMO model. The detailed model is the most complex. It has different multiplying factors for the different phases for a given cost driver. The set of cost drivers applicable to a system or module is also not the same as the drivers for the system level. However, it might be too detailed for many applications. We will follow the intermediate model described earlier, even for detailed estimates. COCOMO also provides help in determining the rating of different attributes and performing sensitivity and trade-off analysis.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 3.19

Summary

Software systems come and go through a series of passages that account for their inception, initial development, productive operation, upkeep, and retirement from one generation to another. This article categorizes and examines a number of methods for describing or modeling how software systems are developed. It begins with background and definitions of traditional software life cycle models that dominate most textbook discussions and current software development practices. This is followed by a more comprehensive review of the alternative models of software evolution that are of current use as the basis for organizing software engineering projects and technologies.

These classic software life cycle models usually include some version or subset of the following activities: _

System Initiation/Planning: where do systems come from? In most situations, new feasible

systems

replace

supplement

existing

information

processing

mechanisms whether they were previously automated, manual, or informal. _

Requirement Analysis and Specification: identifies the problems a new software system is suppose to solve, its operational capabilities, its desired performance characteristics, and the resource infrastructure needed to support system operation and maintenance.

Functional Specification or Prototyping: identifies and potentially formalizes the objects of computation, their attributes and relationships, the operations that transform these objects, the constraints that restrict system behavior, and so forth.

Partition and Selection (Build vs. Buy vs. Reuse): given requirements and functional specifications, divide the system into manageable pieces that denote logical subsystems, then determine whether new, existing, or reusable software systems correspond to the needed pieces.

Architectural Design and Configuration Specification: defines the interconnection and resource interfaces between system subsystems, components, and modules in ways suitable for their detailed design and overall configuration management.

Detailed Component Design Specification: defines the procedural methods through which the data resources within the modules of a component are transformed from required inputs into provided outputs.

Component Implementation and Debugging: codifies the preceding specifications into operational source code implementations and validates their basic operation.

Software Integration and Testing: affirms and sustains the overall integrity of the software system architectural configuration through verifying the consistency and completeness of implemented modules, verifying the resource interfaces and

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

interconnections against their specifications, and validating the performance of the system and subsystems against their requirements. _

Documentation Revision and System Delivery: packaging and rationalizing recorded system development descriptions into systematic documents and user guides, all in a form suitable for dissemination and system support.

Deployment and Installation: providing directions for installing the delivered software into the local computing environment, configuring operating systems parameters and user access privileges, and running diagnostic test cases to assure the viability of basic system operation.

Training and Use: providing system users with instructional aids and guidance for understanding the system's capabilities and limits in order to effectively use the system.

Software Maintenance: sustaining the useful operation of a system in its host/target environment

providing

requested

functional

enhancements,

repairs,

performance improvements, and conversions.

3.20

Self Test 1) Describe Waterfall model. -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2) Differentiate between waterfall model & iterative model. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

3) Write a short note on COCOMO model ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -----------------------------------

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

4) Write a short note on Prototype model. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Unit 4 Project Scheduling And Tracing Structure 4.1

Chapter Objective

4.2

Software Project Planning

4.3

Estimation of a Project

4.4

Cost Estimation

4.5

Building Cost Estimation Models

4.6

Process-Based Estimation

4.7

Project Scheduling and tracing

4.8

Design Tools and Techniques

4.9

Structure Charts

4.10

Gantt Charts

4.11

Activity Networks

4.12

Structured Design Methodology

4.13

Identify the Input and Output Data Elements

4.14

Summary

4.15

Self Test

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 4.1

Chapter Objective After completion of this chapter, you should be able to understand :

4.2



Software project planning steps



Software project estimations



Cost based and process based estimations



Project scheduling tools



Charts and networks for scheduling

Software Project Planning It is the responsibility of the project manager to make accurate estimations of effort and cost. This is particularly true for projects subject to competitive bidding where a bid too high compared with competitors would result in loosing the contract or a bid too low could result in a loss to the organization. This does not mean that internal projects are unimportant. From a project leaders estimate the management often decide whether to proceed with the project. Industry has a need for accurate estimates of effort and size at a very early stage in a project. However, when software cost estimates are done early in the software development process the estimate can be based on wrong or incomplete requirements. A software cost estimate process is the set of techniques and procedures that an organization use to arrive at an estimate. An important aspect of software projects is to know the cost. The major contributing factor is effort.

4.3

Estimation of a Project Estimation is an important aspect since our plan should be such that, so we should we able to complete the task within the organization constraints. Project complexity has a strong effect on the uncertainty inherent in planning. Complexity, however, is a relative measure that is affected by familiarity with past effort. The first-time developer of a sophisticated e-commerce application might consider it to be exceedingly complex. However, a software team developing its tenth e-commerce Web site would consider such work very easy. A number of quantitative software complexity measures have been proposed. Such measures are applied at the design or code level and are therefore difficult to use during software planning (before a design and code exist). However, other, more subjective assessments of complexity can be established early in the planning process. Project size is another important factor that can affect the accuracy and efficacy of estimates. As size increases, the interdependency among various elements of the software grows rapidly. Problem decomposition, an important approach to estimating, becomes more difficult because decomposed elements may still be formidable.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

The degree of structural uncertainty also has an effect on estimation risk. In this context, structure refers to the degree to which requirements have been solidified, the ease with which functions can be compartmentalized, and the hierarchical nature of the information that must be processed. Risk is measured by the degree of uncertainty in the quantitative estimates established for resources, cost, and schedule. If project scope is poorly understood or project requirements are subject to change, uncertainty and risk become dangerously high. The software planner should demand completeness of function, performance, and interface definitions (contained in a System Specialization). The planner, and more important, the customer should recognize that variability in software requirements means instability in cost and schedule. However, a project manager should not become obsessive about estimation. Modern software engineering approaches take an iterative view of development. In such approaches, it is possible to revisit the estimate (as more information is known) and revise it when the customer makes changes to requirements. 4.4

Cost Estimation For a given set of requirements it is desirable to know how much it will cost to develop the software to satisfy the given requirements, and how much time development will take. These estimates are needed before development is initiated. The primary reason for cost and schedule estimation is to enable the client or developer to perform a cost-benefit analysis and for project monitoring and control. A more practical use of these estimates is in bidding for software projects where the developers must give cost estimates to a potential client for the development contract.

As we specify the system more fully and accurately, the uncertainties are reduced and more accurate estimates can be made. For example, once the requirement are completely specified, more accurate cost estimates can be made compared to the estimates after the feasibility study. Once the design is complete, the estimate can be made still more accurately. The obtainable accuracy of the estimates as varies with the different phases is shown in the following figure.

Note that this figure is simply specifying the limitations of cost estimating strategies the best accuracy a cost estimating strategy can hope to achieve. It does say anything about the existence of strategies that can provide the estimate with that accuracy. For actual cost estimation, cost estimation models or procedure have to be developed. The

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

accuracy of the actual cost estimates will depend on the effectiveness and accuracy of the cost estimation procedures or models employed and the process i.e., how predictable it is. Despite the limitations, cost estimation models have matured considerably and generally give fairly accurate estimates. For example, when the COCOMO model was checked with data from some projects, it was found that the estimates were within 20% of the actual cost 68% of the time. It should also be mentioned that achieving a cost estimate after the requirements have been specified within 20% is actually quite good. With such an estimate, there need not even be any cost and schedule overruns, as there is generally enough slack or free time available that can be used to meet the targets set for the project based on the estimates. In other words, if the estimate is within 20%, the effect of this inaccuracy will not even be reflected in the final cost and schedule. 4.5

Building Cost Estimation Models Any cost estimation model can be viewed as a "function" that outputs the cost estimate. As the cost of a project (for the process that is to be followed) depends on the nature of the project, clearly this cost estimation function will need inputs about the project, from which it can produce the estimate. The basic idea of having a model or procedure for cost estimation is that it reduces the problem of estimation to estimating or determining the value of the "key parameters" that characterize the project, based on which the cost can be estimated. The problem of estimation, not yet fully solved, is determining the "key parameters" whose value can be easily determined (especially in the early phases) and how to get the cost estimate from the value of these. Though the cost for a project is a function of many parameters, it is generally agreed that the primary factor that controls the cost is the size of the project that is, the larger the project the greater the cost and resource requirement. Other factors that affect the cost include programmer ability, experience of the developers in the area, complexity of the project, and reliability requirements. In some studies it has been found that programmer ability can have productivity variations of up to a factor of ten. Product complexity has an effect on development effort, as more complex projects that are the same size as simpler projects require more effort. Similarly, reliability requirements have considerable impact on cost; the more the reliability need, the higher the development cost. In fact, the cost increase with reliability is not linear and is often exponential. The goal of a cost model is to determine which of these many parameters have a "significant" effect on cost and then to discover the relationships between the cost and these characteristics. These characteristics should be such that we can measure or

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

estimate them accurately. The most common approach for determining the significant parameters and their relationship to cost is to build models through regression analysis, where cost is the dependent variable and the parameters are the independent variables. As this approach uses historical data to predict future data points, this approach has one clear implication. This approach can be applied only if the process is under statistical control. If this is not the case, then the past is no reflection of the future, and a regression-type model cannot be used. It also follows that the cost models are processdependent, as they should be; the cost of developing a software is more if an inefficient process is followed. The most common approach for estimating effort is to make it a function of a single variable (this is also the simplest from the point of view of model building). Often this variable is the project size, and the equation of effort is considered EFFORT = a * SlZE (b), where a and b are constants. Values for these constants for a particular process are determined through regression analysis, which is applied to data about the projects that has been performed in the past. For example, on analyzing the data of more than 60 projects done at IBM Federal Systems Division, ranging from 4000 to 467000 lines of delivered source code, it was found that if the size estimate is in thousands of delivered lines of code (KDLOC), the total effort, E, in person-months (PM) can be given by the equation E=-5.2(KDLOC)X0.91. A similar study on smaller projects showed that the data fits a straight line quite well, and the equation is of the form , EFFORT=a * SIZE + b, where a and b are again constants obtained by analysis of data of past projects. These equations suggest that the project cost increases linearly with the size of the final product for small systems but has nonlinear growth for larger projects. These models have used LOC as the size measure. Similar models have been developed with function point as the size measure. The process of constructing the model is the same-regression analysis on function point size and cost of previously completed projects. An advantage of using function points is that the size in FP can be calculated, while size in LOC will require size estimation can be done. However, function point calculation also involves subjectivity. Due to this, the FP count is not uniquely determined even at the end of the project, unlike the LOC count, which makes the task of getting] accurate and consistent data on past projects harder. Note that most of these

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

models will not work for very small projects because for such projects factors other than size become far more important. 4.6

Process-Based Estimation The most common technique for estimating a project is to base the estimate on the process that will be used. That is, the process is decomposed into a relatively small set of tasks and the effort required to accomplish each task is estimated. Like the problem-based techniques, process-based estimation begins with a delineation of software functions obtained from the project scope. A series of software process activities must be performed for each function. Functions and related software process activities may be represented as part of a table similar to the one. Once problem functions and process activities are decided, the planner estimates the effort (e.g., person-months) that will be required to accomplish each software process activity for each software function. These data constitute the central matrix of the table. Average labour rates (i.e., cost/unit effort) are then applied to the effort estimated for each process activity. It is very likely the labour rate will vary for each task. Senior staff heavily involved in early activities are generally more expensive than junior, staff involved in later design tasks, code generation, and early testing.

Costs and effort for each function and software process activity are computed as the last step. If process-based estimation is performed independently of LOC or FP estimation, we now have two or three estimates for cost and effort that may be compared and reconciled. If both sets of estimates show reasonable agreement, there is good reason to believe that the estimates are reliable. If, on the other hand, the results of these decomposition techniques show little agreement, further investigation and analysis must be conducted.

4.7

Project Scheduling and tracing Project scheduling is concerned with the techniques that can be employed to manage the activities that need to be undertaken during the development of a project. Scheduling is carried out in advance of the project commencing and involves: 

identifying the tasks that need to be carried out



estimating how long they will take



allocating resources (mainly personnel)



scheduling when the tasks will occur

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

Schedule estimation and staff requirement estimation may be the most important activities after cost estimation. The goal of schedule estimation is to determine the total duration of the project and the duration of the different phases. A schedule cannot be simply obtained from the overall effort estimate by deciding on average staff size and then determining the total time requirement by dividing the total effort by the average staff size. Brooks has pointed out that person and months (time) are not interchangeable. Man and months are interchangeable only for activities that require no communication among men, like sowing wheat or Leaping cotton.

Once the project is underway control needs to be exerted to ensure that the plan continues to represent the best prediction of what will occur in the future: based on what occurs during the development; often necessitates revision of the plan.

Effective project planning will help to ensure that the systems are delivered: within cost; within the time constraint; to a specific standard of quality.

4.8

Design Tools and Techniques During the design phase there are two things of interest: the design of the system, producing which is the basic objective of this phase, and the process of designing itself. It is for the latter that principles and methods are needed. In addition, while designing, a designer needs to record his thoughts and decisions and to represent the design so that he can view it and play with it. For this, design notations are used. Design notations are largely meant to be used during the process of design and are used to represent design or design decisions. They are meant largely for the designer so that he can quickly represent his decisions in a compact manner that he can evaluate and modify. These notations are frequently graphical. Once the designer is satisfied with the design he has produced, the design is to be precisely specified in the form of a document. To specify the design, specification languages are used. Producing the design specification is the ultimate objective of the design phase. The purpose of this design document is quite different from that of the design notation. Whereas a design represented using the design notation is largely to be used by the designer, a design specification has to be so precise and complete that it can be used as a basis of further development by other programmers. Generally, design specification uses textual structures, with design notation helping understanding.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 4.9

Structure Charts For a function-oriented design, the design can be represented graphically by structure charts. The structure of a program is made up of the modules of that program together with the interconnections between modules. Every computer program has a structure, and given a program its structure can be determined. The structure chart of a program is a graphic representation of its structure. In a structure chart a module is represented by a box with the module name written in the box. An arrow from module A to module B represents that module A invokes module B. B is called the subordinate of A, and A is called the super ordinate of B. The arrow is labeled by the parameters received by B as input and the parameters returned by B as output, with the direction of flow of the input and output parameters represented by small arrows. The parameters can be shown to be data (unfilled circle at the tail of the label) or control (filled circle at the tail). As an example consider the structure of the following program, whose structure is shown in Figure below. main() { int sum, n, N, a[MAX], j; readnums(a, &N); sort(a, N); scanf(&n); sum = add_n(a, n); ï¿½ï¿½ï¿½ï¿½ï¿½ printf(sum); } readnums(a, N) int a[], *N; { } sort(a, N) int a [], N; { if (a[i] > a[t]) switch(a[i] , a[t]); } /* Add the first n numb~rs of a */ add_n(a, n) int a [], n; { }

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

In general, procedural information is not represented in a structure chart, and the focus is on representing the hierarchy of modules. However, there are situations where the designer may wish to communicate certain procedural information explicitly, like major loops and decisions. Such information can also be represented in a structure chart. For example, let us consider a situation where module A has subordinates B, C, and D, and A repeatedly calls the modules C and D. This can be represented by a looping arrow around the arrows joining the subordinates C and D to A, as shown in Figure. All the subordinate modules activated within a common loop are enclosed in the same looping arrow.

Major decisions can be represented similarly. For example, if the invocation of modules C and D in module A depends on the outcome of some decision, that is represented by a small diamond in the box for A, with the arrows joining C and D coming out of this diamond, as shown in the above Figure. Modules in a system can be categorized into few classes. There are some modules that obtain information from their subordinates and then pass it to their super ordinate. This kind of module is an input module. Similarly, there are output modules that take information from their super ordinate and pass it on to its subordinates. As the name suggests, the input and output modules are typically used for input and output of data from and to the environment. The input modules get the data from the sources and get it ready to be processed, and the output modules take the output produced and prepare it for proper presentation to the environment. Then there are modules that exist solely for the sake of transforming data into some other form. Such a module is called a transform module. Most of the computational modules typically fall in this category. Finally, there are modules whose primary concern is managing the flow of data to and from different subordinates. Such modules are called coordinate modules. The structure chart representation of the different types of modules is shown in Figure. A module can perform functions of more than one type of module. For example, the composite module in Figure 4.4 is an input module from the point of view of its super ordinate, as it feeds the data Y to the super ordinate. Internally, A is a coordinate module and views its job as getting data X from one subordinate and passing it to another subordinate, which converts it to Y. Modules in actual systems are often composite modules.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

A structure chart is a nice representation mechanism for a design that uses functional abstraction. It shows the modules and their call hierarchy, the interfaces between the modules, and what information passes between modules. It is a convenient and compact notation that is very useful while creating the design. That is, a designer can make effective use of structure charts to represent the model he is creating while he is designing. However, it is not very useful for representing the final design, as it does not give all the information needed about the design. For example, it does not specify the scope, structure of data, specifications of each module, etc. Hence, it is generally not used to convey design to the implementer. We have seen how to determine the structure of an existing program. But once the program is written, its structure is fixed and little can be done about altering the structure. However, for a given set of requirements many different programs can be written to satisfy the requirements, and each program can have a different structure. That is, although the structure of a given program is fixed, for a given set of requirements, programs with different structures can be obtained. The objective of the design phase using function-oriented method is to control the eventual structure of the system by fixing the structure during design.

4.10

Gantt Charts Milestones mark significant events in the life of a project, usually critical activities which must be achieved on time to avoid delay in the project. Milestones should be truly significant and be reasonable in terms of deadlines (avoid using intermediate stages). Examples include: sdfsdinstallation of equipment; completion of phases file conversion cutover to the new system. A Gantt chart is a horizontal bar or line chart which will commonly include the following features: activities identified on the left hand side; time scale is drawn on the top (or bottom) of the chart; a horizontal open oblong or a line is drawn against each activity indicating estimated duration; dependencies between activities are shown; at a review point the oblongs are shaded to represent the actual time spent (an alternative is to represent actual and estimated by 2 separate lines); a vertical cursor (such as a transparent ruler) placed at the review point makes it possible to establish activities which are behind or ahead of schedule. Project management tools incorporating Gantt Charts include PRINCE [CCTA, 1990], MacProject and Microsoft Project. Example of a Gantt Chart:

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

ï¿½Example of a Gantt Chart Which tasks is ahead of schedule ? Which task is behind schedule ? Alternative Gantt Chart incorporating features commonly present in automated tools: Example of a Gantt Chart showing Project Management Tool Features Gantt charts produced in this form are: graphical; easy to read; easy to update. There are no widely accepted standards for Gantt charts. Automated tools are available which produce Gantt charts directly from activity networks or from a full definition of the tasks. Automated tools have features which assist the planning function including: display of original and latest time for task; display of person(s) allocated to tasks; integration with other planning techniques (i.e. networks and milestones). 4.11

Activity Networks The foundation of the approach came from the Special Projects Office of the US Navy in 1958. It developed a technique for evaluating the performance of large development projects, which became known as PERT - Project Evaluation and Review Technique. Other variations of the same approach are known as the critical path method (CPM) or critical path analysis (CPA). The heart of any PERT chart is a network of tasks needed to complete a project, showing the order in which the tasks need to be completed and the dependencies between them. This is represented graphically:

Example of an Activity Network The diagram consists of a number of circles, representing events within the development lifecycle, such as the start or completion of a task, and lines, which represent the tasks themselves. Each task is additionally labelled by its time duration. Thus the task between events 4 & 5 is planned to take 3 time units. The primary benefit is the identification of the critical path. The critical path = total time for activities on this path is greater than any other path through the network (delay in any task on the critical path leads to a delay in the project). Tasks on the critical path therefore need to be monitored carefully. The technique can be broken down into 3 stages: 1.

Planning: identify tasks and estimate duration of times; arrange in feasible sequence; draw diagram.

Scheduling: establish timetable of start and finish times.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING 3.

Analysis: establish float; evaluate and revise as necessary.

4.3.1 Diagram Symbols

Symbols Used in Activity Networks 4.3.2 To Produce the Diagram

There is a single start and end event; Time flows from left to right (so does the numbering sequence); Events are given a unique number (activities then have a unique label i.e. head & tail event numbers);

The network can then be drawn taking into account the dependencies identified;

Working from the start event forward, calculate the earliest times, setting the earliest time of the first event to zero. Add the job duration time to the earliest event time to arrive at the earliest time for the successor event. Where the successor has more than one activity dependent on to the latest time is entered;

Working from the finish event backwards, calculate the latest times. Set the latest time to the earliest time for the finish event. Subtract job duration from the latest time to obtain predecessor latest event times. Where the predecessor event has more than one arrow emanating from it enter the earliest time;

Event slack is calculated by subtracting the earliest event time from the latest event time; Critical path(s) are obtained by joining the events with zero event slack.

4.12

Structured Design Methodology Creating the software system design is the major concern of the design phase. Many design techniques have been proposed over the years to provide some discipline in handling the complexity of designing large systems. The aim of design methodologies is not to reduce the process of design to a sequence of mechanical steps but to provide guidelines to aid the designer during the design process. Here we describe the structured design methodology for developing system designs.

Structured design methodology (SDM) views every software system as having some inputs that are officered into the desired outputs by the software system. The software is

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

viewed as a transformation function that transforms the given inputs into the desired outputs, and the central problem of designing software systems is considered to be properly designing this transformation function. Due to this view of software, the structured design methodology is primarily function-oriented and relies heavily on functional abstraction and functional decomposition.

The concept of the structure of a program lies at the heart of the structured design method. During design, structured design methodology aims to control and influence the structure of the final program. The aim is to design a system so that programs implementing the design would have a nice hierarchical structure, with functionally cohesive modules and as few interconnections between modules as possible. In properly designed systems it is often the case that a module with subordinates does not actually perform much computation. The bulk of actual computation is performed by its subordinates, and the module itself largely coordinates the data flow between the subordinates to get the computation done. The subordinates in turn can get the bulk of their. work done by their subordinates until the "atomic" modules, which have no subordinates, are reached. Factoring is the process of decomposing a module so that the bulk of its work is done by its subordinates. A system is said to be completely factored if all the actual processing is accomplished by bottom-level atomic modules and if non atomic modules largely perform the jobs of control and coordination. SDM attempts to achieve a structure that is close to being completely factored.

The overall strategy is to identify the input and output streams and the primary transformations that have to be performed to produce the output. High-level modules are then created to perform these major activities, which are later refined. There are four major steps in this strategy: 

Restate the problem as a data flow diagram



Identify the input and output data elements



First-level factoring



Factoring of input, output, and transform branches

To use the SD methodology, the first step is to construct the data flow diagram for the problem. However, there is a fundamental difference between the DFDs drawn during requirements analysis and during structured design. In the requirements analysis, a DFD is drawn to model the problem domain. The analyst has little control over the problem, and hence his task is to extract from the problem all the information and then represent it as a DFD.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

During design activity, we are no longer modeling the problem domain, but rather are dealing with the solution domain and developing a model for the eventual system. That is, the DFD during design represents how the data will flow in the system when it is built. In this modeling, the major transforms or functions in the software are decided, and the DFD shows the major transforms that the software will have and how the data will flow through different transforms. So, drawing a DFD for design is a very creative activity in which the designer visualizes the eventual system and its processes and data flows. As the system does not yet exist, the designer has complete freedom in creating a DFD that will solve the problem stated in the SRS. The general rules of drawing a DFD remain the same; we show what transforms are needed in the software and are not concerned with the logic for implementing them. Consider the example of the simple automated teller machine that allows customers to withdraw money. A DFD for this ATM is shown in the following figure.

There are two major streams of input data in this diagram. The first is the account number and the code, and the second is the amount to be debited. The DFD is selfexplanatory. Notice the use of * at different places in the DFD. For example, the transform "validate," which verifies if the account number and code are valid, needs not only the account number and code, but also information from the system database to do the validation. And the transform debit account has two outputs, one used for recording the transaction and the other to update the account.

As another example, consider the problem of determining the number of different words in an input file. The data flow diagram for this problem is shown in figure given below.

This problem has only one input data stream, the input file, while the desired output is the count of different words in the file. To transform the input to the desired output, the first thing we do is form a list of all the words in the file. It is best to then sort the list, as this will make identifying different words easier. This sorted list is then used to count the number of different words, and the output of this transform is the desired count, which is then printed. This sequence of data transformation is what we have in the data flow diagram.

4.13

Identify the Input and Output Data Elements Most systems have some basic transformations that perform the required operations. However, in most cases the transformation cannot be easily applied to the actual physical

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

input and produce the desired physical output. Instead, the input is first converted into a form on which the transformation can be applied with ease. Similarly, the main transformation modules often produce outputs that have to be converted into the desired physical output. The goal of this second step is to separate the transforms in the data flow diagram that convert the input or output to the desired format from the ones that perform the actual transformations.

For this separation, once the data flow diagram is ready, the next step is to identify the highest abstract level of input and output. The most abstract input data elements are those data elements in the data flow diagram that are furthest removed from the physical inputs but can still be considered inputs to the system. The most abstract input data elements often have little resemblance to the actual physical data. These are often the data elements obtained after operations like error checking, data validation, proper formatting, and conversion are complete. Most abstract input (MAI) data elements are recognized by starting from the physical inputs and traveling toward the outputs in the data flow diagram, until the data elements are reached that can no longer be considered incoming. The aim is to go as far as possible from the physical inputs, without losing the incoming nature of the data element. This process is performed for each input stream. Identifying the most abstract data items represents a value judgment on the part of the designer, but often the choice is obvious.

Similarly, we identify the most abstract output data elements (MAO) by starting from the outputs in the data flow diagram and traveling toward the inputs. These are the data elements that are most removed from the actual outputs but can still be considered outgoing. The MAO data elements may also be considered the logical output data items, and the transforms in the data flow diagram after these data items are basically to convert the logical output into a form in which the system is required to produce the output.

There will usually be some transforms left between the most abstract input and output data items. These central transforms perform the basic transformation for the system, taking the most abstract input and transforming it into the most abstract output. The purpose of having central transforms deal with the most abstract data items is that the modules

implementing

these

transforms

can

concentrate

performing

the

transformation without being concerned with converting the data into proper format, validating the data, and so forth. It is worth noting that if a central transform has two

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING

outputs with a + between them, it often indicates the presence of a major decision in the transform (which can be shown in the structure chart).

Consider the data flow diagram shown in Figure (Word count problem). The arcs in the data flow diagram are the most abstract input and most abstract output. The choice of the most abstract input is obvious. We start following the input. First, the input file is converted into a word list, which is essentially the input in a different form. The sorted word list is still basically the input, as it is still the same list, in a different order. This appears to be the most abstract input because the next data (i.e., count) is not just another form of the input data. The choice of the most abstract output is even more obvious; count is the natural choice (a data that is a form of input will not usually be a candidate for the most abstract output). Thus we have one central transform, count-thenumber-of-different-words, which has one input and one output data item.

Consider now the data flow diagram of the automated teller. The two most abstract inputs are the dollar amount and the validated account number. The validated account number is the most abstract input, rather than the account number read in, as it is still the inputbut with a guarantee that the account number is valid. The two abstract outputs are obvious. The abstract inputs and outputs are marked in the data flow diagram.

4.14

Summary Project Schedule - The planned dates for performing activities and meeting milestones.

Project Management (PM) - The application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project.

Scheduling is the process of deciding how to commit resources between a variety of possible tasks. Time can be specified (scheduling a flight to leave at 8:00) or floating as part of a sequence of events.

Scheduling involves : 

entering/drawing up a timetable for the completion of various stages of a complex project;



the coordination of multiple related actions/tasks into a single time sequence;



a list of items to schedule (courses, events, meetings);

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTISING SOFTWARE ENGINEERING ď&#x201A;ˇ

a list of items that cannot be scheduled but may relate to calendaring (memos, address books, phone logs).

4.15

Self Test 1)

What are the basic steps in software project planning? -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Differentiate between cost based and process based cost estimation techniques. -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Explain Project Scheduling. --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Define Gantt Chart.

FOR MORE DETAILS VISIT US ON WWW.IMTSINSTITUTE.COM OR CALL ON +91-9999554621

ADVERTI SI NGSOFTWARE

ENGI NEERI NG

I ns t i t ut eo fMa na g e me nt & Te c hni c a lSt udi e s Addr e s s:E4 1 , Se c t o r 3 , No i da( U. P) www. i mt s i ns t i t ut e . c o m