SARDAR PATEL COLLEGE OF ENGINEERING, BAKROL

Software Engineering (2160701)

Assignment – 2
Assignment – 3
Assignment – 4
Assignment – 5
Assignment – 6

Name: Panchal Ankitaben Rameshbhai

Enrollment No: 181243107004
 1. What do you mean by Software model? explain each model in detail.
A software process (also known as software methodology) is a set of related activities
that leads to the production of the software. These activities may involve the development of the
software from the scratch, or, modifying an existing system.

Any software process must include the following four activities:

1. Software specification (or requirements engineering): Define the main functionalities of

the software and the constrains around them.

2. Software design and implementation: The software is to be designed and programmed.

3. Software verification and validation: The software must conform to its specification
and meets the customer needs.

4. Software evolution (software maintenance): The software is being modified to meet

customer and market requirements changes.

Waterfall Model
The waterfall model is a sequential approach, where each fundamental activity of a process
represented as a separate phase, arranged in linear order.

In the waterfall model, you must plan and schedule all of the activities before starting
working on them (plan-driven process).

Plan-driven process is a process where all the activities are planned first, and the progress is
measured against the plan. While the agile process, planning is incremental and it’s easier to
change the process to reflect requirement changes.
When to Use?

In principle, the waterfall model should only be applied when requirements are well understood
and unlikely to change radically during development as this model has a relatively rigid structure
which makes it relatively hard to accommodate change when the process in underway.

Spiral Model
The spiral model is a risk-driven where the process is represented as spiral rather than a sequence
of activities.

It was designed to include the best features from the waterfall and prototyping models, and
introduces a new component; risk-assessment.

Each loop (from review till service — see figure below) in the spiral represents a phase. Thus,
the first loop might be concerned with system feasibility, the next loop might be concerned with
the requirements definition, the next loop with system design, and so on.
 1. Objective setting: The objectives and risks for that phase of the project are defined.

2. Risk assessment and reduction: For each of the identified project risks, a detailed
analysis is conducted, and steps are taken to reduce the risk. For example, if there’s a risk
that the requirements are inappropriate, a prototype may be developed.

3. Development and validation: After risk evaluation, a process model for the system is
chosen. So if the risk is expected in the user interface then we must prototype the user
interface. If the risk is in the development process itself then use the waterfall model.

4. Planning: The project is reviewed and a decision is made whether to continue with a

further loop or not.

Spiral model has been very influential in helping people think about iteration in software
processes and introducing the risk-driven approach to development. In practice, however, the
model is rarely used.

Iterative Development model

Iterative development model aims to develop a system through building small portions of all the
features, across all components.

We build a product which meets the initial scope and release it quickly for customer feedback.
An early version with limited features important to establish market and get customer feedback.

In each increment, a slice of system features is delivered, passing through the requirements till
the deployment.

The phases of iterative development are:

1. Inception: The goal is to establish a business case for the system. We should identify all
the external entities that will interact with the system, and define these interactions. Then,
uses this information to assess the contribution that the system makes to the business. If
the contribution is minor, then the project may be cancelled.
 2. Elaboration: We develop an understanding of the problem domain and architecture
framework, develop the project plan, and identify risks.

3. Construction: Incrementally  fills-in the architecture with production-ready code

produced from analysis, design, implementation, and testing of the requirements. The
components of the system are dependent on each other and they’re developed in parallel
and integrated during this phase. On the completion of this phase, you should have a
complete working software.

4. Transition: We deliver the system into the production operating environment.

Prototyping model
A prototype is a version of a system or part of the system that’s developed quickly to check the
customer’s requirements or feasibility of some design decisions.

So, a prototype is useful when a customer or developer is not sure of the requirements, or of
algorithms, efficiency, business rules, response time, etc.

In prototyping, the client is involved throughout the development process, which increases the
likelihood of client acceptance of the final implementation.

While some prototypes are developed with the expectation that they will be discarded, it is
possible in some cases to evolve from prototype to working system.

The phases of a prototype are:

1. Establish objectives: The objectives of the prototype should be made explicit from the
start of the process. Is it to validate system requirements, or demonstrate feasibility, etc.
 2. Define prototype functionality: Decide what are the inputs and the expected output
from a prototype. To reduce the prototyping costs and accelerate the delivery schedule,
you may ignore some functionality, such as response time and memory utilization unless
they are relevant to the objective of the prototype.

3. Develop the prototype: The initial prototype is developed that includes only user
interfaces.

4. Evaluate the prototype: Once the users are trained to use the prototype, they then
discover requirements errors. Using the feedback both the specifications and the
prototype can be improved. If changes are introduced, then a repeat of steps 3 and 4 may
be needed.

Prototyping is not a standalone, complete development methodology, but rather an approach to

be used in the context of a full methodology (such as incremental, spiral, etc).

Incremental Development model

Incremental development is based on the idea of developing an initial implementation, exposing
this to user feedback, and evolving it through several versions until an acceptable system has
been developed.

The activities of a process are not separated but interleaved with feedback involved across those
activities.
Each system increment reflects a piece of the functionality that is needed by the customer.
Generally, the early increments of the system should include the most important or most urgently
required functionality.

This means that the customer can evaluate the system at early stage in the development to see if
it delivers what’s required. If not, then only the current increment has to be changed and,
possibly, new functionality defined for later increments.

2. Explain incremental model for system development. Differentiate it with

spiral model.
 3. Explain prototype model and compare with it water fall model.
A prototype is a version of a system or part of the system that’s developed quickly to check the
customer’s requirements or feasibility of some design decisions.

So, a prototype is useful when a customer or developer is not sure of the requirements, or of
algorithms, efficiency, business rules, response time, etc.

In prototyping, the client is involved throughout the development process, which increases the
likelihood of client acceptance of the final implementation.

