Software

Software is (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.

Changing nature of software

System software: System software is a collection of programs written to service other

programs. Some system software’s (e.g., compilers, editors, and file management utilities)
process complex, but determinate, information structures. Other systems applications
(e.g., operating system components, drivers, telecommunications processors) process
largely indeterminate data. In either case, the system software area is characterized by
heavy interaction with computer hardware; heavy usage by multiple users; concurrent
operation that requires scheduling, resource sharing, and sophisticated process
management; complex data structures.

Real-time software. Software that monitors/analyzes/controls real-world events

as they occur is called real time. Elements of real-time software include a data gathering
component that collects and formats information from an external environment, an
analysis component that transforms information as required by the
application, a control/output component that responds to the external environment,
and a monitoring component that coordinates all other components so that real-time
response (typically ranging from 1 millisecond to 1 second) can be maintained.
Business software. Business information processing is the largest single software
application area. Discrete "systems" (e.g., payroll, accounts receivable/payable,
inventory) have evolved into management information system (MIS) software that
accesses one or more large databases containing business information. Applications in
this area restructure existing data in a way that facilitates business operations or
management decision making. In addition to conventional data processing application,
business software applications also encompass interactive computing (e.g., point of- sale
transaction processing).
Engineering and scientific software. Engineering and scientific software have
been characterized by "number crunching" algorithms. Applications range from
astronomy to volcanology, from automotive stress analysis to space shuttle orbital
dynamics, and from molecular biology to automated manufacturing. However, modern
applications within the engineering/scientific area are moving away from conventional
numerical algorithms. Computer-aided design, system simulation, and other interactive
applications have begun to take on real-time and even system software characteristics.

Embedded software: Embedded software resides in read-only memory

and is used to control products and systems for the consumer and industrial markets.
Embedded software can perform very limited and esoteric functions (e.g., keypad control
for a microwave oven) or provide significant function and control capability (e.g., digital
functions in an automobile such as fuel control, dashboard displays, and braking
systems).
Personal computer software. Word processing, spreadsheets, computer graphics,
multimedia, entertainment, database management, personal and business financial
applications, external network, and database access are only a few of hundreds of
applications.

Web-based software. The Web pages retrieved by a browser are software that
incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g
hypertext and a variety of visual and audio formats). In essence, the network becomes a
massive computer providing an almost unlimited software resource that can be accessed
by anyone with a modem.
Artificial intelligence software. Artificial intelligence (AI) software makes use
of non numerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis. Expert systems, also called knowledge based
systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing are representative of applications within this
category.

Software Myths
• Software myths propagate false beliefs and confusion in the minds of
management, users and developers.
• Managers, who own software development responsibility, are often under strain
and pressure to maintain a software budget, time constraints, improved quality,
and many other considerations.
• Common management myths are listed in Table.

• The members of an organization can ➢ Standards are often incomplete,

acquire all-the information, they inadaptable, and outdated.
require from a manual, which contains
standards, procedures, and principles;
➢ Developers are often unaware of all the
established standards.
➢ Developers rarely follow all the known
standards because not all the standards
tend to decrease the delivery time of
software while maintaining its quality.

• If the project is behind schedule, ➢ Adding more manpower to the project,

increasing the number of which is already behind schedule,
programmers can reduce the time gap. further delays the project.
 ➢ New workers take longer to learn about
the project as compared to those
already working on the project.

• If the project is outsourced to a third ➢ Outsourcing software to a third party

party, the management can relax and does not help the organization, which
let the other firm develop software for is incompetent in managing and
them. controlling the software project
internally.
➢ The organization invariably suffers
when it out sources the software
project.

• User Myths

• Brief requirement stated in the initial ➢ Starting development with incomplete

process is enough to start development; and ambiguous requirements often lead
detailed requirements can be added at to software failure. Instead, a complete
the later stages. and formal description of requirements
is essential before starting development.
➢ Adding requirements at a later stage
often requires repeating the entire
development process.

• Software is flexible; hence software ➢ Incorporating change requests earlier in

