0% found this document useful (0 votes)
29 views46 pages

Unit01 SDP

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)
29 views46 pages

Unit01 SDP

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
You are on page 1/ 46

Introduction to System

development process

1
Learning Objectives
• Systems development life cycle
• Identify the software development phases
• How it came about
• Methodology alternatives
• Team roles & skill sets
• Modern software development process
• Agile methodology with SCRUM framework

2
What is a Software Process?
A process is a method for doing or producing something.
A software process is a method for producing software.
Software products are a set of artifacts derived from a software development
process such as SRS, design specifications, executable file, user manual …

"Producing software" includes Managing the software project


involves
 specification
 obtaining resources
 design
 measuring
 construction
 tracking
 documentation
 reviews
 transition
 analyzing results and acting on
 maintenance
them
 improvement
3
Introduction

• Why do we need a formal process?


• Failures occur (too) often
• Creating systems is not intuitive
• Projects are late, over budget or delivered with fewer
features than planned
• The System Analyst is the key person
• Designs a system to add value
• Must understand the business processes
• Job is rewarding, yet challenging
• Requires specific skill sets

4
Do You Have a Process?

Everyone who develops software uses a process.


• Process may not be formal.
• You may even be aware of it (not "defined").
• It changes every time you develop a new application.

5
Why a Defined Process?
• More Effective
• less time spent on planning, estimates, decisions
• Predictable
• Repeatable (related to predictability)
• Trackable (measuring predictability)
• Maintainability
• Quality
• Capability Improvement
• use what you learn from past experience

6
4 key factors in development speed
1. People
– ability, knowledge, skills, motivation
2. Process
– Customer focus
– QA, risk management, lifecycle planning, revision control, ...
3. Product
– Size and characteristics, phasing
4. Technology
– Product or software development environment
– Tools

7
Systems Development
Life Cycle (SDLC)

As is ,to be system?
Design strategy?

8
The SDLC Process

• The process consists of four phases


• Each phase consists of a series of steps
• Each phase is documented (deliverables)
• Phases are executed sequentially, incrementally,
iteratively or in some other pattern

9
SDLC: The Planning Phase

1. Project Initiation
• Develop a system request
• Conduct a feasibility analysis
• Technical feasibility
• Economic feasibility
• Organizational feasibility
2. Project Management
• Develop the work plan
• Staff the project
• Monitor & control the project

10
SDLC: The Analysis Phase
1. Develop an analysis strategy
• Model the current system (as is system)
• Formulate the new system (to-be system)
2. Gather the requirements
• Develop a system concept
• Create a business model to represent:
• Business data
• Business processes
3. Develop a system proposal

11
SDLC: The Design Phase

1. Develop a design strategy


2. Design architecture and interfaces
3. Develop databases and file specifications
4. Develop the program design

12
SDLC: The Implementation Phase

1. Construct the system (write the


programming code)
2. Test, install, and Train the users
3. maintenance: Support the system

13
Obtained products from the software
development processes
A work product is a general abstraction that represents
something obtained from the software development process.
An artifact is formal work product that is produced, modified,
or used by a task, defines an area of responsibility and is
subject to version control.
A deliverable is a tangible or intangible output of a project
that is delivered to a customer.
CRC,
MOM ER, AD,
Work Products Plan, SRS, Source code,
SD,
PC SAR Exe, manual, …
DPD

14
SDLC: Methodologies
• Methodology: a formalized approach to
implementing the SDLC
• Categories
• Process oriented
• Data centered
• Object-oriented
• Structured
• Rapid action development
• Agile development

15
Classes of Methodologies

• Structured Development
• Waterfall Development
• Parallel Development
• Rapid Application Development
• Phased
• Prototyping
• Agile Development or programming-centric
methodologies
• eXtreme Programming
• SCRUM

16
Waterfall V

Parallel Iterative or Phased 17


18
System Prototyping

Throwaway Prototyping

19
Extreme Programming

20
Which Methodology to Use?

21
The roles and responsibilities

22
The Systems Analyst: Skills
• Agents of change
• Identify ways to improve the as-is system
• Motivate & train others
• Skills needed:
• Technical: must understand the technology
• Business: must know the business processes
• Analytical: must be able to solve problems
• Communications: technical & non-technical audiences
• Interpersonal: leadership & management
• Ethics: deal fairly and protect confidential information

23
Agile practices and frameworks

24
What is Agile

• A set of software best practices strung into an


official set of principles in 2001 as the Agile
Manifesto.
• Principles of Agile:
• Individual and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Respond to change over following a plan

25
Key Aspects of any Agile Methodology

Agile
Methodologies

Iterative Incremental Self-Organizing Emergent

Planned Develop parts of The set of tools,