While some prototypes are developed with the expectation that they will be discarded, it is
possible in some cases to evolve from prototype to working system.

The phases of a prototype are:

1. Establish objectives: The objectives of the prototype should be made explicit from the
start of the process. Is it to validate system requirements, or demonstrate feasibility, etc.

2. Define prototype functionality: Decide what are the inputs and the expected output
from a prototype. To reduce the prototyping costs and accelerate the delivery schedule,
you may ignore some functionality, such as response time and memory utilization unless
they are relevant to the objective of the prototype.

3. Develop the prototype: The initial prototype is developed that includes only user
interfaces.

4. Evaluate the prototype: Once the users are trained to use the prototype, they then
discover requirements errors. Using the feedback both the specifications and the
prototype can be improved. If changes are introduced, then a repeat of steps 3 and 4 may
be needed.
Prototyping is not a standalone, complete development methodology, but rather an approach to
be used in the context of a full methodology (such as incremental, spiral, etc.).

Waterfall Model Prototype Model: -

Client can only preview the system only after Client have a preview of the system from the
the final version of the software is developed "quick design" and the prototype developed
because there is no feedback loop. early at the of the process.
Developers encounter a freezing requirement Developers can refine or add requirements
where they are not allowed to modify the and specification to the system after the
requirements or specification of the previous prototype is built.
phase until the next iteration.
The complexity of an error increases because The complexity of an error is low because the
of the nature of the model; each phase is prototype enables the developer to detect any
sequential of the other. deficiency early at the process.
This model is easy to understand. This model is not easy to understand.
Complete program analysis. Incomplete program Analysis.

4. Explain agile process model with diagram

Agile model.

The meaning of Agile is swift or versatile. “Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into smaller
iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which typically
lasts from one to four weeks. The division of the entire project into smaller parts helps to
minimize the project risk and to reduce
the overall project delivery time
requirements. Each iteration involves a
team working through a full software
development life cycle including
planning, requirements analysis,
design, coding, and testing before a
working product is demonstrated to the
client.
Phases of Agile Model:

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based on
this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders to
define requirements. You can use the user flow diagram or the high-level UML diagram to show
the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins. Designers
and developers start working on their project, which aims to deploy a working product. The
product will undergo various stages of improvement, so it includes simple, minimal
functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and
looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.

5. What do you mean by risk? what is s/w risk? Explain all types of risk.
Risk: Risk is an expectation of loss, a potential problem that may or may not occur in the future.
It is generally caused due to lack of information, control or time.

Software Risk: A possibility of suffering from loss in software development process is called a
software risk. Loss can be anything, increase in production cost, development of poor-quality
software, not being able to complete the project on time.

There is five type of risk:

1) Schedule Risk: Project schedule get slip when project tasks and schedule release risks
are not addressed properly. Schedule risks mainly affect a project and finally on company
economy and may lead to project failure.

Schedules often slip due to the following reasons:

 Wrong time estimation
  Resources are not tracked properly. All resources like staff, systems, skills of
individuals, etc.
   Failure to identify complex functionalities and time required to develop those
functionalities.
  Unexpected project scope expansions.
2) Budget Risk
  Wrong budget estimation.
  Cost overruns
  Project scope expansion

3) Operational Risks: Risks of loss due to improper process implementation failed system or

some external events risks. Causes of Operational Risks:
  Failure to address priority conflicts
  Failure to resolve the responsibilities
  Insufficient resources
  No proper subject training
  No resource planning
  No communication in the team.

4) Technical Risks: Technical risks generally lead to failure of functionality and performance.

Causes of Technical Risks are:

  Continuous changing requirements

  No advanced technology available or the existing technology is in the initial stages.
  The product is complex to implement.
  Difficult project modules integration.

5) Programmatic Risks: These are the external risks beyond the operational limits. These are all
uncertain risks are outside the control of the program. These external events can be:
   Running out of the fund.
   Market development
   Changing customer product strategy and priority
   Government rule changes.

Assignment: 3
1. Explain about software project estimation.
Software project estimation is a form of problem solving, and in most cases, the problem to be
solved (i.e., developing a cost and effort estimate for a software project) is too complex to be
considered in one piece.

 Estimation of resources, cost, and schedule for a software engineering effort requires
experience, access to good historical information (metrics), and the courage to commit to
quantitative predictions when qualitative information is all that exists.
 Software project estimation is a form of problem solving, and in most cases, the problem to
be solved is too complex to be considered in one piece.
 For this reason, you should decompose the problem, characterizing it as a set of smaller (and
hopefully, more manageable) problems.

Software Sizing

“Fuzzy logic” sizing:

 This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy
logic.
 To apply this approach, the planner must identify the type of application, establish its
magnitude on a qualitative scale, and then refine the magnitude within the original range.

Function point sizing:

 The planner develops estimates of the information domain characteristics.

Standard component sizing:

 Software is composed of a number of different “standard components” that are generic to a

particular application area.

Change sizing:

 This approach is used when a project encompasses the use of existing software that must be
modified in some way as part of a project.
 The planner estimates the number and type (e.g., reuse, adding code, changing code, and
deleting code) of modifications that must be accomplished.

Problem-Based Estimation

 Start with a bounded statement of scope

 Decompose the software into problem functions that can each be estimated individually
 Compute a LOC or FP value for each function
 Derive cost or effort estimates by applying the LOC or FP values to your baseline
productivity metrics (e.g., LOC/person-month or FP/person-month)
 Combine function estimates to produce an overall estimate for the entire project.
2. Define about project scheduling and tracking.
Project scheduling is a tool to interact with what tasks need to get done and which
organizational resources will be allotted to complete those tasks in what timeframe.

A project schedule is collecting data on all the work required to deliver the project on
time. Yet when it comes to creating a project schedule, well, that's something few have
in-depth knowledge with. Everyone has different systems, and their availability and
holiday or leave dates need to be documented to successfully plan those tasks.

