software engineering

1

Unit 1

What is Software ?1. Instructions(computer programs) that when executed provide desired function and

performance,2. Data structures that enable the programs to adequately manipulate information and 3. Documents that describe the operation and use of the programs.

Software is a set of utility programs which are input and stored permanently in the computer system .

What are the characteristic of Software :1. Software is developed or engineered, it is not manufactured in the classical sense.2. Software doesn't “ware out”3. Most software is custom-built, rather than being assembled from existing components

What is software engineering?

Software engineering is an engineering discipline which is concerned with all aspects of software productionSoftware engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available

“A systematic approach to the analysis, design, implementation and maintenance of software.”

“ The systematic application of tools and techniques in the development of computer-based applications.”

“ Software Engineering is about designing and developing high-quality software.”

Difference between software engineering and software programming

Software programming-Single developer-“Toy” applications-Short lifespan-Single or few stakeholders Architect = Developer = Manager = Tester = Customer = User-One-of-a-kind systems-Built from scratch-Minimal maintenance

Software engineering-Teams of developers with multiple roles-Complex systems-Indefinite lifespan-Numerous stakeholders

2

Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User-System families-Reuse to amortize costs-Maintenance accounts for 60%-80% of overall development costs

Feasibility study

Feasibility Study : An important outcome of the preliminary investigation is the determination that the system requested is feasible . There are three aspects in the feasibility study portion of the preliminary investigation :

1. Technical Feasibility 2. Economic Feasibility3. Operating Feasibility

Technical Feasibility : Can the work of the project be done with current equipment , existing software technology , and available personnel ? If new technology is required , what is the likelihood that it can be developed?

Economic Feasibility : Are there sufficient benefits in creating the system to make the cost acceptable ? Or , are the costs of not creating the system so great that the project must be undertaken ?

Operational Feasibility : Will the system be used if it is developed and implemented ? Will there be resistance from users that will undermine the possible application benefits.

3

software development life cycle

Waterfall Prototyping Spiral Rapid Application Development model

Waterfall Model

Requirements – defines needed information, function, behavior, performance and interfaces. Design – data structures, software architecture, interface representations, algorithmic details. Implementation – source code, database, user documentation, testing. Test – check if all code modules work together and if the system as a whole behaves as per the

specifications. Installation – deployment of system, user-training. Maintenance – bug fixes, added functionality (an on-going process).

Waterfall Strengths Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track)

Prototyping Model Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype When the user is satisfied, the prototype code is brought up to the standards needed for a final

product.Steps in prototyping :

1. Identify the user’s known information requirements and features needed in the system.2. Develop a working prototype.3. Use the prototype , noting needed enhancements and changes.These expand the list of known

system requirements.4. Revise the prototype based in information gained through user experience.5. Repeat these steps as needed to achieve a satisfactory system.

4

When both user and analyst decide that sufficient information has been collected from the prototyping process, they determine how to meet the requirements they have identified. Usually one of the following four alternatives is selected :

1. The prototype is redeveloped . This alternative may mean complete reprogramming from scratch.

2. The prototype is implemented as the complete system. Performance efficiency and methods for user interaction may be sufficient to allow the system to be used as is.

3. The project is abandoned . In this case the prototype has provided enough information to show that a system cannot be developed to meet the desired objectives within existing technology or economic or operational guidelines.

4. Another prototyping series begun.The information gained through the current experience may suggest an entirely different approach to contrasting features.

Each alternative is viewed as a successful result of prototyping.

The Spiral Model :

The spiral model is a software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model .It provides the potential for rapid development of incremental versions of the software .In the spiral model , software is developed in a series of incremental releases .During early iterations , the incremental release might be a paper model or prototype. During later iterations , increasingly more complete versions of the engineered versions are produced.

Objectives: functionality, performance, hardware/software interface, critical success factors, etc.

Alternatives: build, reuse, buy, sub-contract, etc. Constraints: cost, schedule, man-power, experience etc. Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, etc.) Resolve risks

