Software Engineering & TQM (MCA 401)

Part-1

Software Engineering (SE) is a profession dedicated to designing, implementing,

and modifying software so that it is of higher quality, more affordable, maintainable,
and faster to build. It is a "systematic approach to the analysis, design, assessment,
implementation, test, maintenance and re-engineering of a software by applying
engineering to the software".

The Systems Development Life Cycle (SDLC), or Software Development Life

Cycle in systems engineering, information systems and software engineering, is the
process of creating or altering systems, and the models and methodologies that
people use to develop these systems. The concept generally refers to computer or
information systems.

Computer systems are complex and often (especially with the recent rise of Service-
Oriented Architecture) link multiple traditional systems potentially supplied by
different software vendors. To manage this level of complexity, a number of SDLC
models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid
prototyping"; "incremental"; and "synchronize and stabilize".

• Project planning, feasibility study: Establishes a high-level view of the intended project
and determines its goals.
 • Systems analysis, requirements definition: Refines project goals into defined functions
and operation of the intended application. Analyzes end-user information needs.

• Systems design: Describes desired features and operations in detail, including screen
layouts, business rules, process diagrams, pseudocode and other documentation.

• Implementation: The real code is written here.

• Integration and testing: Brings all the pieces together into a special testing environment,
then checks for errors, bugs and interoperability.

• Acceptance, installation, deployment: The final stage of initial development, where the
software is put into production and runs actual business.

• Maintenance: What happens during the rest of the software's life: changes, correction,
additions, and moves to a different computing platform and more. This, the least
glamorous and perhaps most important step of all, goes on seemingly forever.

System analysis

The goal of system analysis is to determine where the problem is in an attempt to fix the system.
This step involves breaking down the system in different pieces to analyze the situation,
analyzing project goals, breaking down what needs to be created and attempting to engage users
so that definite requirements can be defined. Requirements analysis sometimes requires
individuals/teams from client as well as service provider sides to get detailed and accurate
requirements....often there has to be a lot of communication to and from to understand these
requirements. Requirement gathering is the most crucial aspect as many times communication
gaps arise in this phase and this leads to validation errors and bugs in the software program......

Design

In systems design the design functions and operations are described in detail, including screen
layouts, business rules, process diagrams and other documentation. The output of this stage will
describe the new system as a collection of modules or subsystems.

The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be
produced as a result of interviews, workshops, and/or prototype efforts.

Design elements describe the desired software features in detail, and generally include functional
hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams,
pseudocode, and a complete entity-relationship diagram with a full data dictionary. These design
elements are intended to describe the software in sufficient detail that skilled programmers may
develop the software with minimal additional input design.

Implementation
Modular and subsystem programming code will be accomplished during this stage. Unit testing
and module testing are done in this stage by the developers. This stage is intermingled with the
next in that individual modules will need testing before integration to the main project.

Testing

The code is tested at various levels in software testing. Unit, system and user acceptance testings
are often performed. This is a grey area as many different opinions exist as to what the stages of
testing are and how much if any iteration occurs. Iteration is not generally part of the waterfall
model, but usually some occur at this stage.in the testing the whole system is test one by one

Following are the types of testing:

• Defect testing
• Path testing
• Data set testing.
• Unit testing
• System testing
• Integration testing
• Black box testing
• White box testing
• Regression testing
• Automation testing
• User acceptance testing
• Performance testing
• Production process that ensures that the program performs the intended task.

Operations and maintenance

The deployment of the system includes changes and enhancements before the decommissioning
or sunset of the system. Maintaining the system is an important aspect of SDLC. As key
personnel change positions in the organization, new changes will be implemented, which will
require system updates.

Complementary to SDLC

Complementary Software development methods to Systems Development Life Cycle (SDLC)

are:

• Software Prototyping
• Joint Applications Design (JAD)
• Rapid Application Development (RAD)
• Extreme Programming (XP); extension of earlier work in Prototyping and RAD.
• Open Source Development
• End-user development
• Object Oriented Programming
Comparison of Methodology Approaches
Open
SDLC RAD Objects JAD Prototyping End User
Source
Control Formal MIS Weak Standards Joint User User
Time Frame Long Short Medium Any Medium Short Short
Users Many Few Few Varies Few One or Two One
MIS staff Many Few Hundreds Split Few One or Two None
Transaction/DSS Transaction Both Both Both DSS DSS DSS
Interface Minimal Minimal Weak Windows Crucial Crucial Crucial
Documentation
Vital Limited Internal In Objects Limited Weak None
and training
Integrity and
Vital Vital Unknown In Objects Limited Weak Weak
security
Reusability Limited Some Maybe Vital Limited Weak None

A comparison of the strengths and weaknesses of SDLC:

Strength and Weaknesses of SDLC

Strengths Weaknesses
Control. Increased development time.
Monitor Large projects. Increased development cost.
Detailed steps. Systems must be defined up front.
Evaluate costs and completion targets. Rigidity.
Documentation. Hard to estimate costs, project overruns.
Well defined user input. User input is sometimes limited.
Ease of maintenance.
Development and design standards.
Tolerates changes in MIS staffing.