Whereas people in the past might have published calendars on a shared surface, or shared
spreadsheets via email, now, most teams use online project scheduling mechanisms.

3. Explain about RMMM Plan.

The R.M.M.M plan is a document in which all the risk analysis activities are described.
Sometimes project manager includes this document as a part of overall project plan.
Sometimes specific R.M.M.M plan is not created; however, each risk can be described
individually using risk information sheet. Typical template for R.M.M.M plan or risk
information sheet can be

Risk Mitigation:

 Risk mitigation means preventing the risk to occur (Risk Avoidance). Following are the
steps to be taken for mitigating the risks. 
 Communicate with the concerned staff to find of probable risk.
 Find out and eliminate all those causes that can create rick before the project starts. 
 Develop a policy in an organization which will help to continue the project even though
some staff leaves the organization. 
 Everybody in the project team should be acquainted with the current development
activity. 
 Maintain the corresponding documents in timely manner. This documentation should be
strictly as per the standards set by the organization. 
 Conduct timely reviews in order to speed up the work. 
 For conducting every critical activity during software development, provide the
additional staff if required.

Risk Monitoring:

 In risk monitoring process following things must be monitored by the project manager.
 The approach of the team members as pressure of project varies. 
 The degree in which the team performs with the spirit of "team-work". 
  The type of co-operation among the team members. The types of problems that are
occurring. Availability of jobs within and outside the organization. 
 The project manager should monitor certain mitigation steps. For example: If the current
development activity is monitored continuously then everybody in the team will get
acquainted with current development activity. 
 The objective of risk monitoring is to check whether the predicted risks really occur or
not. To ensure the step defined to avoid the risk are applied properly or not. To gather the
information which can be useful for analyzing the risk.
Risk management:

 Project manager perform this task when risk becomes a reality. If project manager is
successful in applying the project mitigation effectively then it becomes very much easy
to manage the risks. 

4. Write a short note on: Risk Identification and Risk Mitigation.

Risk identification
Risk identification is the process of determining risks that could potentially prevent the
program, enterprise, or investment from achieving its objectives. It includes documenting and
communicating the concern.

 The objective of risk identification is the early and continuous identification of events
that, if they occur, will have negative impacts on the project's ability to achieve
performance or capability outcome goals.
 They may come from within the project or from external sources. There are multiple
types of risk assessments, including program risk assessments, risk assessments to
support an investment decision, analysis of alternatives, and assessments of operational
or cost uncertainty.
 Risk identification needs to match the type of assessment required to support risk-
informed decision making. For an acquisition program, the first step is to identify the
program goals and objectives, thus fostering a common understanding across the team of
what is needed for program success. This gives context and bounds the scope by which
risks are identified and assessed.

Risk Mitigation:

 Risk mitigation means preventing the risk to occur (Risk Avoidance). Following are the
steps to be taken for mitigating the risks. 
 Communicate with the concerned staff to find of probable risk.
 Find out and eliminate all those causes that can create rick before the project starts. 
 Develop a policy in an organization which will help to continue the project even though
some staff leaves the organization. 
 Everybody in the project team should be acquainted with the current development
activity. 
 Maintain the corresponding documents in timely manner. This documentation should be
strictly as per the standards set by the organization. 
 Conduct timely reviews in order to speed up the work. 
 For conducting every critical activity during software development, provide the
additional staff if required.
 Assignment: 4
1. Explain briefly about SRS.

The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) also called a requirements document. This report lays a
foundation for software engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their requirements. Also, it
comprises user requirements for a system as well as detailed specifications of the system
requirements.

The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on who
is writing it. First, the SRS could be written by the client of a system. Second, the SRS could be
written by a developer of the system. The two methods create entirely various situations and
establish different purposes for the document altogether. The first case, SRS, is used to define the
needs and expectation of the users. The second case, SRS, is written for various purposes and
serves as a contract document between customer and developer.

Qualities of SRS:
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for importance and/or stability
6. Verifiable
7. Modifiable
8. Traceable
1. Correctness: User review is used to provide the accuracy of requirements stated in
the SRS. SRS is said to be perfect if it covers all the needs that are truly expected
from the system.
2. Unambiguousness: SRS is unambiguous when every fixed requirement has only
one interpretation. This suggests that each element is uniquely interpreted. In case
there is a method used with multiple definitions, the requirements report should
determine the implications in the SRS so that it is clear and simple to understand.
3. Completeness: The SRS is complete if, and only if, it includes the following
elements:

1- All essential requirements, whether relating to functionality, performance,

design, constraints, attributes, or external interfaces.
 2-Definition of their responses of the software to all realizable classes of input
data in all available categories of situations

3-Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure

4. Consistency: The SRS is consistent if, and only if, no subset of individual

requirements described in its conflict. There are three types of possible conflict in
the SRS:
(1). The specified characteristics of real-world objects may conflict
(2). There may be a reasonable or temporal conflict between the two specified
actions.
(3). Two or more requirements may define the same real-world object but use
different terms for that object

5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the
significance or stability of that particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable.
Each element should be identified to make these differences clear and explicit.
Another way to rank requirements is to distinguish classes of items as essential,
conditional, and optional.

6. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.

7. Modifiability: SRS should be made as modifiable as likely and should be capable of

quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if
it facilitates the referencing of each condition in future development or enhancement
documentation

2. Explain about Requirement Analysis

Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This
activity reviews all requirements and may provide a graphical view of the entire system. After
the completion of the analysis, it is expected that the understandability of the project may
improve significantly. Here, we may also use the interaction with the customer to clarify points
of confusion and to understand which requirements are more important than others.
The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the boundaries
and interfaces of the proposed systems with the external world. It identifies the entities outside
the proposed system that interact with the system. The context diagram of student result
management system is given below:

