(1) Software & Software Engineering

Software:
 Computer software is the product that software professionals build and then support over the long term.
 It encompasses programs that execute within a computer of any size and architecture, content that is
presented as the computer programs execute, and descriptive information in both hard copy and virtual
forms that encompass virtually any electronic media.

Characteristics of software:
[1] Software is developed or engineered; it is not manufactured in the classical sense:

 Although some similarities exist between software development and hardware manufacturing, but few
activities are fundamentally different.
 In both activities, high quality is achieved through good design, but the manufacturing phase for
hardware can introduce quality problems than software.
[2] Software doesn’t ―wear out.‖
 Hardware components suffer from the growing effects of dust, vibration, abuse, temperature extremes,
and many other environmental maladies. Stated simply, the hardware begins to wear out.
 Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory,
therefore, the failure rate curve for software should take the form of the ―idealized curve‖.
 When a hardware component wears out, it is replaced by a spare part.
 There are no software spare parts.
 Every software failure indicates an error in design or in the process through which design was translated
into machine executable code.
 Therefore, the software maintenance tasks that accommodate requests for change involve considerably
more complexity than hardware maintenance.
 However, the implication is clear—software doesn’t wear out. But it does deteriorate.

Hardware Failure curve Software Failure curve

[3] Although the industry is moving toward component-based construction, most software continues to be
custom built.

 A software component should be designed and implemented so that it can be reused in many different
programs.

1
 Modern reusable components encapsulate both data and the processing that is applied to the data,
enabling the software engineer to create new applications from reusable parts.
 In the hardware world, component reuse is a natural part of the engineering process

Difference between program and software

Program Software
1) Small in size. 1) Large in size.
2) Authors himself is user-soul. 2) Large number.
3) Single developer. 3) Team developer.
4) Adopt development. 4) Systematic development.
5) Lack proper interface. 5) Well define interface.
6) Large proper documentation. 6) Well documented

Software Myths:
Software myths are beliefs about software and the process used to build it.

(1) Management Myths:

Myth 1:
We already have a book that’s full of standards and procedures for building software. Won’t that provide
my people with everything they need to know?
Reality:
 The book of standards may very well exist, but is it used?
 Are software practitioners aware of its existence?
 Does it reflect modern software engineering practice? Is it complete? Is it adaptable?
 Is it streamlined to improve time-to-delivery while still maintaining a focus on quality?
 In many cases, the answer to all of these questions is no.
Myth 2:
If we get behind schedule, we can add more programmers and catch up.
Reality:
 Software development is not a mechanistic process like manufacturing.
 As new people are added, people who were working must spend time educating the newcomers,
thereby reducing the amount of time spent on productive development effort.
 People can be added but only in a planned and well-coordinated manner.
Myth 3:
If I decide to outsource the software project to a third party, I can just relax and let that firm build it.
Reality:

 If an organization does not understand how to manage and control software projects internally, it
will invariably struggle when it outsources software projects.

2
(2) Customer Myths:
Myth 1:
A general statement of objectives is sufficient to begin writing programs—we can fill in the details later.
Reality:
 Although a comprehensive and stable statement of requirements is not always possible, an
ambiguous ―statement of objectives‖ is a recipe for disaster.
 Unambiguous requirements are developed only through effective and continuous communication
between customer and developer.
Myth 2:
Software requirements continually change, but change can be easily accommodated because software is
flexible.
Reality:

 It is true that software requirements change, but the impact of change varies with the time at
which it is introduced.
 When requirements changes are requested early the cost impact is relatively small.
 However, as time passes, the cost impact grows rapidly—resources have been committed, a
design framework has been established, and change can cause upheaval that requires additional
resources and major design modification.

(3) Practitioner’s Myths:

Myth 1:
Once we write the program and get it to work, our job is done.
Reality:

 Industry data indicate that between 60 and 80 percent of all effort expended on software will be
expended after it is delivered to the customer for the first time.
Myth 2:
Until I get the program “running” I have no way of assessing its quality.
Reality:

 One of the most effective software quality assurance mechanisms can be applied from the
inception of a project—the technical review.
 Software reviews are a ―quality filter‖ that have been found to be more effective than testing for
finding certain classes of software defects.
Myth 3:
The only deliverable work product for a successful project is the working program.
Reality:

 A working program is only one part of a software configuration that includes many elements.
 A variety of work products (e.g., models, documents, plans) provide a foundation for successful
engineering and, more important, guidance for software support.

3
 Myth 4:
Software engineering will make us create voluminous and unnecessary documentation and will invariably
slow us down.
Reality:

 Software engineering is not about creating documents.

 It is about creating a quality product.
 Better quality leads to reduced rework.
 And reduced rework results in faster delivery times.

Software Engineering:
 Software Engineering is the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to
software.

A Layered Technology:

4
A Waterfall Process Model

The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to
software development that begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in ongoing support of the completed
software.

Figure: Waterfall Model

Limitations:
 The nature of the requirements will not change very much during development; during evolution.
 The model implies that you should attempt to complete a given stage before moving on to the next
stage.
 Does not account for the fact that requirements constantly change.
 It also means that customers cannot use anything until the entire system is complete.
 The model implies that once the product is finished, everything else is maintenance.
 Surprises at the end are very expensive
 Some teams sit ideal for other teams to finish
 Therefore, this model is only appropriate when the requirements are well-understood and changes will
be fairly limited during the design process.

When to use waterfall model?

 Requirements are very well known, clear and fixed
 Product definition is stable
 Technology is understood
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short