5

The spiral model is divided into a number of framework activities , also called task regions .• Customer communications – tasks required to establish effective communications between

developer and customer.• Planning –tasks required to define resources , timeliness and other project related information.• Risk analysis –tasks required to access both technical and management risks.• Engineering – tasks required to build one or more representations of the application.• Construction and release – tasks required to construct , test , install and provide use support.• Customer evaluation – tasks required to obtain customer feedback based on evaluation of the

software representations created during the engineering stage and implemented during the installation stage.

The RAD Model :Rapid Action Development is a linear sequential software development process model that emphasizes an extremely short development cycle. If requirements are well understood and project scope is constrained the RAD process enables a development team to create a “fully functional system” within very short time periods . The RAD approach encompasses the following phases :

• Business Modeling : The information flow among business functions is modeled in a way that answers the following questions .

What drives the business process ? What information is generated ? Where does the information go ? Who processes it ?

• Data modeling :The information flow defined as part of business modeling phase is refined into a set of data objects that are needed to support the business . The characteristics (called attributes) of each object are identified and the relationships between these objects are defined .

• Process modeling : The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function.

• Application generation :The RAD process works to reuse existing program components(when possible) to create reusable components (when necessary). Automated tools are used to facilitate construction of software.

• Testing and turnover : Since the RAD process emphasizes reuse , many of the program components have already been tested . This reduces overall testing time.However , new components must be tested and all interfaces must be fully exercised.

6

Requirements planning phase (a workshop utilizing structured discussion of business problems) User design phase – users to participate in the nontechnical design of the system Construction phase – productivity tools, such as code generators, screen generators. Cutover phase -- installation of the system, user acceptance testing and user training

RAD Strengths

Reduced cycle time and improved productivity with fewer people means lower costs Customer involved throughout the complete cycle minimizes risk of not achieving customer

satisfaction and business needs Focus moves from documentation to code Uses modeling concepts to capture information about business, data, and processes.

7

Unit 2: Requirement Engineering Concepts and Methods

What is Requirement EngineeringThe process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

Types of requirement1)User requirements

• Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

Users are those who use the information system to manage their organizations rather than simply those who work with computers. They are the ones who master the current information system (from information sources, management requirements to the system’s shortcomings) and are future owners of the system. Thus their requirements should be respected while developing any information system.

Attention should be paid in the following issues:

Easy access: The system must be able to timely access data and manipulation supports.

The system: The system must be solid and stable, being able to meet staff’s requirements and provide accurate information, easy to maintain and restructure, quick in identifying and correcting mistakes;

8

Interface: Suitable with working style of users, stable, easy to control data, independent and flexible, enabling users to approach in different ways.

2)System requirements• A structured document setting out detailed descriptions of

the system services. Written as a contract between client and contractor

The system is developed base on the requirements of the system itself (to help manage an organization) and technical requirements.

There are different view points of what information system automation is like, however, we can classify them into groups: view point of the system that will be developed, information expert’s view point and user’s one. These points of view often conflict with one another, at the same time we are required to build up a successful system in which the system, information experts and end users share the same view point. Information system is a system that collects information, manages them and creates information products for its users.

Suitable with the general strategies: Small changes in the organization’s development may result in bigger impacts on the information system’s requirements. Therefore, during the system development process, these requirements should be regularly checked for its suitability with the general strategies. Supporting decision maker: Together with hands-on experience, knowledge and anticipating ability, information system plays an important role in supporting decision making process; Competition edge: The more competitive the environment, the more demand for better systems;

9

Return on Investment: A new information system needs to show financial benefits it can bring, because decisions on investment, development costs and operation costs are based on financial analysis; More advanced evaluation techniques can be applied. These techniques take into consideration issues such as customer support, organizational effectiveness, risk, etc. Overhead control: human resource change will influence staff number, staff skills and workload. In many cases, while human resource structure is unchanged, workload and requirement for staff skills are yet much higher; Supporting operational management: This is clear in preparing detail information, making reports quickly, which contribute to a more flexible and efficient way of management; Improving information communication: Optimizing the flow of information, preparing necessary updated information and providing users with the information; Impact of information products: Information products are final outcomes of the IT system. We need to pay special attention to requirements for information products so as to thorough analysis. These requirements shall be frequently in comparison with general strategies while developing the system; Ability to implement more quickly and better.