(ii) Development of a Prototype (optional):  One effective way to find out what the customer wants
is to construct a prototype, something that looks and preferably acts as part of the system they
say they want.
We can use their feedback to modify the prototype until the customer is satisfied continuously.
Hence, the prototype helps the client to visualize the proposed system and increase the
understanding of the requirements. When developers and users are not sure about some of the
elements, a prototype may help both the parties to take a final decision.

Some projects are developed for the general market. In such cases, the prototype should be
shown to some representative sample of the population of potential purchasers. Even though a
person who tries out a prototype may not buy the final system, but their feedback may allow us
to make the product more attractive to othersThe prototype should be built quickly and at a
relatively low cost. Hence it will always have limitations and would not be acceptable in the final
system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various graphical representations
of the functions, data entities, external entities, and the relationships between them. The
graphical view may help to find incorrect, inconsistent, missing, and superfluous requirements.
Such models include the Data Flow diagram, Entity-Relationship diagram, Data Dictionaries,
State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better
understanding of the system behavior. The inconsistencies and ambiguities have been identified
and corrected. The flow of data amongst various modules has been analyzed. Elicitation and
analyze activities have provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a prescribed format.

3. Explain about Requirement Engineering.

Requirements engineering (RE)  refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. Requirement engineering provides the
appropriate mechanism to understand what the customer desires, analyzing the need, and
assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating
the specifications and managing the requirements as they are transformed into a working system.
Thus, requirement engineering is the disciplined application of proven principles, methods, tools,
and notation to describe a proposed system's intended behavior and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
 2. Requirement Elicitation and Analysis

3. Software Requirement Specification

4. Software Requirement Validation

5. Software Requirement Management

1. Feasibility Study

The objective behind the feasibility study is to create the reasons for developing the software that
is acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:
 1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are
needed to accomplish customer requirements within the time and budget.

2. Operational Feasibility - Operational feasibility assesses the range in which the required
software performs a series of levels to solve business problems and customer
requirements.

3. Economic Feasibility - Economic feasibility decides whether the necessary software can
generate financial profits for an organization.

2. Requirement Elicitation and Analysis

This is also known as the gathering of requirements. Here, requirements are identified with the
help of customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want

o Stakeholders express requirements in their terms.

o Stakeholders may have conflicting requirements.

o Requirement change during the analysis process.

o Organizational and political factors may influence system requirements.

3. Software Requirement Specification

Software requirement specification is a kind of document which is created by a software analyst
after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the

requirements. DFD shows the flow of data through a system. The system may be a company, an
organization, a set of procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow graph or bubble chart.

o Data Dictionaries: Data Dictionaries are simply repositories to store information about all data

items defined in DFDs. At the requirements stage, the data dictionary should at least define
customer data items, to ensure that the customer and developers use the same definition and
terminologies.

o Entity-Relationship Diagrams: Another tool for requirement specification is the entity-

relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the
data for the organization and uses three main constructs i.e. data entities, relationships, and their
associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software

o If there are any ambiguities

o If they are full

o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.

o Test-case generation: Developing tests for requirements to check testability.

o Automated consistency analysis: checking for the consistency of structured requirements

descriptions.

4. Define briefly about Requirement Elicitation

Requirement elicitation process can be depicted using the following diagram:

 Requirements gathering - The developers discuss with the client and end users and
know their expectations from the software.
 Organizing Requirements - The developers prioritize and arrange the requirements in
order of importance, urgency and convenience.
 Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.

 Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake in
the software system development.
There are various ways to discover requirements.
Interviews
Interviews are strong medium to collect requirements. Organization may conduct several types
of interviews such as:

 Structured (closed) interviews, where every single information to gather is decided in

advance, they follow pattern and matter of discussion firmly.
 Non-structured (open) interviews, where information to gather is not decided in advance,
more flexible and less biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the table.
 Group interviews which are held between groups of participants. They help to uncover
any missing requirement as numerous people are involved.
Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is handed over to
all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied and
requirements of proposed system are collected
Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a great
help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no
software installed at client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback serves as an
input for requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They observe the actual working of the
existing installed systems. They observe the workflow at client’s end and how execution problems are
dealt. The team itself draws some conclusions which aid to form requirements expected from the
software.
 Assignment: 5
1. Explain the different Design Concepts.

The set of fundamental software design concepts are as follows:

1. Abstraction

 A solution is stated in large terms using the language of the problem environment at the
highest-level abstraction.
 The lower level of abstraction provides a more detail description of the solution.
 A sequence of instruction that contain a specific and limited function refers in a
procedural abstraction.
 A collection of data that describes a data object is a data abstraction.

2. Architecture

 The complete structure of the software is known as software architecture.

 Structure provides conceptual integrity for a system in a number of ways.
 The architecture is the structure of program modules where they interact with each other
in a specialized way.
 The components use the structure of data.
 The aim of the software design is to obtain an architectural framework of a system.
 The more detailed design activities are conducted from the framework.
3. Patterns

 A design pattern describes a design structure and that structure solves a particular design
problem in a specified content.

4. Modularity

 A software is separately divided into name and addressable components. Sometime they
are called as modules which integrate to satisfy the problem requirements.
 Modularity is the single attribute of a software that permits a program to be managed
easily.
5. Information hiding

 Modules must be specified and designed so that the information like algorithm and data
presented in a module is not accessible for other modules not requiring that information.

6. Functional independence

 The functional independence is the concept of separation and related to the concept of
modularity, abstraction and information hiding.
 The functional independence is accessed using two criteria i.e Cohesion and coupling.
Cohesion

 Cohesion is an extension of the information hiding concept.

 A cohesive module performs a single task and it requires a small interaction with the
other components in other parts of the program.
Coupling

 Coupling is an indication of interconnection between modules in a structure of software.