modification of the system techniques,
The team has the
parts of the separately and development
responsibility of
system. Assists integrate. Assists environment, and
organizing its
with modification with improving requirements
internal dynamics.
of design and overall emerge in the
requirements methodology process

26
Agile :Scrum (Cont.)

• Key Components of Scrum Agile:


• Cross-Functional Teams
• Product Backlog
• Timeboxed Development Iterations
• End of Cycle

• Origins of Scrum
• Japanese OR Advancements
• Incremental Development in the U.S.
• Object Oriented technologies in software

27
Agile :Scrum (cont.)

Ref: https://www.scrumalliance.org/why-scrum

28
Agile :Scrum (cont.)

Ref: https://jnyh.medium.com/applying-agile-methodology-to-data- 29
science-projects-db50ebbef115
Ref: http://www.albalenys.com/posts/16 30
Principles of Agile Documentation

• Generate “just enough” documentation


• Should satisfy the objectives of the use for the
documentation.
• Do not generate if not planning to be used.

• Used to transfer knowledge in the team and between


teams.
• Agile tends to keep knowledge within the team.
• Knowledge transfer is essential for add-on projects

31
Two Approaches to Documentation in
Agile
• Method 1: Adapted Agile
• Use document standards as binding constraints to the
Agile effort.
• Documentation must be generated to support periods of
customer reviews
• Full and complete documentation expected
• Plan a full documentation update with each appropriate
iteration with emphasis on the last iteration to generate
complete deliverable documents.
• Ideal for contracts already in work with waterfall style
program management.

32
Two Approaches to Documentation in Agile

• Method 2: Aligned Agile


• Documentation is generated as needed during the Agile
implementation.
• Customer understanding of the differences in Agile method
is essential.
• Customer must agree to less documentation that is
generated only to meet documentation objectives.
• In-progress reviews and supporting documentation are also
broken down to match better with shorter development
iterations.
• Ideal when terms of documentation can be negotiated with
the customer.
• Suggested for company-wide migration towards the use of
Agile methods.

33
Extreme Programming (XP)

34
What is Extreme Programming (XP)?

• An agile development methodology


• Created by Kent Beck in the mid 1990’s
• A set of 12 key practices taken to their “extremes”
• A mindset for developers and customers

35
The 12 Practices of XP
1. The Planning Game
2. Small Releases
3. Metaphor
4. Simple Design
5. Testing
6. Refactoring
7. Pair Programming
8. Collective Ownership
9. Continuous Integration
10. 40-Hour Workweek
11. On-site Customer
12. Coding Standards

36
Top 5 Extreme Programming (XP) Tools Every
Team Should Use

37
https://blog.pythian.com
Problem with Extreme Programming

38
Key points of XP

• Extreme programming includes practices such as systematic


testing, continuous improvement and customer
involvement.
• Customers are involved in developing requirements
• which are expressed as simple scenarios.
• The approach to testing in XP is a particular strength where
executable tests are developed before the code is written.

39
Extreme Programming (Cont.)

https://www.visual-paradigm.com/scrum/extreme-
40
Pair programming

• In XP, programmers work in pairs, sitting together to develop


code.
• This helps develop common ownership of code and spreads
knowledge across the team.
• It serves as an informal review process as each line of code is
looked at by more than 1 person.
• It encourages refactoring as the whole team can benefit
from this.
• Measurements suggest that development productivity with
pair programming is similar to that of two people working
independently.

41
Problems with XP

• Customer involvement
• This is perhaps the most difficult problem. It may be
difficult or impossible to find a customer who can
represent all stakeholders and who can be taken off
their normal work to become part of the XP team.
For generic products, there is no ‘customer’ - the
marketing team may not be typical of real
customers.

42
Problems with XP
• Architectural design
• The incremental style of development can mean
that inappropriate architectural decisions are made
at an early stage of the process.
• Problems with these may not become clear until
many features have been implemented and
refactoring the architecture is very expensive.
• Test complacency
• It is easy for a team to believe that because it has
many tests, the system is properly tested.
• Because of the automated testing approach, there
is a tendency to develop tests that are easy to
automate rather than tests that are ‘good’ tests.
43
Problem with Extreme Programming (Cont.)

https://www.visual-paradigm.com/scrum/extreme-
44
Try to apply a software development for DS
project 1

3 4 5

Is waterfall methodology appropriate ?

Ref:
45
https://livebook.manning.com/book/i
ntroducing-data-science/chapter-2/6
Conclusion

• Why are Software Processes Important?


• 4 key factors in development speed (P:P:P:T)
• Systems development life cycle (SDLC)
• Work products, Deliverables
• Methodology alternatives
• Waterfall, phased, parallel, V methodology
• Agile: Xtreme programming, SCRUM

46

You might also like