3)Software specification• A detailed software description which can serve as a basis

for a design or implementation. Written for developers

Requirement elicitation techniques- Traditional methods and Modern methods, Verification and validation process.

Software validation

10

Verification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customerInvolves checking and review processes and system testingSystem testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system

Characteristics of a Good Software Requirements Specification (SRS)CorrectAn SRS is correct if, and only if, every requirement stated therein is one that the software shall meet. Traceability makes this procedure easier and less prone to error.

UnambiguousAn SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic of the final product be described using a single unique term.

CompleteAn SRS is complete if, and only if, it includes the following elements:

All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated.

Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.

Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.

ConsistentConsistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct. An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict.

Ranked for importance and/or stabilityAn SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or stability of that particular requirement. Typically, all of the requirements that relate to a software product are not equally important. Some requirements may be essential, especially for life-critical applications, while others may be desirable. Each requirement in the SRS should be identified to make these differences clear and explicit.

11

VerifiableAn SRS is verifiable if, and only if, every requirement stated therein is verifiable. A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement.

Nonverifiable requirements include statements such as "works well", "good human interface", and "shall usually happen". These requirements cannot be verified because it is impossible to define the terms "good", "well", or "usually".

ModifiableAn SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style. Modifiability generally requires an SRS to

Have a coherent and easy-to-use organization with a table of contents, an index, and explicit crossreferencing;

Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS);

Express each requirement separately, rather than intermixed with other requirements.

TraceableAn SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation. The following two types of traceability are recommended:

Backward traceability (i.e., to previous stages of development). This depends upon each requirement explicitly referencing its source in earlier documents.

Forward traceability (i.e., to all documents spawned by the SRS). This depends upon each requirement in the SRS having a unique name or reference number.

12

Unit 3: Design Concept and Methods

The software design process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

Architectural design

Abstract specification

Interface design

Component design

Data structure design

Algorithm design

Software Design process and principles, Design concepts: Abstraction, Refinement, Modularity, Architecture, Control hierarchy, Structural partitioning, Data structure, Procedure and Data hiding

Design concept

13

1) AbstractionWasserman: “Abstraction permits one to concentrate on a problem at some level of abstraction without regard to low level detail.At the highest level of abstraction a solution is stated in broad terms using the language of the problem environment.At lower level, a procedural orientation is taken.At the lowest level of abstraction the solution is stated in a manner that can be directly implemented.

Types of abstraction :

1. Procedural Abstraction :

A named sequence of instructions that has a specific &

limited function

Eg: Word OPEN for a door

2. Data Abstraction :

A named collection of data that describes a data object.

Data abstraction for door would be a set of attributes

that describes the door

(e.g. door type, swing direction, weight, dimension)

2. Refinement

Process of elaboration.

Start with the statement of function defined at the abstract level, decompose the statement of function in a stepwise fashion until programming language statements are reached.

3.Modularity

14

In this concept, software is divided into separately named and addressable components called modules

Follows “divide and conquer” concept, a complex problem is broken down into several manageable pieces

Let p1 and p2 be two problems. Let E1 and E2 be the effort required to solve them --

If C(p1)>C(p2)Hence E(p1)>E(p2)Now--Complexity of a problem that combines p1 and p2 is greater than complexity when each problem is considerC(p1+p2) > C(p1)+C(p2), HenceE(p1+p2) > E(p1)+E(p2)It is easier to solve a complex problem when you break it into manageable pieces

5 criteria to evaluate a design method with respect to its modularity-----

15

1)Modular understandability

module should be understandable as a standalone unit (no need to refer to other modules)

