W8: SOFTWARE PROCESS

HCI IN THE
S FTWAR
PR CESS
SOFTWARE
Software is a collection of instructions
and data that tell the computer how to
work. This is in contrast to physical
hardware, from which the system is
built and actually performs the work.
 Software
Software engineering provides a
means of understanding the
structure of the design process,
and that processed can be
assessed for its effectiveness in

engineering
interactive system design. One
of the cornerstones of software
engineering is the software life
cycle
 Software Development Life Cycle (SDLC) is

Software
a process used by the software industry to
design, develop and test high quality
software.

The SDLC aims to produce a high-quality

software that meets or exceeds customer

life cycle
expectations, reaches completion within
times and cost estimates.
• SDLC is the acronym of Software Development
Life Cycle.
• It is also called as Software Development
Process.
• SDLC is a framework defining tasks performed
at each step in the software development
process.
Activities in the Software Life Cycle

REQUIREMENT ANALYSIS The Waterfall Model was the first Process

Model to be introduced. It is also referred
to as a linear-sequential life cycle model.
SYSTEM DESIGN
It is very simple to understand and use. In a
IMPLEMENTATION waterfall model, each phase must be
completed before the next phase can begin
and there is no overlapping in the phases.
TESTING

DEPLOYMENT

MAINTENANCE

Waterfall model Software Life Cycle

“SDLC - Waterfall Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm.
 Requirement Analysis Implementation
All possible requirements of the system to With inputs from the system design, the system
be developed are captured in this phase is first developed in small programs called units,
and documented in a requirement which are integrated in the next phase. Each unit
is developed and tested for its functionality,
specification document.
which is referred to as Unit Testing.

System Design Integration and Testing

The requirement specifications from first All the units developed in the
phase are studied in this phase and the implementation phase are integrated into a
system design is prepared. This system system after testing of each unit. Post
design helps in specifying hardware and integration the entire system is tested for
system requirements and helps in defining any faults and failures.
the overall system architecture.

Software Life Cycle: Waterfall model

“SDLC - Waterfall Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm.
 Deployment of system Maintenance
Once the functional and non-functional There are some issues which come up in the
testing is done; the product is deployed in client environment. To fix those issues, patches
the customer environment or released into are released. Also to enhance the product some
better versions are released. Maintenance is
the market. done to deliver these changes in the customer
environment.

NOTE!
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In
this model, phases do not overlap.

Software Life Cycle: Waterfall model

“SDLC - Waterfall Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm.
 Waterfall Model -Application
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model
is most appropriate are −

• Requirements are very well documented, clear and fixed.

• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.

Software Life Cycle: Waterfall model

“SDLC - Waterfall Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm.
 Advantages disadvantages
• Simple and easy to understand and use • No working software is produced until late during
• Easy to manage due to the rigidity of the life cycle.
the model. Each phase has specific • High amounts of risk and uncertainty.
• Not a good model for complex and object-
deliverables and a review process.
oriented projects.
• Phases are processed and completed • Poor model for long and ongoing projects.
one at a time. • Not suitable for the projects where requirements
• Works well for smaller projects where are at a moderate to high risk of changing. So, risk
requirements are very well understood. and uncertainty is high with this process model.
• Clearly defined stages. • It is difficult to measure progress within stages.
• Well understood milestones. • Cannot accommodate changing requirements.
• Easy to arrange tasks. • Adjusting scope during the life cycle can end a
project.
• Process and results are well
• Integration is done as a "big-bang. at the very end,
documented. which doesn't allow identifying any technological
or business bottleneck or challenges early.

Software Life Cycle: Waterfall model

“SDLC - Waterfall Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm.
 Prototype is a working model of software

Software
with some limited functionality. The
prototype does not always hold the exact
logic used in the actual software application
and is an extra effort to be considered
under effort estimation.

Prototyping is used to allow the users

Prototyping
evaluate developer proposals and try them
out before implementation. It also helps
understand the requirements which are
user specific and may not have been
considered by the developer during
product design.

Software Life Cycle : Prototyping

“SDLC - Software Prototype Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm.
 Throwaway/Rapid PRELIMINARY REQUIREMENTS

Prototyping BUILD PROTOTYPE