7. Refinement

 Refinement is a top-down design approach.

 It is a process of elaboration.
 A program is established for refining levels of procedural details.
 A hierarchy is established by decomposing a statement of  function in a stepwise manner
till the programming language statement are reached.
8. Refactoring

 It is a reorganization technique which simplifies the design of components without

changing its function behaviour.
 Refactoring is the process of changing the software system in a way that it does not
change the external behaviour of the code still improves its internal structure.
9. Design classes
  The model of software is defined as a set of design classes.
 Every class describes the elements of problem domain and that focus on features of the
problem which are user visible.

2. What are Design Principle?

A particular area provided by design principle for the judgments of particular aspects of design.
We have three types of principles which are explained below:
1. Division of problems - The base of these principles is to divide a big problem in to little
parts. Every little part developed by different programs individually. Every little part can
be individually altered.
o This helps the system to become more sufficient.
o This principle reduce the size of the problem and make simple and easy to service
or maintenance.
o Leads to hierarchy in the design.
For the solution of big problem it is necessary to became proper coordination between
these small pieces of problems.
2. Abstraction - To get the information in concerned to software parts from the outside is
called the abstraction.
3. Top down and bottom up design planning - According to this principle a big problem
divided in two little parts which is called modules and solved these modules one by one
individually so that no one module can affected each other. We have two types of
approaches. The top down approach goes from high level to the lower level. On the
other side the bottom up approach goes the opposite that mean it goes lower level to top
level.
o Top down design planning - When planning of system starts from that target
which system wants to get then that approach is called top down design
planning. When we see the desired task is not easy for achieving then this task
divided in parts and these parts is called sub task. These sub tasks have some
quality which is:
 Size of problem will be small
 Reduce the level of difficulty
 Easy to achieve
If a task is difficult then we may divide it low difficulty and easily getable
subtasks. Thus, the process of division of various tasks in to sub tasks is to make
simple and easy which can be used or solved easily. Many types of module based
on this approach but this approach is useful only those that case where the target
is mentioned clearly.
 o Bottom up design planning - To get the big goal for the system, this approach is
used. It started from the lower level and at the end it reached the top level. In this
approach individual modules are combined with each other so that a big module
can be built which is the target of this system. A good idea is must require for the
success of this approach. Until we have not good idea about the operation need at
the higher level then we cannot decide what operation support at this time.
3. What are Testing Strategies? Explain Software Testing (Black Box and
White Box Testing)
Software Testing is evaluation of the software against requirements gathered from users and
system specifications. Testing is conducted at the phase level in software development life cycle
or at module level in program code. Software testing comprises of Validation and Verification.

Black-box testing
It is carried out to test functionality of the program. It is also called ‘Behavioral’ testing. The
tester in this case, has a set of input values and respective desired results. On providing input, if
the output matches with the desired results, the program is tested ‘ok’, and problematic
otherwise.

In this testing method, the design and structure of the code are not known to the tester, and
testing engineers and end users conduct this test on the software.
Black-box testing techniques:
 Equivalence class - The input is divided into similar classes. If one element of a class
passes the test, it is assumed that all the class is passed.
 Boundary values - The input is divided into higher and lower end values. If these values
pass the test, it is assumed that all values in between may pass too.
 Cause-effect graphing - In both previous methods, only one input value at a time is
tested. Cause (input) – Effect (output) is a testing technique where combinations of input
values are tested in a systematic way.
 Pair-wise Testing - The behavior of software depends on multiple parameters. In
pairwise testing, the multiple parameters are tested pair-wise for their different values.
 State-based testing - The system changes state on provision of input. These systems are
tested based on their states and input.
White-box testing
It is conducted to test program and its implementation, in order to improve code efficiency or
structure. It is also known as ‘Structural’ testing.

In this testing method, the design and structure of the code are known to the tester.
Programmers of the code conduct this test on the code.
The below are some White-box testing techniques:
 Control-flow testing - The purpose of the control-flow testing to set up test cases which
covers all statements and branch conditions. The branch conditions are tested for both
being true and false, so that all statements can be covered.
 Data-flow testing - This testing technique emphasis to cover all the data variables
included in the program. It tests where the variables were declared and defined and
where they were used or changed.

4. What are the various coding standard? Write in brief regarding Code
Review.

General coding standards refers to how the developer writes code, so here we will discuss some
essential standards regardless of the programming language being used.

The following are some representative coding standards:

 1. Indentation: Proper and consistent indentation is essential in producing easy to read and
maintainable program

Indentation should be used to:

o Emphasize the body of a control structure such as a loop or a select statement.

o Emphasize the body of a conditional statement

o Emphasize a new scope block

2. Inline comments: Inline comments analyze the functioning of the subroutine, or key

aspects of the algorithm shall be frequently used.

3. Rules for limiting the use of global: These rules file what types of data can be declared
global and what cannot.

4. Structured Programming: Structured (or Modular) Programming methods shall be

used. "GOTO" statements shall not be used as they lead to "spaghetti" code, which is
hard to read and maintain, except as outlined line in the FORTRAN Standards and
Guidelines.

5. Naming conventions for global variables, local variables, and constant identifiers: A
possible naming convention can be that global variable names always begin with a capital
letter, local variable names are made of small letters, and constant names are always
capital letters.

6. Error return conventions and exception handling system: Different functions in a

program report the way error conditions are handled should be standard within an
organization. For example, different tasks while encountering an error condition should
either return a 0 or 1 consistently.

Code Review: -

Code Review is a systematic examination, which can find and remove the vulnerabilities in the
code such as memory leaks and buffer overflows.
  Technical reviews are well documented and use a well-defined defect detection process
that includes peers and technical experts.
 It is ideally led by a trained moderator, who is NOT the author.
 This kind of review is usually performed as a peer review without management