requirement changes can be added
during any phase of the development
process.
the development process costs lesser
than those that occurs at later stages.
This is because incorporating changes
later may require redesigning and extra
resources.

• Developer Myths
 • Software development is considered • 50% to 70% of all the efforts are
complete when the code is delivered. expended after the software is delivered
to the user.

• The success of a software project • The quality of programs is not the only
depends on the quality of the product factor that makes the project successful
produced. instead the documentation and software
configuration also plays crucial role.

• Software engineering requires• Software engineering is about creating

unnecessary documentation, which quality at every level of the software
slows down the project. project. Proper documentation enhances
quality which results in reducing the
amount of rework.

• Software quality can be assessed only
after the program is executed.
• The quality of software can be measured
during any phase of development process
by applying some quality assurance
mechanism. One such mechanism is
formal technical review that can be
effectively used during each phase of
development to uncover certain errors.

Software engineering layered technology

• Software engineering is a fully layered technology.

• To develop a software, we need to go from one layer to another.
• All these layers are related to each other and each layer demands the fulfillment of the
previous layer.

Quality focus
The characteristics of good quality software are:
 • The bedrock that supports software engineering is a quality focus
• Every organization commited to quality.
• Correctness of the functions required to be performed by the software.
• Maintainability of the software
• Integrity i.e. providing security so that the unauthorized user cannot access
information or data.
• Usability i.e. the efforts required to use or operate the software.

2. Process
• It is the base layer or foundation layer for the software engineering.
• SE process is the GLUE that holds all the technology layers together and enables the
timely development of computer software.
• It defines a framework that includes different activities and tasks.
• In short, it covers all activities, actions and tasks required to be carried out for software
development.

3. Methods
• The method provides the answers of all 'how-to' that are asked during the process.
• It provides the technical way to implement the software.
• It includes collection of tasks starting from communication, requirement analysis,
analysis and design modelling, program construction, testing and support.

4. Tools
• The software engineering tool is an automated support for the software development.
• The tools are integrated i.e the information created by one tool can be used by the other
tool.
• For example: The Microsoft publisher can be used as a web designing tool.
: Figma is an interface design tool that enables multiple designers to
collaborate in real-time

: Avocode makes it extremely easy for frontend developers to code

websites or apps from Photoshop or Sketch design

Process Framework
• The process of framework defines a small set of activities that are applicable to all types
of projects.
• The software process framework is a collection of task sets.
• Task sets consist of a collection of small work tasks, project milestones, work
productivity and software quality assurance points.

The following generic process framework is applicable to the vast majority of software
projects :
1. Communication: This framework activity involves heavy communication and
collaboration with the customer (and other stakeholders) and encompasses
requirements gathering and other related activities.
Action –Requirement gathering
Tasks- 1. Make list of stakeholder
2. Invite all stake holder to an informal meeting
3. Ask for features and function required
4. Discuss requirement and build final list
5. Prioritize requirement
 2. Planning: This activity establishes a plan for the software engineering work that
follows. It describes the technical tasks to be conducted, the risks that are likely, the
resources that will be required, the work products to be produced and a work schedule.
3. Modeling: This activity encompasses the creation of models that allow the developer
and the customer to better understand software requirements and the design that will
achieve those requirements.
Action 1- Analysis
Tasks 1. Requirement Gathering
2. Elaboration
3. Negotiation
4. Specification
5. Validation

Action 2-Design
Tasks 1.Data design
2.interface design
3.Component level design

4. Construction: This activity combines code generation (either manual or

automated) and the testing that is required to uncover errors in the code.
5. Deployment: The software is delivered to the customer who evaluates the delivered
product and provides feedback based on evaluation.

• The framework can be described in the generic view of software engineering is

completed by number of “Umbrella Activities” and they are:
1. Software Project Tracking and Control - : allows the team to assess
progress against the project plan and take necessary action to maintain schedule.
2. Risk Management: Assesses the risks that may affect the outcome of the
project or the quality.
3. Software quality assurance: defines and conducts the activities required to
ensure software quality.
 4. Formal Technical Review: uncover and remove errors before they propagate