An alternative to the SDLC is Rapid Application Development, which combines prototyping,

Joint Application Development and implementation of CASE tools. The advantages of RAD are
speed, reduced development cost, and active user involvement in the development process.

------------------------------------------------------------------------------------

WATERFALL MODEL
The Waterfall model is a sequential design process, often used in software development
processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the
phases of Conception, Initiation, Analysis, Design, Construction, Testing and Maintenance.

The waterfall development model originates in the manufacturing and construction industries;
highly structured physical environments in which after-the-fact changes are prohibitively costly,
if not impossible. Since no formal software development methodologies existed at the time, this
hardware-oriented model was simply adapted for software development.

Advantages

The waterfall model, as described above, offers numerous advantages for software developers.
First, the staged development cycle enforces discipline: every phase has a defined start and end
point, and progress can be conclusively identified (through the use of milestones) by both vendor
and client. The emphasis on requirements and design before writing a single line of code ensures
minimal wastage of time and effort and reduces the risk of schedule slippage, or of customer
expectations not being met.

Getting the requirements and design out of the way first also improves quality; it's much easier to
catch and correct possible flaws at the design stage than at the testing stage, after all the
components have been integrated and tracking down specific errors is more complex. Finally,
because the first two phases end in the production of a formal specification, the waterfall model
can aid efficient knowledge transfer when team members are dispersed in different locations.
Criticisms

Despite the seemingly obvious advantages, the waterfall model has come in for a fair share of
criticism in recent times. The most prominent criticism revolves around the fact that very often,
customers don't really know what they want up-front; rather, what they want emerges out of
repeated two-way interactions over the course of the project. In this situation, the waterfall
model, with its emphasis on up-front requirements capture and design, is seen as somewhat
unrealistic and unsuitable for the vagaries of the real world. Further, given the uncertain nature
of customer needs, estimating time and costs with any degree of accuracy (as the model
suggests) is often extremely difficult. In general, therefore, the model is recommended for use
only in projects which are relatively stable and where customer needs can be clearly identified at
an early stage.

Another criticism revolves around the model's implicit assumption that designs can be feasibly
translated into real products; this sometimes runs into roadblocks when developers actually begin
implementation. Often, designs that look feasible on paper turn out to be expensive or difficult in
practice, requiring a re-design and hence destroying the clear distinctions between phases of the
traditional waterfall model. Some criticisms also center on the fact that the waterfall model
implies a clear division of labor between, say, "designers", "programmers" and "testers"; in
reality, such a division of labor in most software firms is neither realistic nor efficient.

Fountain model

• Based on the waterfall model

• But observes that the sequence always contains cycles

• Reflects the fact that some phases cannot begin before others

• ...and that some phases are poorly delineated

• A mental image to help visualize what actually happens in many real

software development projects
SPIRAL MODEL

The Spiral model is a software development process combining elements of both design and
prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.
Also known as the spiral lifecycle model (or spiral development), it is a systems development
method (SDM) used in information technology (IT). This model of development combines the
features of the prototyping model and the waterfall model. The spiral model is intended for large,
expensive and complicated projects. The spiral model was defined by Barry Boehm.
Pros & Cons of Spiral Model
* High amount of risk analysis
* Good for large and mission-critical projects.
* Software is produced early in the software life cycle.
--
* 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.

Build-and-fix model
In this most simple model of software development, the product is constructed with minimal
requirements, and generally no specifications nor any attempt at design, and testing is most often
neglected. This is a representation of what is happening in many software development projects.
Note that this way of doing is not only a counter-example: it has its benefits in some situations.

Advantages

• Cost efficient for very small projects of limited complexity.

Disadvantages

• Unsatisfying approach for products of reasonable size.

• Cost is higher for larger projects.
• Product will not be delivered on time most of the times.
• Often results in a product of overall low quality.
• No documentation is produced.
• Maintenance can be extremely difficult without specification and design
document.

PROTOTYPE MODEL

Software Prototyping refers to the activity of creating prototypes of software applications,

i.e., incomplete versions of the software program being developed. It is an activity that can occur
in software development and is comparable to prototyping as known from other fields, such as
mechanical engineering or manufacturing.

A prototype typically simulates only a few aspects of the final solution, and may be completely
different from the final product.

Horizontal Prototype

A common term for a user interface prototype is the horizontal prototype. It provides a broad
view of an entire system or subsystem, focusing on user interaction more than low-level system
functionality, such as database access. Horizontal prototypes are useful for:

• Confirmation of user interface requirements and system scope

• Demonstration version of the system to obtain buy-in from the business
• Develop preliminary estimates of development time, cost and effort.

Vertical Prototype

A vertical prototype is a more complete elaboration of a single subsystem or function. It is

useful for obtaining detailed requirements for a given function, with the following benefits:

• Refinement database design

• Obtain information on data volumes and system interface needs, for network
sizing and performance engineering
• Clarifies complex requirements by drilling down to actual system functionality

Throwaway prototyping

• Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the

creation of a model that will eventually be discarded rather than becoming part of the
final delivered software. After preliminary requirements gathering is accomplished, a
 simple working model of the system is constructed to visually show the users what their
requirements may look like when they are implemented into a finished system.

Evolutionary prototyping

• Evolutionary Prototyping (also known as breadboard prototyping) is quite different from

Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build
a very robust prototype in a structured manner and constantly refine it. "The reason for
this is that the Evolutionary prototype, when built, forms the heart of the new system, and
the improvements and further requirements will be built.

Advantages of prototyping

There are many advantages to using prototyping in software development – some tangible, some
abstract.

Reduced time and costs: Prototyping can improve the quality of requirements and specifications
provided to developers. Because changes cost exponentially more to implement as they are
detected later in development, the early determination of what the user really wants can result in
faster and less expensive software.

Improved and increased user involvement: Prototyping requires user involvement and allows
them to see and interact with a prototype allowing them to provide better and more complete
feedback and specifications. The presence of the prototype being examined by the user prevents
many misunderstandings and miscommunications that occur when each side believe the other
understands what they said. Since users know the problem domain better than anyone on the
development team does, increased interaction can result in final product that has greater tangible
and intangible quality. The final product is more likely to satisfy the users desire for look, feel
and performance.

Disadvantages of prototyping

Using, or perhaps misusing, prototyping can also have disadvantages.[11]

Insufficient analysis: The focus on a limited prototype can distract developers from properly
analyzing the complete project. This can lead to overlooking better solutions, preparation of
incomplete specifications or the conversion of limited prototypes into poorly engineered final
projects that are hard to maintain. Further, since a prototype is limited in functionality it may not
scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if
developers are too focused on building a prototype as a model.

User confusion of prototype and finished system: Users can begin to think that a prototype,
intended to be thrown away, is actually a final system that merely needs to be finished or
polished. (They are, for example, often unaware of the effort needed to add error-checking and
security features which a prototype may not have.) This can lead them to expect the prototype to
accurately model the performance of the final system when this is not the intent of the
developers. Users can also become attached to features that were included in a prototype for
consideration and then removed from the specification for a final system. If users are able to
require all proposed features be included in the final system this can lead to conflict.

Developer misunderstanding of user objectives: Developers may assume that users share their
objectives (e.g. to deliver core functionality on time and within budget), without understanding
wider commercial issues. For example, user representatives attending Enterprise software (e.g.
PeopleSoft) events may have seen demonstrations of "transaction auditing" (where changes are
logged and displayed in a difference grid view) without being told that this feature demands
additional coding and often requires more hardware to handle extra database accesses. Users
might believe they can demand auditing on every field, whereas developers might think this is
feature creep because they have made assumptions about the extent of user requirements. If the
developer has committed delivery before the user requirements were reviewed, developers are
between a rock and a hard place, particularly if user management derives some advantage from
their failure to implement requirements.

Developer attachment to prototype: Developers can also become attached to prototypes they
have spent a great deal of effort producing; this can lead to problems like attempting to convert a
limited prototype into a final system when it does not have an appropriate underlying
architecture. (This may suggest that throwaway prototyping, rather than evolutionary
prototyping, should be used.)

Excessive development time of the prototype: A key property to prototyping is the fact that it
is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to
develop a prototype that is too complex. When the prototype is thrown away the precisely
developed requirements that it provides may not yield a sufficient increase in productivity to
make up for the time spent developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and delaying the final product.

Expense of implementing prototyping: the startup costs for building a development team
focused on prototyping may be high. Many companies have development methodologies in
place, and changing them can mean retraining, retooling, or both. Many companies tend to just
jump into the prototyping without bothering to retrain their workers as much as they should.

Rapid prototyping is the automatic construction of physical objects using additive

manufacturing technology. The first techniques for rapid prototyping became
available in the late 1980s and were used to produce models and prototype parts.
Today, they are used for a much wider range of applications and are even used to
manufacture production-quality parts in relatively small numbers. Some sculptors
use the technology to produce complex shapes for fine arts exhibitions. The use of
additive manufacturing for rapid prototyping takes virtual designs from computer
aided design (CAD) or animation modeling software, transforms them into thin,
virtual, horizontal cross-sections and then creates successive layers until the model
is complete. It is a WYSIWYG process where the virtual model and the physical
model are almost identical.
ITERATIVE/INCREMENTAL MODEL

Iterative and Incremental development is at the heart of a cyclic software

development process developed in response to the weaknesses of the waterfall
model. It starts with an initial planning and ends with deployment with the cyclic
interactions in between.

Synchronize-and-stabilize (sometimes just called sync-and-stabilize) is a systems

development life cycle model in which teams work in parallel on individual
application modules, frequently synchronizing their code with that of other teams,
and debugging (stabilizing) code regularly throughout the development process.
The sync-and-stabilize model offers advantages over the older waterfall model,
which is strictly sequential in nature. Because sync-and-stabilize development
allows for changes at any point in the process, it can be flexible, and more easily
able to respond to market requirement changes.