participation.
 Reviewers prepare for the review meeting and prepare a review report with a list of
findings.
 Technical reviews may be quite informal or very formal and can have a number of
purposes but not limited to discussion, decision making, evaluation of alternatives,
finding defects and solving technical problems.
5. Explain SIX SIGMAS.
Six Sigma is the process of improving the quality of the output by identifying and eliminating the
cause of defects and reduce variability in manufacturing and business processes. The maturity of
a manufacturing process can be defined by a sigma rating indicating its percentage of defect-free
products it creates.

Characteristics of Six Sigma

The Characteristics of Six Sigma are as follows

1. Statistical Quality Control: Six Sigma is derived from the Greek Letter σ (Sigma) from
the Greek alphabet, which is used to denote Standard Deviation in statistics. Standard
Deviation is used to measure variance, which is an essential tool for measuring non-
conformance as far as the quality of output is concerned.
 2. Methodical Approach: The Six Sigma is not a merely quality improvement strategy in
theory, as it features a well defined systematic approach of application in DMAIC and
DMADV which can be used to improve the quality of production. DMAIC is an acronym
for Design-Measure- Analyze-Improve-Control. The alternative method DMADV stands
for Design-Measure- Analyze-Design-Verify.

3. Fact and Data-Based Approach: The statistical and methodical aspect of Six Sigma
shows the scientific basis of the technique. This accentuates essential elements of the Six
Sigma that is a fact and data-based.

4. Project and Objective-Based Focus: The Six Sigma process is implemented for an

organization's project tailored to its specification and requirements. The process is flexed
to suits the requirements and conditions in which the projects are operating to get the best
results.

5. Customer Focus: The customer focus is fundamental to the Six Sigma approach. The
quality improvement and control standards are based on specific customer requirements.

6. Teamwork Approach to Quality Management: The Six Sigma process requires

organizations to get organized when it comes to controlling and improving quality. Six
Sigma involving a lot of training depending on the role of an individual in the Quality
Management team.

6. Explain CMM.
Capability Maturity Model (CMM) specifies an increasing series of levels of a software
development organization. The higher the level, the better the software development process,
hence reaching each level is an expensive and time-consuming process.

Levels of CMM
 Level One :Initial - The software process is characterized as inconsistent, and
occasionally even chaotic. Defined processes and standard practices that exist are
abandoned during a crisis. Success of the organization majorly depends on an individual
effort, talent, and heroics. The heroes eventually move on to other organizations taking
their wealth of knowledge or lessons learnt with them.
  Level Two: Repeatable - This level of Software Development Organization has a basic
and consistent project management processes to track cost, schedule, and functionality.
The process is in place to repeat the earlier successes on projects with similar
applications. Program management is a key characteristic of a level two organization.

 Level Three: Defined - The software process for both management and engineering
activities are documented, standardized, and integrated into a standard software process
for the entire organization and all projects across the organization use an approved,
tailored version of the organization's standard software process for developing, testing
and maintaining the application.
 Level Four: Managed - Management can effectively control the software development
effort using precise measurements. At this level, organization set a quantitative quality
goal for both software process and software maintenance. At this maturity level, the
performance of processes is controlled using statistical and other quantitative techniques,
and is quantitatively predictable.
 Level Five: Optimizing - The Key characteristic of this level is focusing on continually
improving process performance through both incremental and innovative technological
improvements. At this level, changes to the process are to improve the process
performance and at the same time maintaining statistical probability to achieve the
established quantitative process-improvement objectives.

7. What are Quality Standards? Explain Quality Control and Assurance.

The quality of software has improved significantly over the past two decades. One reason for this
is that companies have used new technologies in their software development process such as
object-oriented development, CASE tools, etc. In addition, a growing importance of software
quality management and the adoption of quality management techniques from manufacturing can
be observed. However, software quality significantly differs from the concept of quality
generally used in manufacturing mainly for the next reasons.

 The software specification should reflect the characteristics of the product that the
customer wants. However, the development organization may also have requirements
such as maintainability that are not included in the specification.
 Certain software quality attributes such as maintainability, usability, reliability cannot be
exactly specified and measured.
 At the early stages of software process it is very difficult to define a complete software
specification. Therefore, although software may conform to its specification, users don’t
meet their quality expectations.
Software quality management is split into three main activities:

 Quality assurance. The development of a framework of organizational procedures and

standards that lead to high quality software.
 Quality planning. The selection of appropriate procedures and standards from this
framework and adapt for a specific software project.
 Quality control. Definition of processes ensuring that software development follows the
quality procedures and standards.

Quality Control
Many people get confused between quality control (QC) and quality assurance (QA). Let's take
a look at quality control function in high-level.
As we have already discussed, organizations can define their own internal quality standards,
processes and procedures; the organization will develop these over time and then relevant
stakeholders will be required to adhere by them.
The process of making sure that the stakeholders are adhered to the defined standards and
procedures is called quality control. In quality control, a verification process takes place.
Certain activities and products are verified against a defined set of rules or standards.
Every organization that practices QC needs to have a Quality Manual. The quality manual
outlines the quality focus and the objectives in the organization.
The quality manual gives the quality guidance to different departments and functions.
Therefore, everyone in the organization needs to be aware of his or her responsibilities
mentioned in the quality manual.
Quality Assurance
Quality Assurance is a broad practice used for assuring the quality of products or services.
There are many differences between quality control and quality assurance.
In quality assurance, a constant effort is made to enhance the quality practices in the
organization.
Therefore, continuous improvements are expected in quality functions in the company. For this,
there is a dedicated quality assurance team commissioned.
Sometimes, in larger organizations, a 'Process' team is also allocated for enhancing the
processes and procedures in addition to the quality assurance team.
Quality assurance team of the organization has many responsibilities. First and foremost,
responsibility is to define a process for achieving and improving quality.
Some organizations come up with their own process and others adopt a standard process such as
ISO or CMMi. Processes such as CMMi allow the organizations to define their own internal
processes and adhere by them.
Quality assurance function of an organization uses a number of tools for enhancing the quality
practices. These tools vary from simple techniques to sophisticated software systems.
The quality assurance professionals also should go through formal industrial trainings and get
them certified. This is especially applicable for quality assurance functions in software
development houses.
Since quality is a relative term, there is plenty of opportunity to enhance the quality of products
and services.
The quality assurance teams of organizations constantly work to enhance the existing quality of
products and services by optimizing the existing production processes and introducing new
processes.
 Assignment: 6