to the next action.
5. Measurement: defines and collects process, project, and product measures that
assist the team in delivering S/W that meets customers’ needs.
6. Software configuration management: Manages the effect of change
throughout the S/W process
7. Reusability management: defines criteria for work product reuse.
8. Work product preparation and production: encompasses the activities
required to create work products such as models, documents, etc.

Q1) How do Process differ from one another?

• The overall flow of activities and tasks and their interdependencies among
activities and tasks
• The degree to which work tasks are defined wthin each framework

Capability Maturity Model

• The Capability Maturity Model (CMM) is a methodology used to develop and refine
an organization's software process. The model describes a five-level evolutionary
path of increasingly organized and systematically more mature processes.
• To determine an organization’s current state of process maturity’s the SEI uses an
assessment that results in a five point grading scheme
• Capability Maturity Model is a bench-mark for measuring the maturity of an
organization’s software process. To determine an organization’s current state of
process maturity, the SEI uses an assessment that results in a five point grading
scheme.
• Each level ranks the organization according to its standardization of processes in the
subject area being assessed.
• CMMI represent process meta model in two ways, Continuous Model, staged
model
• Continuous Model-it describes a process in two dimensional process area capability
profile
Each process area is formally assessed against specific goal and rated according
following capability levels
• Level 0 Incomplete—the process area e.g.(requirement management) is not
performed or does not achieve all goals defined by CMMI level 1.

• Level 1 Performed: All specific goals of this process area have been achieved Work
task require to produce work product are being conducted.

• Level 2 – Managed: All work associated with process area are being conformed to
an organizationally defined policy. All people doing work have access to resources to
get job done. Stakeholders are actively involved in process area as required. All work
tasks and work products are monitored, controlled and reviewed.

• Level 3: At the defined level, an organization has developed its own standard
software process through greater attention to documentation, standardization, and
integration. All projects use an approved version of the organizations standard
software process for developing and maintaining software.

• Level 4: Quantitatively managed level, an organization monitors and controls

its own processes through data collection and analysis. In addition to implementing
standard processes, company has installed systems to measure the quality of those
processes across all projects. . Quantitative objectives are based on the needs of the
 customer, end users, organization, and process implementers. Quality and
performance of process are understood in statistical terms and are managed
throughout the life of the processes.

• Level 5: At the optimizing level, processes are constantly being improved

through monitoring feedback from current processes and introducing innovative
processes to better serve the organization's particular needs.

There are three types of prescriptive process models. They are:

1. The Waterfall Model

2. Incremental Process model

1. The Waterfall Model

• The waterfall model is also called as 'Linear sequential model' or 'Classic life
cycle model'.
• In this model, each phase is fully completed before the beginning of the next phase.
• This model is used for the small projects.
• In this model, feedback is taken after each phase to ensure that the project is on the
right path.
• Testing part starts only after the development is complete.
• The linear sequential model suggests a systematic, sequential approach to software
development that begins at the system level and progresses through analysis, design,
coding, testing, and support.
• In this Waterfall model, typically, the outcome of one phase acts as the input for the
next phase sequentially.

• Requirements: The first phase involves understanding what need to be design

and what is its function, purpose etc. Here, the specifications of the input and
output or the final product are studied and marked.

• System Design: The requirement specifications from first phase are studied in
this phase and system design is prepared. System Design helps in specifying
hardware and system requirements and also helps in defining overall system
architecture. The software code to be written in the next stage is created now.

• Implementation: With inputs from system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit
is developed and tested for its functionality which is referred to as Unit Testing.

• Integration and Testing: All the units developed in the implementation phase
are integrated into a system after testing of each unit. The software designed,
needs to go through constant software testing to find out if there are any flaw or
errors. Testing is done so that the client does not face any problem during the
installation of the software.

• Deployment of System: Once the functional and non-functional testing is done,

the product is deployed in the customer environment or released into the
market.

• Maintenance: This step occurs after installation, and involves making