Modular continuity

If small changes to the system requirements result in

changes to individual modules, rather than system wide

changes, the impact of side effects will be minimized

Modular protection

If an error occurs within a module then those errors are localized and not spread to other modules.

Modular Composability

Design method should enable reuse of existing components.

Modular Decomposability

Complexity of the overall problem can be reduced if the design method provides a systematic mechanism to decompose a problem into sub problems

3)Control Hierarchy

16

Also called program structure

Represent the organization of program components.

Does not represent procedural aspects of software such as decisions, repetitions etc.

Depth –No. of levels of control (distance between the top and bottom modules in program control structure)

Width- Span of control.

Fan-out -no. of modules that are directly controlled by another module

Fan-in - how many modules directly control a given

\

module

Super ordinate -module that control another module

17

Subordinate - module controlled by another

Visibility -set of program components that may be called or used as data by a given component

Connectivity – A module that directly causes another module to begin execution is connected to it.

4) Software Architecture

Software architecture is the hierarchical structure of program components (modules), the manner in which these components interact and the structure of data that are used by the components.

A set of properties should be specified as part of an architectural design:

Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects) and the manner in which those components are packaged and interact with one another.

Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, reliability, security, adaptability, and other system characteristics.

Families of related systems. the design should have the ability to reuse architectural building blocks.

5)Data Structure

Data structure is a representation of the logical relationship among individual elements of data.

• Scalar item –

A single element of information that may be addressed by an identifier .

18

• Scalar item organized as a list- array

• Data structure that organizes non-contiguous scalar items-linked list

6)data or Information hiding

Information (data and procedure) contained within a module should be inaccessible to other modules that have no need for such information.

Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module.

7) Structural partitioning

If the architectural style of a system is

hierarchical program structure can be partitioned -----

1. Horizontal partitioning

2. Vertical partitioning

Horizontal partitioning

Separate branches can be defined for each major function

Eg : 3 partitions

1. Input

2. Data Transformation

19

3. Output

Advantages

◦ Easier to test

◦ Easier to maintain

◦ Propagation of fewer side effects

◦ Easier to add new features

Vertical Partitioning

◦ Control and work modules are distributed top down

◦ Top level modules perform control functions

