0% found this document useful (0 votes)
2 views38 pages

BIE Week 13 - SoftwareDevelopmentProcess

The document outlines the software development process, focusing on the Software Development Life Cycle (SDLC) and methodologies such as Waterfall and Agile. It details the phases of SDLC, the importance of requirement analysis, and the distinction between functional and non-functional requirements. Additionally, it discusses techniques for gathering requirements and their respective advantages and disadvantages.

Uploaded by

ariavalo124
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views38 pages

BIE Week 13 - SoftwareDevelopmentProcess

The document outlines the software development process, focusing on the Software Development Life Cycle (SDLC) and methodologies such as Waterfall and Agile. It details the phases of SDLC, the importance of requirement analysis, and the distinction between functional and non-functional requirements. Additionally, it discusses techniques for gathering requirements and their respective advantages and disadvantages.

Uploaded by

ariavalo124
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

SOFTWARE DEVELOPMENT

PROCESS

Business Innovation & Enterprise


IT1112/IT1212/IT1512/IT1812/IT1912
AY2026 Semester 1
LEARNING OUTCOMES

◎ Describe software development life cycle and key activities in a software


development lifecycle
◎ Examine different software development methodologies
• Waterfall
• Agile
◎ List the properties of requirements
◎ Explain the need of requirement analysis in software development
◎ Describe the key activities in requirement development process
◎ To identify and differentiate functional and non-functional requirements for
a system
◎ To describe different techniques for requirement gathering including their
advantages and disadvantages
2
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
◎ A systematic process aims to produce a high-quality software that
meets or exceeds customer expectations, reaches completion within
times and cost estimates.

◎ SDLC is a framework defining tasks performed at each step in the


software development process.

◎ It is also called as Software Development Process.

3
PHASES IN A TYPICAL SDLC
SDLC Phase Objective

Planning To identify the scope of the new system, ensure that the project is feasible and develop a schedule,
resource plan and budget for the remainder of the project
Analysis To understand and document in detail the business needs and the processing requirements of the new
system
Design To design the solution system based on the requirements defined and decisions made during analysis

Implementation To build a software solution according to business needs

Testing To ensure the developed system has certain inherent qualities, with verification as a means to check its
adequacy with respect to the specified requirements and validation as a means to check that the
solution does address the problem.
Deployment To make the developed software solution available in its context of operation and use.

Maintenance To ensure the deployed solution continues to address the problem throughout the time it is in operation,
and handles its decommissioning at the end of the life-cycle

4
WHAT IS SOFTWARE DEVELOPMENT METHODOLOGY?
◎ Includes the pre-definition of specific deliverables and artifacts that
are created and completed by a project team to develop or
maintain an application / software
◎ Examples of software development methodologies
• Waterfall
• Agile

5
SOFTWARE DEVELOPMENT
METHODOLOGIES

6
WATERFALL MODEL
◎ A highly structured SDLC process that relies heavily on up-front planning
and a set of sequential and prescribed steps like a waterfall

◎ A linear process mode, in which the outcome of one phase acts as the input
for the next phase sequentially.

◎ When to use:
 Requirements are clear and fixed
 Technology is understood and is not dynamic
 The project is short

7
BENEFITS & DRAWBACKS OF WATERFALL MODEL
Benefits Drawbacks
Simple and easy to understand and use No working software is produced until late
during the life cycle
Easy to manage. Each phase has specific High amounts of risk and uncertainty
deliverables and a review process
Works well for smaller projects where Cannot accommodate changing requirements
requirements are very well understood
Process and results are well documented Integration is done as a "big-bang” at the very
end, which doesn't allow identifying any
technological or business bottleneck or
challenges early

8
AGILE SOFTWARE DEVELOPMENT
◎ A lightweight software engineering framework that promotes iterative
development throughout the life-cycle of the project, close collaboration
between the development team and business side.
◎ Agile Software Development is an umbrella term for a set of methods and
practices based on the values and principles expressed in the Agile
Manifesto
◎ produces solutions through evolution and collaboration between self-
organizing, cross-functional teams by utilizing the appropriate practices.
E.g. Scrum
◎ When to use:
 project with frequently changing requirements

9
AGILE MANIFESTO

◎ In a nutshell, the Agile Manifesto reads as follows:


◎ We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right,


we value the items on the left more.

10
AGILE SOFTWARE DEVELOPMENT LIFE CYCLE

11
PLANNED (SDLC) VS. AGILE
ONE-OFF ACTIVITIES VS CONTINUOUS ACTIVITIES