1. Explain Software Configuration Management (SCM)

Software Configuration Management is a process to systematically manage, organize, and

control the changes in the documents, codes, and other entities during the Software Development
Life Cycle. It is abbreviated as the SCM process in software engineering. The primary goal is to
increase productivity with minimal mistakes.

 Tasks in SCM process

1. Configuration Identification
2. Baselines
3. Change Control
 4. Configuration Status Accounting
5. Configuration Audits and Reviews

Configuration Identification:

Configuration identification is a method of determining the scope of the software system. With
the help of this step, you can manage or control something even if you don't know what it is. It is
a description that contains the CSCI type (Computer Software Configuration Item), a project
identifier and version information.

Activities during this process:

 Identification of configuration Items like source code modules, test case, and
requirements specification.
 Identification of each CSCI in the SCM repository, by using an object-oriented
approach
 The process starts with basic objects which are grouped into aggregate objects.
Details of what, why, when and by whom changes in the test are made
 Every object has its own features that identify its name that is explicit to all other
objects
 List of resources required such as the document, the file, tools, etc.

Baseline : A baseline is a formally accepted version of a software configuration item. It is

designated and fixed at a specific time while conducting the SCM process. It can only be
changed through formal change control procedures.

Activities during this process:

 Facilitate construction of various versions of an application

 Defining and determining mechanisms for managing various versions of these work
products
 The functional baseline corresponds to the reviewed system requirements
 Widely used baselines include functional, developmental, and product baselines

In simple words, baseline means ready for release.

Change Control:

Change control is a procedural method which ensures quality and consistency when changes are
made in the configuration object. In this step, the change request is submitted to software
configuration manager.

Activities during this process:

  Control ad-hoc change to build stable software development environment. Changes
are committed to the repository
 The request will be checked based on the technical merit, possible side effects and
overall impact on other configuration objects.
 It manages changes and making configuration items available during the software
lifecycle

Configuration Status Accounting:

Configuration status accounting tracks each release during the SCM process. This stage involves
tracking what each version has and the changes that lead to this version.

Activities during this process:

 Keeps a record of all the changes made to the previous baseline to reach a new
baseline
 Identify all items to define the software configuration
 Monitor status of change requests
 Complete listing of all changes since the last baseline
 Allows tracking of progress to next baseline
 Allows to check previous releases/versions to be extracted for testing

Configuration Audits and Reviews:

Software Configuration audits verify that all the software product satisfies the baseline needs. It
ensures that what is built is what is delivered.

Activities during this process:

 Configuration auditing is conducted by auditors by checking that defined processes

are being followed and ensuring that the SCM goals are satisfied.
 To verify compliance with configuration control standards. auditing and reporting the
changes made
 SCM audits also ensure that traceability is maintained during the process.
 Ensures that changes made to a baseline comply with the configuration status reports
 Validation of completeness and consistency

 Participant of SCM process:

1) Configuration Manager
2) Developer
3) Auditor
4) Project Manager:
5) User
1. Configuration Manager

 Configuration Manager is the head who is Responsible for identifying configuration

items.
 CM ensures team follows the SCM process
 He/She needs to approve or reject change requests

2. Developer

 The developer needs to change the code as per standard development activities or
change requests. He is responsible for maintaining configuration of code.
 The developer should check the changes and resolves conflicts

3. Auditor

 The auditor is responsible for SCM audits and reviews.

 Need to ensure the consistency and completeness of release.

4. Project Manager:

 Ensure that the product is developed within a certain time frame

 Monitors the progress of development and recognizes issues in the SCM process
 Generate reports about the status of the software system
 Make sure that processes and policies are followed for creating, changing, and testing

5. User

The end user should understand the key SCM terms to ensure he has the latest version of the
software

Software Configuration Management Plan

The SCMP (Software Configuration management planning) process planning begins at the early
phases of a project. The outcome of the planning phase is the SCM plan which might be
stretched or revised during the project.

 The SCMP can follow a public standard like the IEEE 828 or organization specific
standard
 It defines the types of documents to be management and a document naming.
Example Test_v1
 SCMP defines the person who will be responsible for the entire SCM process and
creation of baselines.
 Fix policies for version management & change control
 Define tools which can be used during the SCM process
 Configuration management database for recording configuration information.
Software Configuration Management Tools

Any Change management software should have the following 3 Key features:

Concurrency Management:

When two or more tasks are happening at the same time, it is known as concurrent operation.
Concurrency in context to SCM means that the same file being edited by multiple persons at the
same time.

If concurrency is not managed correctly with SCM tools, then it may create many pressing
issues.

Version Control:

SCM uses archiving method or saves every change made to file. With the help of archiving or
save feature, it is possible to roll back to the previous version in case of issues.

Synchronization:

Users can check out more than one files or an entire copy of the repository. The user then works
on the needed file and checks in the changes back to the repository. They can synchronize their
local copy to stay updated with the changes made by other team members.

Following are popular tools

1. Git: Git is a free and open source tool which helps version control. It is designed to
handle all types of projects with speed and efficiency.

2. Team Foundation Server: Team Foundation is a group of tools and technologies that

enable the team to collaborate and coordinate for building a product.