◦ Lower modules perform computations (input processing and output

Modular Design

Functional Independence

20

Functional independence is achieved by developing modules with “single minded” function and an aversion to excessive interaction with other modules.

Measured using 2 qualitative criteria:

1. Cohesion : Measure of the relative strength of a module.

2. Coupling : Measure of the relative interdependence among modules.

Cohesion

• Strength of relation of elements within a module

• Element- Group of instructions or a data definition.

• Strive for high cohesion

Different types of cohesion :

1. Functional Cohesion (Highest):

A functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task.

Examples of functionally cohesive modules are Compute cosine of an angle Calculate net employee salary

2. Sequential Cohesion :

A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serves as input data to the next.

Eg: Module read and validate customer record

Read record

Validate customer record

Here output of one activity is input to the

second

3. Communicational cohesion

21

A communicationally cohesive module is one whose elements contribute to activities that use the same input or output data.

Suppose we wish to find out some facts about a book

For instance, we may wish to

FIND TITLE OF BOOK

FIND PRICE OF BOOK

FIND PUBLISHER OF BOOK

FIND AUTHOR OF BOOK

These four activities are related because they all work on the same input data, the book, which makes the

“module” communicationally cohesive.

4. Procedural Cohesion

A procedurally cohesive module is one whose elements are involved in different and possibly unrelated activities in which control flows from each activity to the next. A piece of coding ties the activities together

Eg: Module that averages two completely unrelated tables, TABLE-A and TABLE-B, which both just happen to have 100 elements each.

module compute table-A-avg and table-B-avg uses table-A, table-B returns table-A-avg, table-B-avg table-A-total : = 0 table-B-total : = 0 for i = i to 100 add table-A (i) to table-A-total add table-B (i) to table-B-total endfor table-A-avg : = table-A-total/100 table-B-avg : = table-B-total/100 endmodule

5. Temporal Cohesion

22

A temporally cohesive module is one whose elements are involved in activities that are related in time. A module INITIALIZE initializes many different functions in a mighty sweep, causing it to be broadly related to several other modules in the system.

module initialize updates a-counter, b-counter, items table, totals table, switch-a, switch-b rewind tape-a set a-counter to 0 rewind tape-b set b-counter to 0 clear items table clear totals table set switch-a to off set switch-b to on endmodule

6. Logical Cohesion

A logically cohesive module is one whose elements contribute to activities of the same general category in which the activity or activities to be executed are selected from outside the module.

A logically cohesive module contains a number of activities of the same general kind. To use the module, we pick out just the piece(s) we need.

7. Coincidental Cohesion (Lowest)

A coincidentally cohesive module is one whose elements contribute to activities with no meaningful relationship to one another.

Eg. When a large program id modularized by arbitrarily segmenting the program into several small modules.

23

Coupling

Measure of interconnection among modules in a software structure

Strive for lowest coupling possible.

Types of coupling

1. Data coupling (Most desirable)

Two modules are data coupled, if they communicate through

parameters where each parameter is an elementary piece of

data.

e.g. an integer, a float, a character, etc. This data item should

be problem related and not be used for control purpose.

2. Stamp Coupling

Two modules are said to be stamp coupled if a data structure is passed as parameter but the called module operates on some but not all of the individual components of the data structure.

3. Control Coupling

Two modules are said to be control coupled if one module

passes a control element to the other module.

This control element affects /controls the internal logic of the

called module

Eg: flags

24

4. Common Coupling

Takes place when a number of modules access a data item in a global data area.

5. Content coupling (Least desirable)

25

Two modules are said to be content coupled if one module branches into another module or modifies data within another.

Eg:

int func1(int a)

{ printf(“func1”);

a+=2;

goto F2A;

return a;

}

void func2(void)

{ printf(“func2”);

F2A : printf(“At F2A”)

}

26

Unit 6

The Importance of Software Maintenance

The Institute of Electrical and Electronics Engineers (IEEE) defines software maintenance as follows:

“Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performance, or adapt to a changed environment”

This definition of maintenance is a succinct outline of the benefits of software maintenance. Much like your car, software requires periodic refreshes to ensure it continues to run smoothly, a s well as preventative maintenance to reduce the occurrence of problems.

Correct Faults

Software maintenance packages provided by vendors offer peace-of-mind protection by keeping you covered for bugs and software problems. Like any other product, most software packages are under warranty for a specific period of time. Once these warranties expire, however, you may be required to pay out of pocket for fixes, much like you would for your vehicle. Maintenance programs allow your software to stay in warranty so you do not have to come up with cash should an error occur.

Improve Performance

Maintenance programs should include an upgrade component. Under a maintenance program, you will be entitled to free upgrades – usually onceper year. These upgrades often address issues reported by other software users and can greatly improve functionality or performance. Considering the overall cost of upgrades over time, this component of software

27

maintenance is often all that is necessary to make the program worthwhile.

Adapt to a Changing Environment

Technology and the Business environment are the two of the fastest changing aspects of our world. It is increasingly important to make sure that your business is always taking advantage of the best that your software has to offer and that your software matches the business requirements of the time. Regular updates and maintenance will allow you to keep up with market trends and ensure your business is as efficient and effective as it can be.

Predictive Cash Flow

The last benefit, but one of the most significant from a financial perspective, is the ability to gain control over your software expenditure. If you are covered for software bugs and receive regular upgrades, your overall IT expenditures will be reduced to a single monthly (or yearly) fee – your maintenance fee. This eliminates the guessing game of IT expenditure and eliminates large unexpected upfront costs down the road.

Unit-7

28

Computer Aided Software Engineering (CASE)What is CASE?

Computer-Aided Software Engineering (CASE) is the use of software tools to assist in the

development and maintenance of software. Tools used to assist in this way are known as

CASE Tools.

What is CASE Tool?

A CASE tool is a computer-based product aimed at supporting one or more software

engineering activities within a software development process.

Computer-Aided Software Engineering tools are those software which are used in any and all

phases of developing an information system, including analysis, design and programming.

For example, data dictionaries and diagramming tools aid in the analysis and design phases,

while application generators speed up the programming phase.

CASE tools provide automated methods for designing and documenting traditional

structured programming techniques. The ultimate goal of CASE is to provide a language for

describing the overall system that is sufficient to generate all the necessary programs

needed.

Components of CASE Tools

CASE Tool are used to support a wide variety of SDLC. CASE Tools are used to help in the

project identification and selection, project initiation and planning, and design phacss, and in

the implementation and maintenance phases. The components of CASE Tools are

categorized into 3 mainly;

UpperCASE Tool

UpperCASE Tool is a Computer-Aided Software Engineering (CASE) software tool that

supports the software development activities upstream from implementation. Uppercase

tool focus on the analysis phase (but sometimes also the design phase) of the software

development lifecycle (diagramming tools, report and form generators, and analysis

tools)

LowerCASE Tool

LowerCASE Tool Computer-Aided Software Engineering (CASE) software tool that directly

supports the implementation (programming) and integration tasks. LowerCASE tools

support database schema generation, program generation, implementation, testing, and

configuration management.

I CASE

Tools that integrate both upper and lower CASE, for example making it possible to design

a form and build the database to support it at the same time. An automated system

development environment that provides numerous tools to create diagrams, forms and

reports. It also offers analysis, reporting, and code generation facilities and seamlessly

shares and integrates data across and between tools.

29

Types of CASE Tools

The general types of CASE tools are listed below:

1. Diagramming tools: enable system process, data and control structures to be

represented graphically.

2. Computer display and report generators: help prototype how systems look and

feel. It makes it easier for the systems analyst to identify data requirements and

relationship.

3. Analysis tools: automatically check for importance, inconsistent, or incorrect

specifications in diagrams, forms, and reports.

4. Central repository: enables the integrated storage of specifications, diagrams,

reports and project management information.

5. Documentation Generators: produce technical and user documentation in

standard formats.

6. Code generators: enable the automatic generation of program and data base

definition code directly from the design documents, diagrams, forms, and reports.

What is Quality to CASE Tool?

The reason for using case may be very straight forward and practical decision such as being

easier to use and makes life better. However from a broader perspective, Quality to using

case implies how Case tools have improved the quality of software development. Case tool

has improved software development in the following;

Improve the quality of the system developed.

Increase the speed with which systems are designed and developed.

Ease and improve the testing process through the use of automated checking.

Improve the integration of development activities via common methodologies.

Improve the quality and completeness to documentation.

Help standardize the development process.

Improve the management of the project.

Simplify program maintenance.

Promote reusability of modules and documentation.

Improve software portability across environments.

What is productivity to CASE Tool? And how it helps Software Development.

Productivity can be said to be the state or quality of producing something. Or the

effectiveness of the productive efforts. Therefore productivity to case can be the

achievements gained or the effectiveness of using the CASE technology. Productivity has

helped in the development of software in the following ways;

Provide new systems with shorter development time.

Improve the productivity of the systems development process.

Improve the quality of the systems development process.

Improve worker skills.

30

Improve portability of new systems.

Improve the management of the systems development process.

Functions of a CASE Tool

1. Analysis

CASE analysis tools automatically check for incomplete, inconsistent, or in correct

specifications in diagrams, forms and reports.

2. Design

This is where the technical blueprint of the system is created by designing the

technical architecture – choosing amongst the architectural designs of

telecommunications, hardware and software that will best suit the organization’s

system and future needs. Also designing the systems model – graphically creating a

model from graphical user interface, screen design, and databases, to placement of

objects on screen

3. Code generation

CASE Tool has code generators which enable the automatic generation of program

and data base definition code directly from the documents, diagrams, forms, and

reports.

4. Documentation

CASE Tool has documentation generators to produce technical and user

documentation in standard forms. Each phase of the SDLC produces documentation.

The types of documentation that flow from one face to the next vary depending upon

the organization, methodologies employed and type of system being built.

Unit -8

31

Agile Software Development

Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.

Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks.

Agile methods also emphasize working software as the primary measure of progress

Agile process models:

1)DSDM 