modifications to the system or an individual component to alter attributes or
improve performance. These modifications arise either due to change requests
initiated by the customer, or defects uncovered during live use of the system.
Client is provided with regular maintenance and support for the developed
software.

Advantages of waterfall model

• The waterfall model is simple and easy to understand, implement, and use.
• All the requirements are known at the beginning of the project, hence it is easy to
manage.
• It avoids overlapping of phases because each phase is completed at once.
• This model works for small projects because the requirements are understood
very well.
 • This model is preferred for those projects where the requirement are fixed and
work is to proceed to completion in linear manner.

Disadvantages of the waterfall model

• It is often difficult for the customer to state all requirements explicitly. The linear
sequential model requires this and has difficulty accommodating the natural uncertainty
that exists at the beginning of many projects.
• It is a poor model for long projects.
• The problems with this model are uncovered, until the software testing.
• The amount of risk is high.

Incremental Process model

• The incremental model combines the elements of waterfall model and they are applied
in an iterative fashion.

• The incremental model delivers software in small but usable pieces, called “increments.”
In general, each increment builds on those that have already been delivered.
• The first increment in this model is generally a core product.
• Each increment builds the product and submits it to the customer for any suggested
modifications.
• The next increment implements on the customer's suggestions and add additional
requirements in the previous increment.
This process is repeated until the product is finished.
For example, For example, word-processing software developed using the
incremental Model it might deliver basic file management, editing, and document
production functions in the first increment; more sophisticated editing and document
production capabilities in the second increment; spelling and grammar checking in the
third increment; and advanced page layout capability in the fourth increment.

Incremental development is particularly useful when staffing is unavailable for a

complete implementation by the business deadline that has been established for the
project. Early increments can be implemented with fewer people. If the core product is
well received, then additional staff (if required) can be added to implement the next
increment. In addition, increments can be planned to manage technical risks.

• For example, a major system might require the availability of new hardware that is
underdevelopment and whose delivery date is uncertain. It might be possible to plan
 early increments in a way that avoids the use of this hardware, thereby enabling partial
functionality to be delivered to end-users without inordinate delay.

Advantages of incremental model

• This model is flexible because the cost of development is low and initial product
delivery is faster.
• It is easier to test and debug during the smaller iteration.
• The working software generates quickly and early during the software life cycle.
• The customers can respond to its functionalities after every increment.
Disadvantages of the incremental model
• The cost of the final product may cross the cost estimated initially.
• This model requires a very clear and complete planning.
• The planning of design is required before the whole system is broken into small
increments.
• The demands of customer for the additional functionalities after every increment
causes problem during the system architecture

RAD model

• RAD is a Rapid Application Development model.

• RAD model is designed for larger projects that must be delivered in tight time frames
(short time).
• If all requirements are well understood and project scope is constrained then by using
the RAD model, software product is developed in a short period of time (60 to 90 days).
• Like all other models this models also maps into generic framework activities.
• The initial activity starts with the communication between customer and developer.
• Planning depends upon the initial requirements and then the requirements are divided
into groups.
• Planning is more important to work together on different modules.
• In the RAD model, the functional modules are developed in parallel as prototypes and
are integrated to make the complete product for faster product delivery.
The RAD model consist of following phases:

1. Business Modeling
• Business modeling consist of the flow of information between various functions in the
project.
• For example what type of information is produced by every function and which are the
functions to handle that information.
• A complete business analysis should be performed to get the essential business
information.
2. Data modeling
• The information in the business modeling phase is refined into the set of objects and it is
essential for the business.
• The attributes of each object are identified and define the relationship between objects.
3. Process modeling
• The data objects defined in the data modeling phase are changed to fulfil the information
flow to implement the business model.
• The process description is created for adding, modifying, deleting or retrieving a data
object.
4. Application generation
• In the application generation phase, the actual system is built.
• To construct the software the automated tools are used.
5. Testing and turnover
• The prototypes are independently tested after each iteration so that the overall testing time
is reduced.
• The data flow and the interfaces between all the components are are fully tested. Hence,
most of the programming components are already tested.
 Like all process models, the RAD approach has drawbacks :