5
(2) Incremental Process Model
 The incremental model combines elements of linear and parallel process flows.
 The incremental model applies linear sequences in a staggered fashion as calendar time progresses.
 Each linear sequence produces deliverable ―increments‖ of the software.
 For example, word-processing software developed using the incremental paradigm 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.

Advantages:

Figure: Incremental Process Model

 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during iteration.
Disadvantages:
 Needs good planning and design.
 Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.
 Total cost is higher than waterfall.

When to use waterfall model?

 This model can be used when the requirements of the complete system are clearly defined and
understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used.
 Resources with needed skill set are not available.
 There are some high risk features and goals.

6
(3) RAD (Rapid Application Development) Process Model
 It is a type of incremental model. In RAD model the components or functions are developed in parallel as
if they were mini projects.
 The developments are time boxed, delivered and then assembled into a working prototype.
 This can quickly give the customer something to see and use and to provide feedback regarding the
delivery and their requirements.

Figure: Rapid Application Development Model

Advantages:
 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
Disadvantages:
 For large but scalable projects RAD requires sufficient human resources.
 Projects fail if developers and customers are not committed in a much shortened time-frame.
 Problematic if system cannot be modularized.
 Not appropriate when technical risks are high (heavy use of new technology).
When to use RAD model?
 RAD should be used when there is a need to create a system that can be modularized in 2-3 months of
time.
 It should be used if there’s high availability of designers for modeling and the budget is high enough to
afford their cost along with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high business knowledge are available and
there is a need to produce the system in a short span of time (2-3 months).

7
(4) Prototype process model
 The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a
throwaway prototype is built to understand the requirements.
 This prototype is developed based on the currently known requirements.
 By using this prototype, the client can get an ―actual feel‖ of the system, since the interactions with
prototype can enable the client to better understand the requirements of the desired system.
 Prototyping is an attractive idea for complicated and large systems for which there is no manual process
or existing system to help determining the requirements.
 The prototype are usually not complete systems and many of the details are not built in the prototype.
The goal is to provide a system with overall functionality.

Figure: Prototype Model

Advantages:
 Users are actively involved in the development
 Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified

Disadvantages:
 Leads to implementing and then repairing way of building systems.
 Practically, this methodology may increase the complexity of the system as scope of the system may
expand beyond original plans.
 Incomplete application may cause application not to be used as the full system was designed.

8
When to use Prototype Model?
 Prototype model should be used when the desired system needs to have a lot of interaction with the end
users.
 Typically, online systems, web interfaces have a very high amount of interaction with end users, are best
suited for Prototype model. It might take a while for a system to be built that allows ease of use and
needs minimal training for the end user.
 Prototyping ensures that the end users constantly work with the system and provide a feedback which is
incorporated in the prototype to result in a useable system. They are excellent for designing good human
computer interface systems.

(5) Spiral process model

 It was originally proposed by Barry Boehm, the spiral model is an evolutionary software process model
that couples the iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model.
 It provides the potential for rapid development of increasingly more complete versions of the software.
 The spiral development model is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
 It has two main distinguishing features. One is a cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its degree of risk.
 The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.

Figure: Spiral Process Model

 The first circuit around the spiral might result in the development of a product specification; subsequent
passes around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the software.
 Each pass through the planning region results in adjustments to the project plan.
 Cost and schedule are adjusted based on feedback derived from the customer after delivery.
 In addition, the project manager adjusts the planned number of iterations required to complete the
software.

Advantages:
 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.
 Software is produced early in the software life cycle.

9
Disadvantages:
 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.

When to use spiral process model?

 When costs and risk evaluation is important for medium to high-risk projects.
 Long-term project commitment unwise because of potential changes to economic priorities
 Users are unsure of their needs.
 Requirements are complex
 New product line Significant changes are expected (research and exploration)

(6) Agile Process Model

 Agile SDLC model is a combination of iterative and incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of working software product.
 Agile Methods break the product into small incremental builds.
 Every iteration involves cross functional teams working simultaneously on various areas like planning,
requirements analysis, design, coding, unit testing, and acceptance testing.

Advantages:
 Customer satisfaction by rapid, continuous delivery of useful software.
 Customers, developers and testers constantly interact with each other.
 Close, daily cooperation between business people and developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Disadvantages:
 In case of some software, it is difficult to assess the effort required at the beginning of the software
development life cycle.
 There is lack of emphasis on necessary designing and documentation.
 The project can easily get taken off track if the customer representative is not clear what final outcome
that they want.
 Only senior programmers are capable of taking the kind of decisions required during the development
process.

10
 Over view of Software

Agile Process:
 Any agile software process is characterized in a manner that addresses a number of key assumptions
[1] It is difficult to predict in advance which software requirements will persist and which will change. It is
equally difficult to predict how customer priorities will change as the project proceeds.
[2] For many types of software, design and construction are interleaved. That is, both activities should be
performed in tandem so that design models are proven as they are created. It is difficult to predict
how much design is necessary before construction is used to prove the design.
[3] Analysis, design, construction, and testing are not as predictable as we might like.
Agility Principles:
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2 Welcome changing requirements, even late in development.
3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
4 Business people and developers must work together daily throughout the project.
5 Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
7 Working software is the primary measure of progress.
8 Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9 Continuous attention to technical excellence and good design enhances agility.
10 Simplicity—the art of maximizing the amount of work not done—is essential.
11 The best architectures, requirements, and designs emerge from self– organizing teams.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
 ope extensions occur).

11