by ashish shrivastav pune

1. 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
production
Software 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. 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 Feasibility
3. 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. 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. 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. 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. 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. 7
Unit 2: Requirement Engineering Concepts and Methods
What is Requirement Engineering
The 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 requirement
1)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. 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. 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.

10. 10
Software validation
Verification and validation is intended to show that a system
conforms to its specification and meets the requirements of the
system customer
Involves checking and review processes and system testing
System 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)
Correct
An 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.
Unambiguous
An 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.
Complete
An 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.
Consistent
Consistency 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 stability
An 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

11. 11
for life-critical applications, while others may be desirable. Each requirement in the SRS should be
identified to make these differences clear and explicit.
Verifiable
An 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".
Modifiable
An 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.
Traceable
An 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. 12
Unit 3: Design Concept and Methods
The software design process
Requir
ements
specif
ication
Design acti ities
v
Architectur
al
design
Abstr
act
specif
ication
Interface
design
Component
design
Data
structur
e
design
Algorithm
design
System
architectur
e
Software
specif
ication
Interface
specif tion
ica
Component
specif
ication
Data
structur
e
specif
ication
Algorithm
specif tion
ica
Design pr
oducts
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

13. 13
Design concept
1) Abstraction
Wasserman: “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.

14. 14
3.Modularity
 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 consider
C(p1+p2) > C(p1)+C(p2),
Hence
E(p1+p2) > E(p1)+E(p2)
It is easier to solve a complex problem when
you break it into manageable pieces

15. 15
5 criteria to evaluate a design method with respect to its modularity-----
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

16. 16
3)Control Hierarchy
 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

17. 17
module
 Super ordinate -module that control another module
 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.

18. 18
• Scalar item –
A single element of information that may be addressed by an identifier .
• 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

19. 19
1. Input
2. Data Transformation
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

20. 20
Modular Design
Functional Independence

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 angleCalculate 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

21. 21
3. Communicational cohesion
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. 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 amighty 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
2.
3.
4.
5.
User involvement
Iterative and incremental development
Increased delivery frequency
Integrated tests at each phase
The acceptance of delivered products depends directly on fulfilling requirements.

32. 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. 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. 34
(TDD) , Agile Model Driven Development (AMDD) , agile change management , and database
refactoring to improve your productivity.
Erd for lib.

35. 35

36. 36