information technology

1. “You’ve got to be very careful if you don’t know where you’re
going, because you might not get there.”
Yogi Berra

2.  The objective of software engineering is to get software with high
quality.
 Process is a framework for the tasks that are required to build
high-quality software.
 A software process is a set of activities and associated results,
which produces a software product. Software engineers carry out
the activities.
Chapter 2 Software Processes 2

3.  The common activities ca be categorized into:
3
• The functionality of the software and constraints on its
operation must be defined.
Software specification
• The software to meet the specification must be produced.
Software development
• The software must be validated to ensure that it does what
the customer wants.
Software validation
• The software must be evolved to meet the changing
requirements of customers.
Software evolution

4.  Plan-driven processes are processes where all of the
process activities are planned in advance and progress
is measured against this plan.
 In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
 In practice, most practical processes include elements
of both plan-driven and agile approaches.
 There are NO right or wrong software processes.
Chapter 2 Software Processes 4

5. A framework that describes the activities performed at each
stage of a software development project.

6. 6

7.  Requirements – defines needed
information, function, behavior,
performance and interfaces.
 Design – data structures,
software architecture, interface
representations, algorithmic
details.
 Implementation – source code,
database, user documentation,
testing.

8.  Test – check if all code modules
work together and if the system
as a whole behaves as per the
specifications.
 Installation – deployment of
system, user-training.
 Maintenance – bug fixes, added
functionality (an on-going
process).

9. Easy to understand,
easy to use
Provides structure to
inexperienced staff
Milestones are well
understood
Sets requirements
stability
Good for management
control (plan, staff,
track)
Works well when quality
is more important than
cost or schedule

10.  All requirements must be known upfront
 Deliverables created for each phase are considered frozen –
inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the system (until
it may be too late)

11.  Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.

12.  A variant of the Waterfall that
emphasizes the verification
and validation of the product.
 Testing of the product is
planned in parallel with a
corresponding phase of
development

13.  Project and Requirements Planning
– allocate resources
 Product Requirements and
Specification Analysis – complete
specification of the software system
 Architecture or High-Level Design –
defines how software functions
fulfill the design
 Detailed Design – develop
algorithms for each architectural
component
 Production, operation and
maintenance – provide for
enhancement and corrections
 System and acceptance testing –
check the entire software system in
its environment
 Integration and Testing – check that
modules interconnect correctly
 Unit testing – check that each
module acts as expected
 Coding – transform algorithms into
software

14.  Emphasize planning for verification and validation of the
product in early stages of product development
 Each deliverable must be testable
 Project management can track progress by milestones
 Easy to use

15.  Does not easily handle concurrent events
 Does not handle iterations or phases
 Does not easily handle dynamic changes in
requirements
 Does not contain risk analysis activities

16.  Excellent choice for systems requiring high
reliability – hospital patient control
applications
 All requirements are known up-front
 When it can be modified to handle changing
requirements beyond analysis phase
 Solution and technology are known

17. Two ways:
 System prototyping
 Incremental delivery
Chapter 2 Software Processes 17

18.  What is software Prototyping?
◦ Prototype is working model of software with
some limited functionality.
 Stepwise approach to develop software
prototype
◦ Basic Requirement identification
◦ Developing the initial prototype
◦ Review of the prototype
◦ Revise and enhance the prototype

19. Throwaway
Rapid
Prototyping
Evolutionary
Prototype

20.  Objective - Derive end system requirements
Throw away prototyping is one type of approach
where an initial prototype is built mainly focusing
on the poorly understood requirements.
• Once the requirements are understood, prototype is
discarded. Requirements document is updated.
• Actual system is developed (i.e. a conventional
development process) with clear understanding of
requirements.

21.  Used to reduce requirements risk.
 Initial prototype is developed from outline
requirements, delivered for experiment,
and modified until risk is acceptably low.
 Examples of throwaway prototypes
include screen mock-ups and story boards.

22.  Developers may be pressurized to deliver a
throw-away prototype as the final system.
 This is problematic...
 It may be impossible to meet non-functional
requirements.
 The prototype is almost certainly undocumented.
 The system may be poorly structured and therefore
difficult to maintain.
 Normal quality standards may not have been applied.