The DSDM (Dynamic Software Development Method) was developed to fill in some of the gaps in the RAD method by providing a framework which takes into account the entire development cycle. The main features of the DSDM method are as follows:

1. User involvement 2. Iterative and incremental development3. Increased delivery frequency4. Integrated tests at each phase5. The acceptance of delivered products depends directly on fulfilling requirements. 

32

2)Adaptive Software Development (ASD)

is a software development process that grew out of rapid application development.

The characteristics of an Adaptive Software Development (ASD) lifecycle go well with what Software Planner has to offer. Software Planner's comprehensive features include requirements management, test case management, defect management, and project management.

Software Planner is an award winning application lifecycle management (ALM) tool that helps Information Technology (IT) departments manage all components of software development including managing customer requirements, project deliverables, test cases, defects, and support tickets.

Coupled with collaborative tools like document sharing, team calendars, interactive dashboards, knowledge bases and threaded discussions, teams begin communicating more effectively and begin delivering solutions quickly and with high quality.

3)Scrum Model

Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement.

Scrum employs real-time decision-making processes based on actual events and information. This requires well-trained and specialized teams capable of self-management, communication and decision-making. The teams in the organization work together while constantly focusing on their common interests.

Scrum involves:

Initial appointment of a project manager called the "scrum master."

