CSC 615'2 Lecture 2

1

• CSC 615.2 - Lecture 2
• Software Development Process
• Structured Design
• Defect Removal
• Correctness checking
• Software lifecycle models

2
Definition A software development process is a
structure imposed on the development of a
software product. There are several models for
such processes, each describing approaches to a
variety of tasks or activities that take place
during the process.
3

• Requirements
• Architecture
• Implementation
• Testing
• Deployment

4

• The development of software is an extremely risky
  activity. How do you succeed in producing high
  quality business software in an environment of
  constant change?
• Business needs that drive the creation of
  software are constantly shifting
• The technology available to create and support
  software changes daily

5

• Embracing Change and Delivering Business Value
• In an environment of constant change, the
  processes used to create business software must
  not only accommodate change, but embrace it. A
  modern software development process must
• Realize that change will occur constantly and
  allow that change to feed back into the
  development flow
• Strive to understand the real business needs and
  provide solutions for those needs
• Minimize risk by delivering the highest business
  value as quickly as possible
• Ensure the continuous creation of release-quality
  builds

6

• Process Improvement through Leadership
• Organizations must be helped to improve processes
  by providing mentors well-seasoned in full SDLC
  Java projects that guide you through the
  implementation of modern best practices,
  including
• Iterative and incremental project management
  Plan and manage an iterative project to begin to
  realize business value as soon as possible
• Scenario-based requirements management Describe
  usage scenarios that form the basis of planning,
  design, development, and testing
• Continuous build and test Establish a
  development environment that enables continuous
  build and test

7
Continuous Integration and Automated Build
Services Perhaps one of the most beneficial
practices you can make to your organization's
Software Development Life Cycle is to implement a
continuous integration environment.  By
implementing a continuous integration
environment, your project's validity is checked
and tested every time there is a development
commit to the source code repository. Having an
automated build system comprises many different
components.  The main purpose for having a
continuous integration environment is to be able
to dependably reproduce a stable build. In order
to do this, you need to implement an automated
build process, that is IDE-independent. 
Libraries such as Ant and Maven are made for this
purpose and serve well to create an automated
build script.
8

• There are several steps to an automated build. 
  Such things as
• code compilation,
• javadoc generation,
• packaging into jar and war files, and
• deployment
• are standard build practices.  But in order to
  provide a better validation process, there are
  several additional items that should be added to
  the build process.  There are several open source
  libraries that will assist in providing an
  automated code review.  PMD, Checkstyle, and
  Findbugs are libraries that include many standard
  quality and standards based checks, and they can
  be extended to include custom, organization-specif
  ic rules.