12
PROS AND CONS OF AGILE DEVELOPMENT
Benefits Drawbacks

The customers continuously get a look and feel of the project Depends heavily on customer interaction, so if customer is not clear,
progress at the end of each iteration/sprint. team can be driven in the wrong direction

Each sprint provides the customer with a working software Total cost may be higher than Waterfall
which meets their expectations as per the definition of done
provided by them.
The development teams are quite responsive to the Transfer of technology to new team members may be quite
changing requirements and can accommodate changes even challenging due to lack of documentation
in the advanced stages of development.

There is constant two-way communication which keeps the


customers involved, thus all stakeholders – business and
technical – have clear visibility on the project’s progress.

The design of the product is efficient and fulfills the business


requirements.
13
AGILE MANIFESTO PRINCIPLES (1)
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. Agile processes harness
change for the customer's competitive advantage.
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.

14
AGILE MANIFESTO PRINCIPLES (2)

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 behaviour accordingly.

12 principles behind the Agile Manifesto ([Link]

15
AGILE METHODOLOGIES

◎ Practices based upon the Manifesto for Agile Software Development are
called Agile practices.
◎ Methodologies consisting of Agile practices are called Agile
methodologies.
◎ Several Agile methodologies in practice across the world
 Scrum
 Kanban
 Lean
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Dynamic Software Development Method (DSDM)

16
REQUIREMENT ANALYSIS

17
IMPORTANCE OF REQUIREMENT ANALYSIS IN SOFTWARE
DEVELOPMENT
◎ Right Product
◎ Meeting the needs of your clients and end-users and not just their wants
◎ Involves understanding the problem they need to solve, and the tasks they need to
accomplish with the software.
◎ Done Right & Manage Right
◎ Software development must start with a quality set of software requirements, which are
later planned, designed, implemented, and tested.

18
WHAT IS REQUIREMENT?

◎ A software capability needed by the user to solve a problem or to achieve


an objective
◎ All stakeholders in a project - developers, end users, software managers,
customer managers - must achieve a common understanding of what the
product will be and do.
◎ Need ways to accurately capture, interpret, and represent the voice of
customers when specifying the requirements for a software product
◎ Requirements activities linked to other development activities: design,
implementation, and testing

19
ACTIVITIES IN REQUIREMENT ANALYSIS
Requirements analysis is critical to the success or failure of a systems or software
project. Requirements analysis includes four types of activity:
◎ Eliciting Requirements: the task of communicating with customers and users to
determine what their requirements are. This is sometimes also called requirements
gathering.
◎ Analysing Requirements: determining whether the stated requirements are unclear,
incomplete, ambiguous, or contradictory, and then resolving these issues.
◎ Requirements Modelling: Requirements might be documented in various forms, such as
natural-language documents, use cases, user stories, or process specifications.
◎ Review and Retrospective: Team members reflect on what happened in the iteration
and identifies actions for improvement going forward.

20
TYPES OF REQUIREMENTS

◎ Functional Requirements
• Capabilities/features that the
system MUST HAVE
• E.g.: An application that can
support placing of orders by users

◎ Non-functional Requirements
• Constraints that the new system
MUST MEET
• E.g.: Saving of orders must be
completed in less than 5 seconds.

21
PROPERTIES OF A REQUIREMENT
◎ Unambiguous
• Documentation must be clear.
• Need to understand what you have written and others can understand it too.

◎ Consistent
◎ Comprehensive/Exhaustive
• Steps must be clear and precise

◎ Prioritised
• Be realistic of what can you do with the given timeline.
• Prioritized to do the more important features first and implement in a way that achieves the
best outcome.

◎ Verifiable
• Documentation must be verifiable how the features that are developed that satisfy the
requirements.
22
ACTIVITIES IN REQUIREMENT
ANALYSIS

23
ACTIVITY 1 - GATHER DETAILED INFORMATION

◎ Talk to users of new system or similar systems


◎ Read documentation on existing system
◎ Develop expertise in business area of the system
◎ Collect technical information
• Understand computer usage, work locations, system interfaces with other systems
and software packages

24
ACTIVITY 2 - IDENTIFY FUNCTIONAL REQUIREMENTS
Functional Requirement:
◎ System requirement that describes what the system MUST perform
◎ Typically, it is needed to support business processes
◎ Example: ATM functional requirements
• ATM system shall validate the inserted ATM card
• ATM system shall dispense money
• ATM system shall alert staff when cash holding is below limit

The above functions are needed to support the banking services offered by a
bank.
25
ACTIVITY 3 - IDENTIFY NON-FUNCTIONAL REQUIREMENTS
Non-functional requirements
◎ Constraints or characteristics expected from the system.
◎ Example:
◎ The system is to be developed using Python programming language.

◎ The system is required to support concurrently 1000 users.

◎ Typically include the following areas:

26
ACTIVITY 4 - DEFINE NON-FUNCTIONAL REQUIREMENTS
Examples:
◎ ATM system shall be written in C++ language
• A constraint placed for the development work (i.e.: development constraint)

◎ ATM system shall communicate with bank using 256bit encryption


• A constraint placed on the security of the proposed system (i.e. system performance)

◎ ATM system shall validate the PIN number in 5 seconds.


• A characteristic on the performance of the system (i.e. system performance)

27
ACTIVITY 5 - PRIORITISE REQUIREMENTS

◎ Manage users requests according to user needs, urgency, complexity,


estimated efforts needed.
◎ Balance between limitation of resources vs. user needs
◎ Scope creep (A challenge when managing requirements)
 is the tendency of function list to grow in an uncontrolled manner
 this can adversely impact project progress:
 Leads to cost overruns
 May also cause implementation delays [slippage]

28
ACTIVITY 6 – EVALUATE REQUIREMENTS
◎ Evaluate requirements with user till an acceptable requirement model is developed

◎ Evaluate all possibilities ( scenarios ) in the design and implementation of system

◎ Validate the accuracy and correctness of requirements (“Are we building the right
product ?” )

◎ Process is iterative
 Alternative models developed and continually revised

29
TECHNIQUES OF REQUIREMENT
GATHERING

30
TECHNIQUES FOR REQUIREMENT GATHERING
◎ Questioning, Observing, Researching, Modelling
◎ Good questions initiate process
◎ Questions center around three themes
 What are business processes?
 How is the business process performed?
 What information is required?

31
TECHNIQUES FOR REQUIREMENT GATHERING - INTERVIEW USERS
AND OTHER STAKEHOLDERS

• Most widely used fact-finding


technique

• Types of Questions: Mixture of


Open and Close-ended questions

ITB811 Busines Needs Analysis

32
TECHNIQUES FOR REQUIREMENT GATHERING - DISTRIBUTE &
COLLECT QUESTIONNAIRES

Typically include:
•Close-ended questions (provide a
direct response to the question)

•Opinions questions (respondents


are asked whether they agree or
disagree with the statement)

•Explanation of procedure or
ITB811 Busines Needs Analysis problem

33
TECHNIQUES FOR REQUIREMENT GATHERING - REVIEW INPUTS,
OUTPUTS, AND DOCUMENTATION
2 sources of information

• External to the organisation


• Industry journals and
magazines report the findings
of "best practices" studies

• Existing business documents and


procedure descriptions within the
organisation
ITB811 Busines Needs Analysis
• Gets preliminary
understanding of the processes
• Serves as visual aids

34
TECHNIQUES FOR REQUIREMENT GATHERING - OBSERVE AND
DOCUMENT BUSINESS PROCESSES

• Diagram all information


gathered into workflows
• create activity diagrams
(Identify activities,
relationships between
activities, personnel
responsible for the
activities)
ITB811 Busines Needs Analysis

35
TECHNIQUES FOR REQUIREMENT GATHERING - BUILDING
EFFECTIVE PROTOTYPES
• It is an initial, look alike model with
limited features of a real-
production system

• Discovery prototype
• model created to verify
concept and discarded

• Evolving prototype
• working model that grows and
may become part of system
ITB811 Busines Needs Analysis
• Mock-up
• example of final product for
viewing only, not executable

36
TECHNIQUES FOR REQUIREMENT GATHERING - RESEARCH
VENDOR SOLUTION

ITB811 Busines Needs Analysis

37
SUMMARY
◎ SDLC: set of activities required to complete system development project
◎ Waterfall - A highly structured design process that relies heavily on up-front
planning and a set of sequential and prescribed steps.

◎ Agile Software Development - an approach where requirements and solutions


evolve through collaboration between self-organizing, cross-functional teams.
Scrum is one of the methods.
◎ Properties of Requirements
◎ Activities in the Requirements Discipline:
◎ Functional & non-functional requirements
◎ Techniques for gathering requirements and their pros & cons

38

You might also like