Definition and prioritization of tasks to be done.

Planning sessions for each task.

Daily meetings among teams.

33

Identification and evaluation of potential project risks and process pitfalls.

Execution of projects in brief, high-intensity, frequent work sessions.

Reviews of progress and evaluations of completed projects.

Openness to constructive criticism and ideas for improvement.

4) Agile modeling (AM)

Agile Modeling (AM) is a chaordic, practice-based methodology for effective modeling of software-based systems. The AM methodology is a collection of practices – guided by principles and values – that are meant to be applied by software professionals on a day-to-day basis.  AM is not a prescriptive process, in other words it does not define detailed procedures for how to create a given type of model, instead it provides advice for how to be effective as a modeler.  AM is “touchy-feely” in that it is not hard and fast – think of AM as an art, not a science.

An important concept to understand about AM is that it is not a complete software process. AM’s focus is on effective modeling and documentation. That’s it. It doesn’t include programming activities, although it will tell you to prove your models with code. It doesn’t include testing activities, although it will tell you to consider testability as you model. It doesn’t cover project management, system deployment, system operations, system support, or a myriad of other issues. Because AM’s focus in on a portion of the overall software process you need to use it with another, full-fledged process such as eXtreme Programming (XP), DSDM, SCRUM, the Agile Unified Process (AUP), or theRational Unified Process (RUP).  You start with a base process, such as XP or RUP or perhaps even your own existing process, and then tailor it with AM (hopefully adopting all of AM) as well as other techniques as appropriate to form your own process that reflects your unique needs. Alternatively, you may decide to pick the best features from a collection of existing software processes to form your own process. For XP projects, AM explicitly describes how to improve productivity through addition of modeling activities whereas with for RUP projects it describes how to streamline modeling and documentation efforts to improve productivity. 

5) Agile unified Process

 is a simplified version of the Rational Unified Process (RUP) .  It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP.  I've tried to keep the Agile UP as simple as possible, both in its approach and in its description.  The descriptions are simple and to the point, with links to details (on the web) if you want them.  The approach applies agile techniques include test driven development

34

(TDD) , Agile Model Driven Development (AMDD) , agile change management , and database refactoring  to improve your productivity.

Erd for lib.

35

36