9
Automated unit tests is also another key factor
to providing a quality build process.  Libraries
such as Junit, Easymock, Dbunit, and Http Unit
provide a way for developers to create automated
unit tests that check for the code's quality, and
ability to perform the functions required of
it. A final area that can be added to the build
process is dependency management.  If you have
several different components that get built and
assembled into other projects, having automated
dependency management can greatly simplify the
entire build process. In order to execute this
process each time there is a commit to the source
code repository, a continuous integration system
is used.  Luntbuild and CruiseControl are two
popular open source systems, and QuickBuild is a
cost-effective commercial solution to better
manage a larger set of projects.
10
Requirement Customers typically know what they
want, but not what software should do, while
incomplete, ambiguous or contradictory
requirements are recognized by skilled and
experienced software engineers. Frequently
demonstrating live code may help reduce the risk
that the requirements are incorrect.
11
Specification This is the task of precisely
describing the software to be written, possibly
in a rigorous way. In practice, most successful
specifications are written to understand and
fine-tune applications that were already
well-developed, although safety-critical software
systems are often carefully specified prior to
application development. Specifications are most
important for external interfaces that must
remain stable.
12
Software Architecture The architecture of a
software system refers to an abstract
representation of that system. Architecture is
concerned with making sure the software system
will meet the requirements of the product, as
well as ensuring that future requirements can be
addressed. The architecture step also addresses
interfaces between the software system and other
software products, as well as the underlying
hardware or the host operating system.
13
Testing Testing of parts of software, especially
where code by two different engineers must work
together, falls to the software engineer
14
Documentation An important (and often overlooked)
task is documenting the internal design of
software for the purpose of future maintenance
and enhancement. Documentation is most important
for external interfaces. Software Training and
Support  A large percentage of software projects
fail because the developers fail to realize that
it doesn't matter how much time and planning a
development team puts into creating software if
nobody in an organization ends up using it.
People are occasionally resistant to change and
avoid venturing into an unfamiliar area so, as a
part of the deployment phase, it is very
important to have training classes for the most
enthusiastic software users (build excitement and
confidence), shifting the training towards the
neutral users intermixed with the avid
supporters, and finally incorporate the rest of
the organization into adopting the new software.
Users will have lots of questions and software
problems which leads to the next phase of
software
15
Maintenance Maintaining and enhancing software
to cope with newly discovered problems or new
requirements can take far more time than the
initial development of the software. Not only may
it be necessary to add code that does not fit the
original design but just determining how software
works at some point after it is completed may
require significant effort by a software
engineer. About ? of all software engineering
work is maintenance, but this statistic can be
misleading. A small part of that is fixing bugs.
Most maintenance is extending systems to do new
things, which in many ways can be considered new
work. In comparison, about ? of all civil
engineering, architecture, and construction work
is maintenance in a similar way.
16
SEQUENCE First, lets take a look at the sequence
structure. The sequence of operations is A, B,
and C (see Figure 1). This sequence has one entry
point and one exit, a key premise of structured
design. The operations A, B, and C may be
complicated routines, but testing is
straightforward and can be completed with a
certainty that youve done it correctly.
17
Many times A, B, and C are referred to as
processes. These processes can be as simple as
performing an arithmetic operation (a b c) or
as complicated as RepaintTheUsersScreen(). Also,
they can be referred to as a single process.
Lets call it process ABC (see Figure 2).
You can divide and conquer, break it down into
modules, or structure that design. You have a
building block that can start small, be tested,
and grow to unlimited size and complexity. As I
describe different types of structures, notice
that they all have one entry and one exit. All
the structures can be thought of as or reduced to
a simple sequence structure, which is completely
understandable and testable.
18
SELECTION In order to understand the selection
structure, you need to know what a condition is.
Think of it as a test. For example, is A less
than 10? Or, is the A/D converter complete? Those
are conditions. If the condition is true, you
execute process E. If the condition is false, you
execute D. Note that both D and E do not need to
be present, either can be missing. If both are
missing, then the test is not necessary. Again,
this structure has only one entry and exit and is
still completely testable.
Figure 3 Whether the condition is true or false
determines how the selection structure for the
process will appear.
19
ITERATION/LOOPING The third structural element
is iteration, or looping. In this situation, the
condition is tested, and if it is true, then
process F is executed and the test is repeated.
If the condition is not true, then the program
continues. This is commonly called the while loop
(see Figure 4).
Figure 4 When the condition is false, the
program continues. This is called a while loop.
20
A slight variation in the construction of this
structure is called the until loop, which can be
seen in Figure 5.
You can define more structures, such as a case or
switch structure, which may make your design more
compact or understandable. There are provisions
in most languages for this. BASIC has its case
statement, and C has its switch statement. But,
you can construct either of those out of the
three structures.
21
Defect Removal
Defect Removal Effectiveness (or efficiency as
used by some writers) is calculated Defects
removed during a development phase x
100 Defects latent in the product at that
phase Since the latent defects in a software
product is unknown at any point in time, it is
approximated by adding the number of defects
removed during the phase to the number of defects
found later (but that existed during that phase).
22
For example, assume that the following table
reflects the defects detected during the
specified phases and the phase where those
defects were introduced.
23
The Defect Removal Effectiveness for each of the
phases would be as follows Requirements DRE 10
/ (103021) x 100 63 Design DRE (318) /
(302118452) x 100 60 Coding DRE
(0426) / (0214522687) x 100
55 Testing DRE (258) / (215287) x 100
60   Defect Removal Effectiveness can also be
calculated for the entire development cycle to
examine defect detection efforts before the
product is released to the field. According to
Capers Jones, world class organizations have
Development DRE greater than 95. Development
DRE (Pre-release Defect) / (Total Defects) x
100 (10321845268) / (10321184522
687) x 100 88
24
The longer a defect exists in a product before it
is detected, the more expensive it is to fix.
Knowing the DRE for each phase can help an
organization target its process improvement
efforts to improve defect detection methods where
they can be most effective. Future DRE measures
can then be used to monitor the impact of those
improvement efforts.
25
Correctness Checking The correctness checking
techniques are  -      Normalization -      Proce
ss dependency checking -      Redundancy
checking -      Quantity cross-checking -      Str
uctured walkthroughs   Purpose Correctness
checking enables us to confirm that the business
area model is an accurate representation of the
area and that it conforms to the IEM rules and
conventions.   In particular, consider the
following questions -       Have the attribute
types been assigned to the correct entity
types? -       Do the models exclude all
unnecessary elements? -       Are the information
views consistent across processes? -       Does
the model look right to the end-users?   The
result of correctness checking is a "correct"
business area model on which to base the Business
System Design stage.
26
Software Lifecycle Models
1. System Development Life Cycle (SDLC)
Model This is also known as Classic Life Cycle
Model (or) Linear Sequential Model (or) Waterfall
Method. This model has the following activities.
System/Information Engineering and Modeling As
software is always of a large system (or
business), work begins by establishing the
requirements for all system elements and then
allocating some subset of these requirements to
software. This system view is essential when the
software must interface with other elements such
as hardware, people and other resources. System
is the basic and very critical requirement for
the existence of software in any entity. So if
the system is not in place, the system should be
engineered and put in place. In some cases, to
extract the maximum output, the system should be
re-engineered and spruced up. Once the ideal
system is engineered or tuned, the development
team studies the software requirement for the
system.
27
Software Requirement Analysis This process is
also known as feasibility study. In this phase,
the development team visits the customer and
studies their system. They investigate the need
for possible software automation in the given
system. By the end of the feasibility study, the
team furnishes a document that holds the
different specific recommendations for the
candidate system. It also includes the personnel
assignments, costs, project schedule, target
dates etc.... The requirement gathering process
is intensified and focussed specially on
software. To understand the nature of the
program(s) to be built, the system engineer or
"Analyst" must understand the information domain
for the software, as well as required function,
behavior, performance and interfacing. The
essential purpose of this phase is to find the
need and to define the problem that needs to be
solved . System Analysis and Design In this
phase, the software development process, the
software's overall structure and its nuances are
defined. In terms of the client/server
technology, the number of tiers needed for the
package architecture, the database design, the
data structure design etc... are all defined in
this phase. A software development model is thus
created. Analysis and Design are very crucial in
the whole development cycle. Any glitch in the
design phase could be very expensive to solve in
the later stage of the software development. Much
care is taken during this phase. The logical
system of the product is developed in this phase.
28
Code Generation The design must be translated
into a machine-readable form. The code generation
step performs this task. If the design is
performed in a detailed manner, code generation
can be accomplished without much complication.
Programming tools like compilers, interpreters,
debuggers etc... are used to generate the code.
Different high level programming languages like
C, C, Pascal, Java are used for coding. With
respect to the type of application, the right
programming language is chosen. Testing Once the
code is generated, the software program testing
begins. Different testing methodologies are
available to unravel the bugs that were committed
during the previous phases. Different testing
tools and methodologies are already available.
Some companies build their own testing tools that
are tailor made for their own development
operations. Maintenance The software will
definitely undergo change once it is delivered to
the customer. There can be many reasons for this
change to occur. Change could happen because of
some unexpected input values into the system. In
addition, the changes in the system could
directly affect the software operations. The
software should be developed to accommodate
changes that could happen during the post
implementation
29
2. Prototyping Model This is a cyclic version of
the linear model. In this model, once the
requirement analysis is done and the design for a
prototype is made, the development process gets
started. Once the prototype is created, it is
given to the customer for evaluation. The
customer tests the package and gives his/her feed
back to the developer who refines the product
according to the customer's exact expectation.
After a finite number of iterations, the final
software package is given to the customer. In
this methodology, the software is evolved as a
result of periodic shuttling of information
between the customer and developer. This is the
most popular development model in the
contemporary IT industry. Most of the successful
software products have been developed using this
model - as it is very difficult (even for a whiz
kid!) to comprehend all the requirements of a
customer in one shot. There are many variations
of this model skewed with respect to the project
management styles of the companies. New versions
of a software product evolve as a result of
prototyping.
30
3. Rapid Application Development (RAD) Model The
RAD model is a linear sequential software
development process that emphasizes an extremely
short development cycle. The RAD model is a "high
speed" adaptation of the linear sequential model
in which rapid development is achieved by using a
component-based construction approach. Used
primarily for information systems applications,
the RAD approach encompasses the following
phases Business modeling The information flow
among business functions is modeled in a way that
answers the following questions What information
drives the business process? What information is
generated? Who generates it? Where does the
information go? Who processes it? Data
modeling The information flow defined as part of
the business modeling phase is refined into a set
of data objects that are needed to support the
business. The characteristic (called attributes)
of each object is identified and the
relationships between these objects are defined.
31
Process modeling The data objects defined in the
data-modeling phase are transformed to achieve
the information flow necessary to implement a
business function. Processing the descriptions
are created for adding, modifying, deleting, or
retrieving a data object. Application
generation The RAD model assumes the use of the
RAD tools like VB, VC, Delphi etc... rather
than creating software using conventional third
generation programming languages. The RAD model
works to reuse existing program components (when
possible) or create reusable components (when
necessary). In all cases, automated tools are
used to facilitate construction of the
software. Testing and turnover Since the RAD
process emphasizes reuse, many of the program
components have already been tested. This
minimizes the testing and development time.
32
4. Component Assembly Model Object technologies
provide the technical framework for a
component-based process model for software
engineering. The object oriented paradigm
emphasizes the creation of classes that
encapsulate both data and the algorithm that are
used to manipulate the data. If properly
designed and implemented, object oriented classes
are reusable across different applications and
computer based system architectures. Component
Assembly Model leads to software reusability. The
integration/assembly of the already existing
software components accelerate the development
process. Nowadays many component libraries are
available on the Internet. If the right
components are chosen, the integration aspect is
made much simpler.
33
Conclusion All these different software
development models have their own advantages and
disadvantages. Nevertheless, in the contemporary
commercial software development world, the fusion
of all these methodologies is incorporated.
Timing is very crucial in software development.
If a delay happens in the development phase, the
market could be taken over by the competitor.
Also if a 'bug' filled product is launched in a
short period of time (quicker than the
competitors), it may affect the reputation of the
company. So, there should be a trade-off between
the development time and the quality of the
product. Customers don't expect a bug free
product but they expect a user-friendly product.
That results in Customer Ecstasy!