23. Air Tank
Developer
User Mgmt
No, no, no! I
won’t deliver the
prototype to you!
Pressurizing the
Developer

24.  Developers build a prototype during the requirements phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype code is brought up to the
standards needed for a final product.

25.  A preliminary project plan is developed
 An partial high-level paper model is created
 A prototype is built with basic and critical attributes
 The designer builds
 the database
 user interface
 algorithmic functions
 The designer
demonstrates the
prototype, the user
evaluates for problems
and suggests
improvements.
 This loop continues
until the user is
satisfied

26. Customers can “see” the system requirements as
they are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates awareness
of additional needed functionality

27.  Tendency to discard structured program
development for “code-and-fix”
development
 Bad reputation for “quick-and-dirty”
methods
 Overall maintainability may be
overlooked
 Process may continue forever (scope
creep)

28. Requirements
are unstable or
have to be
clarified
Develop user
interfaces
Short-lived
demonstrations
New, original
development

29.  The system is developed as a series of versions (increments), with
each version adding functionality to the previous version.
 In Incremental Model, Project requirements are divided into
multiple modules and each module is developed separately.
 Finally developed modules are integrated with other modules.
 During development of each module, waterfall model is followed
for each module development separately.
 Each developed module in Incremental Model is standalone
feature and could be delivered to the end users to use it.

30. Chapter 2 Software Processes 30

31. Chapter 2 Software Processes 31

32.  Develop high-risk or major functions first
 Each release delivers an operational product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced

33.  Requires good planning and design
 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not
lower

34.  Risk, funding, schedule, program complexity, or need for
early realization of benefits.
 Most of the requirements are known up-front but are
expected to evolve over time
 A need to get basic functionality to the market early
 On projects which have lengthy development schedules
 On a project with new technology

35.  The CBD Solution
 Systems should be assembled from existing
components.
Chapter 2 Software Processes 35

36.  A software component is a program module
that can be used independently, or can operate
in conjunction with other components.
 Components should be executable to allow
independence.
Chapter 2 Software Processes 36

37. What is CBSE?
 Component-based software engineering is
the idea of building software from
established software components, as
opposed to building the software from the
ground up.
Chapter 2 Software Processes 37

38.  Based on systematic reuse where systems are
integrated from existing components or
COTS (Commercial-off-the-shelf) systems.
 Reuse is now the standard approach for
building many types of business system
Chapter 2 Software Processes 38

39.  Advantages:
reducing cost and risk.
faster delivery of software
 Disadvantages:
Requirement compromises
Chapter 2 Software Processes 39

40.  Similar to the incremental model, with more emphasis placed
on risk analysis.
 Process is represented as a spiral, rather than as a sequence of
activities.
 Software project repeatedly passes through these phases in
iterations.
 Risks are explicitly assessed and resolved throughout the
process.
 Incremental releases of the product, or incremental refinement
through each iteration around the spiral.
Spiral model is an evolutionary software
process model which is a combination of an
iterative nature of prototyping and systematic
aspects of traditional waterfall model.

41. Development cycles through multiple (3-6) task regions

42. Figure 2.13

43. •The objectives, alternatives and constraints of the project are determined and are
documented.
Planning Phase
•All possible alternatives, which can help in developing a cost effective project are analyzed
•This phase identify and resolve all the possible risks in the project development.
Risk assessment and reduction
•The actual development of the project is carried out.
•The output of this phase is passed through all the phases iteratively in order to obtain
improvements in the same.
Development and validation
•Developed product is passed on to the customer in order to receive customer’s comments and
suggestions.
•This phase is very much similar to TESTING phase.
•And the next phase of the spiral is planned.
Customer Evaluation (Planning)

44.  Provides early indication of unsolvable
risks, without much cost
 Users see the system early because of
rapid prototyping tools
 Critical high-risk functions are
developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle
steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently

46.  When creation of a prototype is appropriate
 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)

47.  Speed up or bypass one or more life cycle
phases
 Usually less formal and reduced scope
 Used for time-critical applications
 Used in organizations that employ disciplined
methods

48. Agile software development is a group of
software development methodologies based on
iterative and incremental development, where
requirements and solutions evolve through
collaboration between self-organizing, cross-
functional teams.
48

49. 49