• For large but scalable projects, RAD requires sufficient human resources to
create the right number of RAD teams.

• RAD requires developers and customers who are committed to the rapid-fire
activities necessary to get a system complete in a much abbreviated time
frame. If commitment is lacking from either constituency, RAD projects will fail.

• Not all types of applications are appropriate for RAD. If a system cannot be
properly modularized, building the components necessary for RAD will be
problematic.

• If high performance is an issue and performance is to be achieved through tuning

the interfaces to system components, the RAD approach may not work.

• RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology
 Evolutionary Process Models

• Evolutionary models are iterative type models.

• They allow developing more complete versions of the software.
• These models are applied because as the requirements often change so the end product
will be unrealistic, where a complete version is impossible due to tight market
deadlines it is better to introduce a limited version to meet the pressure. Thus the
software engineers can follow a process model that has been explicitly designed to
accommodate a product that gradually complete over time.

The Prototyping model

Often, a customer defines a set of general objectives for software but does not identify
detailed input, processing, or output requirements. In other cases, the developer may be
unsure of the efficiency of an algorithm, the adaptability of an operating system, or the
form that human/machine interaction should take. In these, and many other situations,
a Prototyping paradigm may offer the best approach.

• Prototype is defined as first or preliminary form using which other forms are
copied or derived.
• Prototype model is a set of general objectives for software.
• It does not identify the requirements like detailed input, output.
• It is software working model of limited functionality.
• In this model, working programs are quickly produced.

(i) Communication :
Firstly, developer and customer meet and define the overall objectives, requirements,
and outline areas where further definition is mandatory.

(ii) Quick Plan : Based on the requirements and others of the communication part a
quick plane is made to design the software.

(iii) Modeling Quick Design : Based on the quick plane, ‘A Quick Design’ occurs. The
quick design focuses on a representation of those aspects of the software that will be
visible to the customer/user, such as input approaches and output formats.
 (iv) Construction of Prototype : The quick design leads to the construction of a
prototype.

(v) Deployment, delivery and feedback : The prototype is evaluated by the

customer/user and used to refine requirements for the software to be developed. All these
steps are repeated to tune the prototype to satisfy user’s need. At the same time enable
the developer to better understand what needs to be done

Problems With Prototype Model :

(i) In the rush to get the software working the overall software quality or long-term
maintainability will not get consideration. So software, in that way, gets the need of
excessive modification to ensure quality.

(ii) The developer may choose inappropriate operating system, algorithms, language in
the rush to make the prototype working.

Prototyping is an effective paradigm for software engineering. It necessary to build the

prototype to define requirements and then to engineer the software with a eye toward
quality.

Spiral model
• The spiral model is an evolutionary software process model that combines the iterative
nature of prototyping with the controlled and systematic aspects of the linear sequential
model.
• Using 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 system
are produced.
• The development team in Spiral-SDLC model starts with a small set of requirement and
goes through each development phase for those set of requirements.
• The development team adds functionality for the additional requirement in every-
increasing spirals until the application is ready for the production phase.
• The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis.
• A software project repeatedly passes through these phases in iterations (called Spirals
in this model).

Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.

• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.

Disadvantages of Spiral model:

• Can be a costly model to use.

• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

Concurrent Process Modeling

 • The concurrent development model, sometimes called concurrent engineering.
• It can be represented schematically as a series of framework activities, Software
engineering actions of tasks, and their associated states.
• All activities exist concurrently but reside in different states.
• For example, early in the project the communication activity has completed its
first iteration and exists in the awaiting changes state. The modeling activity
which existed in the none state while initial communication was completed now
makes a transition into underdevelopment state.
• If, however, the customer indicates the changes in requirements must be made,
the modeling activity moves from the under development state into the
awaiting changes state.
• The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the Software engineering activities,
actions, or tasks.

Advantages of the concurrent development model

• This model is applicable to all types of software development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
• It needs better communication between the team members. This may not be achieved
all the time.
• It requires remembering the status of the different activities.