Throwaway prototyping is also called as

rapid or close ended prototyping. This type EVALUATE PROTOTYPE
of prototyping uses very little efforts with
minimum requirement analysis to build a
prototype. NO YES
ACCEPTABLE
Once the actual requirements are
understood, the prototype is discarded and
the actual system is developed with a much
FINAL REQUIREMENTS
clear understanding of user requirements.

Software Life Cycle : Prototyping

“SDLC - Software Prototype Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm.
 Evolutionary
Prototyping DESIGNING COMPONENTS

Here the prototype is not discarded and BUILD PROTOTYPE

serves as the basis for the next iteration of
design. In this case, the actual system is
seen as evolving from a very limited initial EVALUATE PROTOTYPE
version to its final release.

Evolutionary prototyping also fits in well

with the modifications which must be made OPERATION & MAINTENANCE
to the system that arise during the
operation and maintenance activity in the
life cycle.

Software Life Cycle : Prototyping

“SDLC - Software Prototype Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm.
 Prototyping -Application
Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems. Systems which need users to fill out forms or go through
various screens before data is processed can use prototyping very effectively to give the
exact look and feel even before the actual software is developed.

Software that involves too much of data processing and most of the functionality is internal
with very little user interface does not usually benefit from prototyping. Prototype
development could be an extra overhead in such projects and may need lot of extra efforts.

Software Life Cycle : Prototyping

“SDLC - Software Prototype Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm.
 Advantages disadvantages
• Increased user involvement in the product • Risk of insufficient requirement analysis owing to
even before its implementation. too much dependency on the prototype.
• Since a working model of the system is • Users may get confused in the prototypes and
displayed, the users get a better actual systems.
understanding of the system being • Practically, this methodology may increase the
developed. complexity of the system as scope of the system
• Reduces time and cost as the defects can be may expand beyond original plans.
detected much earlier. • Developers may try to reuse the existing
• Quicker user feedback is available leading to prototypes to build the actual system, even when
better solutions. it is not technically feasible.
• Missing functionality can be identified easily. • The effort invested in building prototypes may be
• Confusing or difficult functions can be too much if it is not monitored properly.
identified.

Software Life Cycle : Prototyping

“SDLC - Software Prototype Model.” Tutorialspoint, www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm.
 There are many definitions of Design Rationale:

• "Design rationale expresses elements of the

reasoning which has been invested behind the design

Design
of an artifact" [Shum & Hammond, 1993].

• "Design rationale is the reasoning and argument that

leads to the final decision of how the design intent is
achieved." "Design intent is the `expected’ effect or
behavior that the designer intended the design
object should achieve to fulfil the required function."
[Sim & Duffy, 1994]

rationale
• "Design rationale means statements of reasoning
underlying the design process that explain, derive,
and justify design decisions" [Fischer, et. a., 1995]

• Design rationale means "information that explains

why an artifact is structured the way that it is and has
the behavior that it has"
Is the information that explains why a computer system is the way it is [Conklin, Burgess-Yakemovic, 1995].

• "Design rationales include not only the reasons

behind a design decision but also the justification for
it, the other alternatives considered, the tradeoffs
evaluated, and the argumentation that led to the
decision" [Lee, 1997].
Design rationale -Application
• Design verification • Design teaching
• — The design rationale can be used to verify if the • — The design rationale could be used as a resource to
design decisions and the product itself are the teach people who are unfamiliar with the design and
reflection of what the designers and the users actually the system.
wanted.
• Design communication
• Design evaluation • — The design rationale facilitates better communication
• — The design rationale is used to evaluate the various among people who are involved in the design process
design alternatives discussed during the design process. and thus helps to come up with a better design.

• Design maintenance • Design assistance

• — The design rationale helps to determine the changes • — The design rationale could be used to verify the
that are necessary to modify the design. design decisions made during the design process.

• Design reuse • Design documentation

• — The design rationale is used to determine how the • — The design rationale is used to document the entire
existing design could be reused for a new requirement design process which involves the meeting room
with or without any changes in it. If there is a need to deliberations, alternatives discussed, reasons behind
modify the design, then the DR also suggests what the design decisions and the product overview.
needs to be modified in the design.