3. Ansible: It is an open source Software configuration management tool. Apart from

configuration management it also offers application deployment & task automation.

2. Difference between Software Engineering and Reverse Engineering

Software engineering Reverse engineering

Software engineering is defined as a process Reverse engineering can extract design
 of analyzing user requirements and then
designing, building, and testing software
application which will satisfy those
requirements.
IEEE, in its standard 610.12-1990, defines
software engineering as the application of a
systematic, disciplined, which is a
computable approach for the development,
operation, and maintenance of software.
Fritz Bauer defined it as ‘the establishment
and used standard engineering principles. It
helps you to obtain, economically, software
which is reliable and works efficiently on the
real machines’
Boehm defines software engineering, which
involves, ‘the practical application of
scientific knowledge to the creative design
and building of computer programs. It also
includes associated documentation needed for
developing, operating, and maintaining them.’
3. What is Change Control?
Change control is a systematic approach to managing all changes made to a product or system.
The purpose is to ensure that no unnecessary changes are made, that all changes are documented,
information from source code, but the
abstraction level, the completeness of the
documentation, the degree to which tools and
a human analyst work together, and the
Directionality of the process are highly
variable
The abstraction level of a reverse engineering
process and the tools used to effect it refers to the
sophistication of the design information that can
be extracted from source code.
That is, the reverse engineering process
should be capable of deriving procedural
design representations (a low-level
abstraction), program and data structure
information (a somewhat higher level of
abstraction), object models, data and/or
control flow models (a relatively high level of
abstraction), and entity relationship models (a
high level of abstraction).
The completeness of a reverse engineering
process refers to the level of detail that is
provided at an abstraction level. In most
cases, the completeness decreases as the
abstraction level increases.
that services are not unnecessarily disrupted and that resources are used efficiently. Within
information technology (IT), change control is a component of change management.

The change control process is usually conducted as a sequence of steps proceeding from the
submission of a change request. Typical IT change requests include the addition of features to
software applications, the installation of patches, and upgrades to network equipment.

Here's an example of a six-step process for a software change request:

1. Documenting the change request:

When the client requests the change, that request is categorized and recorded, along with
informal assessments of the importance of that change and the difficulty of implementing it.

2. Formal assessment:
The justification for the change and risks and benefits of making/not making the change are
evaluated. If the change request is accepted, a development team will be assigned. If the
change request is rejected, that fact is documented and communicated to the client.

3. Planning:
The team responsible for the change creates a detailed plan for its design and
implementation, as well as a plan for rolling back the change should it be deemed
unsuccessful.

4. Designing and testing:

The team designs the program for the software change and tests it. If the change is deemed
successful, the team requests approval and a date for implementation.

5. Implementation and review:

The team implements the program and stakeholders review the change.

6. Final assessment:
If the client is satisfied that the change was implemented satisfactorily, the change request is
closed. If the client is not satisfied, the project is reassessed and steps may be repeated.
4. Explain SAAS Architecture.
Software as a service is a software licensing and delivery model in which software is licensed on
a subscription basis and is centrally hosted. Users can access it with the help of web browsers.

SaaS is a common delivery model for many business applications, including office and
messaging software, management software, virtualization etc. It is part of the nomenclature of
cloud computing, along with infrastructure as a service (IaaS), platform as a service (PaaS),
desktop as a service (DaaS).

SAAS Architecture:

With this model, a single version of the application, with a single configuration is used for all
customers. The application is installed on multiple machines to support scalability (called
horizontal scaling). In some cases, a second version of the application is set up to offer a select
group of customers with access to pre-release versions of the applications for testing purposes. In
this traditional model, each version of the application is based on a unique code. Although an
exception, some SaaS solutions do not use multitenancy, to cost-effectively manage a large
number of customers in place. Whether multitenancy is a necessary component for software-as-
a-service is a topic of controversy.

Vertical SaaS

 A Software which answers the needs of a specific industry (e.g., software for the
healthcare, agriculture, real estate, finance industries)
 Horizontal SaaS
 The products which focus on a software category (marketing, sales, developer tools, HR)
but are industry agnostic.
 5. Explain CASE and its Process
Computer aided software engineering (CASE) is the implementation of computer facilitated
tools and methods in software development. CASE is used to ensure a high-quality and defect-
free software. CASE ensures a check-pointed and disciplined approach and helps designers,
developers, testers, managers and others to see the project milestones during development.
CASE can also help as a warehouse for documents related to projects, like business plans,
requirements and design specifications. One of the major advantages of using CASE is the
delivery of the final product, which is more likely to meet real-world requirements as it ensures
that customers remain part of the process.
CASE illustrates a wide set of labor-saving tools that are used in software development. It
generates a framework for organizing projects and to be helpful in enhancing productivity. There
was more interest in the concept of CASE tools years ago, but less so today, as the tools have
morphed into different functions, often in reaction to software developer needs. The concept of
CASE also received a heavy dose of criticism after its release.
Types of CASE Tools:

1. Diagramming Tools:
It helps in diagrammatic and graphical representations of the data and system processes. It
represents system elements, control flow and data flow among different software
components and system structure in a pictorial form.
For example, Flow Chart Maker tool for making state-of-the-art flowcharts.

2. Computer Display and Report Generators:

It helps in understanding the data requirements and the relationships involved.

3. Analysis Tools:
It focuses on inconsistent, incorrect specifications involved in the diagram and data flow. It
helps in collecting requirements, automatically check for any irregularity, imprecision in
the diagrams, data redundancies or erroneous omissions.
4. Central Repository:

It provides the single point of storage for data diagrams, reports and documents related to
project management.

5. Documentation Generators:

It helps in generating user and technical documentation as per standards. It creates

documents for technical users and end users.

6. Code Generators:

It aids in the auto generation of code, including definitions, with the help of the designs,
documents and diagrams.