METHODOLOGIES

FOR SYSTEMS ANALYSIS

QUESTIONS TO CONSIDER

What are the various approaches to developing Information Systems?

​

Is there one best way?

​

What is the difference between techniques, methodologies and tools?

​

What does the popular term “SDLC” actually mean?

​

SDLC

SDLC stands for

• Systems
• Development
• Life
• Cycle

​

What does it mean?

SDLC: SYSTEMS DEVELOPMENT LIFE CYCLE �

• SDLC is a Life Cycle

​

• All systems have a life cycle or a series of stages they naturally undergo. 
• The number and name of the stages varies, but the primary stages are conception, development, maturity and decline.

​

• The systems development life cycle (SDLC) therefore, refers to the development stage of the system’s life cycle.

​

A Life Cycle

​

METHODOLOGIES

​

• Is there a difference between the term SDLC and the term ‘methodology’?

​

• SDLC: refers to a stage all systems naturally undergo,

​

• A Methodology refers to an approach invented by humans to manage the events naturally occurring in the SDLC. 

METHODOLOGIES

​

A methodology is, a set of steps, guidelines, activities and/or principles to follow in a particular situation.

​

• Most methodologies are comprehensive, multi-step approaches to systems development

​

• There are many (thousands!) methodologies available. See www.methodology.org .

​

SDLC VS. METHODOLOGY

​

The term SDLC is frequently used synonymously

with the waterfall or traditional approach for

developing information systems.

​

WRONG !!!

“THE WATERFALL APPROACH”�

• This approach essentially refers to a linear sequence of stages to develop a system from planning to analysis to design to implementation. 

​

• Stages are followed from beginning to end. 

​

​

• Revisiting prior stages is not permitted. 

​

WATERFALL MODEL

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.

WATERFALL STRENGTHS

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

​

​

​

​

WATERFALL DEFICIENCIES

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)

​

WHEN TO USE THE WATERFALL MODEL

• 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.

​

• High risk for new systems because of specification and �design problems.
• Low risk for well-understood developments using familiar technology.

​

Why doesn’t Waterfall work?

To find out, let’s�read a passage from�Schwaber and Beedle (2001*)

*Agile Software Development with Scrum

Why Waterfall doesn’t work

False assumption:�Specifications predictable and stable,�and can be correctly defined at the start,�with low change rates

25% change in

requirements

35% to 50% change�for large projects

Waterfall is a “defined” process control model

http://flic.kr/p/9xmccb

(think mass manufacturing)

http://flic.kr/p/4Xt7Xe

Software development needs an “empirical” model

(think new product development)

Prototyping Model

​

A type of development in which emphasis is placed on developing prototypes early in the development process to permit early feedback and analysis in support of the development process.”

​

Need for prototyping

​

• As a requirements artifact to initially envision the system.
• As a design artifact that enables us to explore the solution space of your system.
• A vehicle for you to communicate the possible UI design(s) of your system.
• A potential foundation from which to continue developing the system

​

RAPID PROTOTYPING MODEL

• Prototyping is defined as the process of developing a working replication of a product or system that has to be engineered.
• It offers a small scale replica of the end product and is used for obtaining customer feedback as described below:

WHAT IS A PROTOTYPE?

​

​

In interaction design it can be (among other things):

​

• a series of screen sketches

​

• a storyboard, i.e. a cartoon-like series of scenes

​

• a Powerpoint slide show

​

• a video simulating the use of a system

​

• a lump of wood (e.g. PalmPilot)

​

• a cardboard mock-up

​

• a piece of software with limited functionality written in the target language or in another language

​

​

21

SYSTEM PROTOTYPING

• Prototyping is the rapid development of a system
• In the past, the developed system was normally thought of as inferior in some way to the required system so further development was required
• Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach

USES OF SYSTEM PROTOTYPES

• The principal use is to help customers and developers understand the requirements for the system
• Requirements elicitation. Users can experiment with a prototype to see how the system supports their work
• Requirements validation. The prototype can reveal errors and omissions in the requirements
• Prototyping can be considered as a risk reduction activity which reduces requirements risks

PROTOTYPING BENEFITS

• Misunderstandings between software users and developers are exposed
• Missing services may be detected and confusing services may be identified
• A working system is available early in the process
• The prototype may serve as a basis for deriving a system specification
• The system can support user training and system testing

PROTOTYPING BENEFITS

• Improved system usability
• Closer match to the system needed
• Improved design quality
• Improved maintainability
• Reduced overall development effort

PROTOTYPING IN THE SOFTWARE PROCESS

• Evolutionary prototyping
• An approach to system development where an initial prototype is produced and refined through a number of stages to the final system
• Throw-away prototyping
• A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process

PROTOTYPING OBJECTIVES

• The objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood.
• The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood

APPROACHES TO PROTOTYPING

EVOLUTIONARY PROTOTYPING

• Must be used for systems where the specification cannot be developed in advance e.g. AI systems and user interface systems
• Based on techniques which allow rapid system iterations
• Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system

EVOLUTIONARY PROTOTYPING

EVOLUTIONARY PROTOTYPING ADVANTAGES

• Accelerated delivery of the system
• Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability
• User engagement with the system
• Not only is the system more likely to meet user requirements, they are more likely to commit to the use of the system

EVOLUTIONARY PROTOTYPING

• Specification, design and implementation are inter-twined
• The system is developed as a series of increments that are delivered to the customer
• Techniques for rapid system development are used such as CASE tools and 4GLs
• User interfaces are usually developed using a GUI development toolkit

EVOLUTIONARY PROTOTYPING PROBLEMS

• Management problems
• Existing management processes assume a waterfall model of development
• Specialist skills are required which may not be available in all development teams
• Maintenance problems
• Continual change tends to corrupt system structure so long-term maintenance is expensive
• Contractual problems

PROTOTYPES AS SPECIFICATIONS

• Some parts of the requirements (e.g. safety-critical functions) may be impossible to prototype and so don’t appear in the specification
• An implementation has no legal standing as a contract
• Non-functional requirements cannot be adequately tested in a system prototype

INCREMENTAL DEVELOPMENT

• System is developed and delivered in increments after establishing an overall architecture
• Requirements and specifications for each increment may be developed
• Users may experiment with delivered increments while others are being developed. therefore, these serve as a form of prototype system
• Intended to combine some of the advantages of prototyping but with a more manageable process and better system structure

INCREMENTAL DEVELOPMENT PROCESS

THROW-AWAY PROTOTYPING

• Used to reduce requirements risk
• The prototype is developed from an initial specification, delivered for experiment then discarded
• The throw-away prototype should NOT be considered as a final system
• Some system characteristics may have been left out
• There is no specification for long-term maintenance
• The system will be poorly structured and difficult to maintain

THROW-AWAY PROTOTYPING

PROTOTYPE DELIVERY

• Developers may be pressurised to deliver a throw-away prototype as a final system
• This is not recommended
• It may be impossible to tune the prototype to meet non-functional requirements
• The prototype is inevitably undocumented
• The system structure will be degraded through changes made during development
• Normal organisational quality standards may not have been applied

RAPID PROTOTYPING MODEL (CONTD.)

• Rapid prototype characteristics:
• Used in the requirements phase
• Evaluated by the customer/user
• Then, it is discarded -do not turn into product
• Rapid prototyping model is not proven and has its own problems
• Possible solution
• Rapid prototyping for defining requirements
• Waterfall model for rest of life cycle

​

SPIRAL MODEL

• Combining elements of design and prototyping-in-stages
• Combines the features of the prototyping and the waterfall model
• The spiral model is intended for large, expensive and complicated projects

SPIRAL DEVELOPMENT

• Combination of waterfall methodology and prototyping methodologies
• Combination of the top-down and bottom up concepts

​

• Primary focus is on risk assessment
• Break the project into smaller segments
• Controls the impact of change

​

​

43

SPIRAL MODEL (BOEHM)

Barry Boehm, USC

44

ANOTHER VIEW OF THE SPIRAL

45

SPIRAL DETAILS

• breaks up the project into mini-projects based on risk
• purpose: risk reduction
• example: in first phase,
• great when charting new territories (with high risks)

​

• steps taken at each loop of the spiral (roughly):
• determine objectives, options, constraints
• identify risks
• evaluate options to resolve the risks
• develop and verify any deliverable items
• plan the next phase
• commit to approach for next phase

​

46

SPIRAL BENEFITS

• benefits of spiral
• provides early indication of unforeseen problems
• as costs increase, risks decrease
• always addresses the biggest risk first
• focuses attention on reuse
• accommodates changes, growth
• eliminates errors and unattractive choices early
• limits to how much is enough (not too much design, reqs, etc)
• treats development, maintenance same way

​

47

SPIRAL PROBLEMS

• What are some drawbacks to the spiral model?

- complicated

- relies on developers to have risk-assessment expertise

- possibly more management overhead to assess risk

- need for more elaboration of project steps �(clearer milestones)

- matching to contract software�(doesn't work well when you're bound to a fixed inflexible contract)

WHEN TO USE SPIRAL MODEL

• As mentioned before, the spiral model is best used in large, expensive and complicated projects. Other uses include:
• projects in which frequent releases are necessary;
• projects in which changes may be required at any time;
• long term projects that are not feasible due to altered economic priorities;
• medium to high risk projects;
• projects in which cost and risk analysis is important;
• projects that would benefit from the creation of a prototype; and
• projects with unclear or complex requirements.

​

_AGILE Quality-driven

Cooperative _Iterative

Adaptable

Rapid

Not a process, it's a philosophy or set of values

WHAT IS AGILE?

Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.

It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations.

WHAT IS AGILE? (CONTD..)

Individuals and interactions over

processes and tools

​

Working software over comprehensive

documentation

Customer collaboration over

contract negotiation

Responding to change over

following a plan

AGILE MANIFESTO

SOME OF THE REAL LIFE EXAMPLES OF AGILE MODEL:

• Restaurant orders:
• Preparation of some of the food before opening the shop (sprint planning)
• continuous delivery of orders (adhoc stories)
• number of successful orders (velocity)
• cricket team:
• Run rate (velocity)
• team (scrum team self sufficient)
• over (sprint length)
• captain/ coach (scrum master)

​

​

WHAT ARE THE 12 PRINCIPLES OF AGILE?�

• Customer satisfaction
• Early and continuous delivery
• Embrace change
• Frequent delivery
• Collaboration of businesses and developers
• Motivated individuals
• Face-to-face conversation
• Functional products
• Technical excellence
• Simplicity
• Self-organized teams
• Regulation, reflection and adjustment

​

EXAMPLES OF AGILE METHODOLOGY�

• Scrum.
• Lean Software Development.
• Kanban.
• Extreme Programming (XP)
• Crystal.
• Dynamic Systems Development Method (DSDM)
• Feature Driven Development (FDD)
• Rapid Application Development (RAD)

​

AGILE UMBRELLA

Agile

Scrum

Crystal

Kanban

XP

DSDM

FDD

RUP

And few more…

RUP (120+)

XP (13)

Scrum (9)

Kanban (3)

Do Whatever!! (0)

More Prescriptive

more rules to follow

More Adaptive

fewer rules to follow

* Check wikipedia for list of all Agile methods

RUP has over 30 roles, over 20 activities, and over 70 artifacts

Large Companies that use Scrum…and lots of local guys, too

Intro to Scrum

60

THE GAME OF RUGBY --- SIMILAR TO AMERICAN FOOTBALL

• Scrum. Packs of opposing players push against each other for possession of the ball

​

• Once a team gets the ball, it attempts to “sprint” to the goal line.

61

THE RUGBY SCRUM

62

THE RUGBY “SPRINT”

wesleying.blogspot.com/2009/03/mens-club-rugb..

63

THREE MAJOR ROLES IN SCRUM

1. ScrumMaster, who maintains the processes (typically in lieu of a project manager);
2. Product Owner, who represents the stakeholders; and
3. Team, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

64

DAILY SCRUM (15 MINUTE MEETING)

• What have you done since yesterday?
• What are you planning to do by today?
• Do you have any problems preventing you from accomplishing your goal?

65

SPRINT PLANNING MEETING

• Plan next 15-30 days
• Select what work is to be done
• Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
• Identify and communicate how much of the work is likely to be done during the current sprint
• Eight hour limit

66

SPRINT REVIEW MEETING

• Review the work that was completed and not completed
• Present the completed work to the stakeholders (a.k.a. "the demo")
• Incomplete work cannot be demonstrated
• Four hour time limit

67

SPRINT RETROSPECTIVE

• All team members reflect on the past sprint.
• Make continuous process improvement.
• Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
• Three hour time limit

​

68

SCRUM DIAGRAM

www.methodsandtools.com/archive/archive.php?id=18

Definition of Scrum (n): A framework within which people can address

complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is

Scrum is

lightweight.

simple to

understand.

difficult to master.

SCRUM

Split your organization

into small, cross-functional, self- organizing teams.

A light-weight agile process tool

Scrum Team

Product/Project

​

Split your work into a list of small, concrete deliverables.

Sort the list by priority and estimate the relative effort of each item.

​

Scrum Master

Owner

SCRUM IN A NUTSHELL

So instead of a large group spending a long time building a

big thing, we have a small team spending a short time

building a small thing.

But integrating regularly to see the whole.

SCRUM PROCESS

CEREMONIES: THE MEETINGS

Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

Release Planning

(optional)

Create

regularity

Minimize the need for meetings not defined in Scrum

Are timeboxed

Designed to enable transparency and inspection

Scrum Roles

Product Owner

Scrum Master

The Team

ROLES: THE PEOPLE

Product Owner

PRODUCT OWNER

Works daily with the Scrum team

to clarify requirements

Member of the Scrum team

Decides what the project/product does and does not include

Bridges gaps between customer, stakeholders, and the Scrum Team

The single wringable neck, the PO is responsible for the project and driving product success.

Represents and speaks for the business needs of the project by creating and sharing the vision of the product.

Creates shared vision

PRODUCT OWNER’S RESPONSIBILITIES

Product

Backlog

Work with Team

Develops product vision, strategy, and direction

​

Sets short- and long-term goals for the product

​

Takes responsibility for the product’s budget and profitability

​

Provides or has access to product expertise

​

Decides on the release date for completed functionality

Gathers, prioritizes, and manages product requirements

​

Works with the team on a daily basis to answer questions and make decisions

​

Conveys product needs to the team

​

Accepts or rejects completed work during the sprint

Owns the product backlog

Product Backlog

Product Backlog

Our “to do” List

Backlog lists all of the work on a project

​

The Product Owner is responsible for the product backlog, including its content, availability, and priority ordering

​

A product backlog is never complete and evolves along with the product and the environment in which it will be used

Delete an item

Add an item

Product Backlog Items

The team determines how the backlog item will be achieved

The team determines the complexity of each product backlog item

As a team, we estimate the t-shirt size of this item as a small.

Here are the steps we will take to implement this item...

Product Backlog Item

Backlog E_Os_rt_dim_era_:te

:

Description: As a hotel

guest, I

want to reserve

a room

1

Small

online.

Hotel Software System Product Backlog

Scrum Master

SCRUM MASTER

Servant leader

Works daily with the Scrum team

Enabling (not accountability) role

Member of the Scrum team

Change agent

The Scrum Master is responsible for ensuring Scrum is understood and enacted while supporting the Team. Scrum Masters do this by acting as a coach, ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

The Team

SCRUM TEAM KEY FEATURE #1�THE TEAM MODEL IN SCRUM IS DESIGNED TO OPTIMIZE FLEXIBILITY, CREATIVITY, AND PRODUCTIVITY

Self-Organizing

Traditional

Self-organizing teams choose how to best accomplish their work, rather than being directed by others outside the team

Team’s tasks and work being directed by a

manager

SCRUM TEAM KEY FEATURE #2�THE TEAM MODEL IN SCRUM IS DESIGNED TO OPTIMIZE FLEXIBILITY, CREATIVITY, AND PRODUCTIVITY

Cross Functional

Traditional

Cross functional teams have all the competencies needed to accomplish the work without depending on others not part of the team

Traditional teams are formed by function

The Sprint

SPRINT BASICS

At the heart of Scrum is the Sprint

Consistent iteration of time (timebox) where the team completes a specific group of tasks from start to finish.

Timebox duration is consistent from sprint to sprint.

Timeboxes vary from team to team between 2 to 4 weeks.

Each Sprint can be thought of as a project. Like projects, Sprints are used to accomplish something.

Each Sprint builds incrementally on the work of prior Sprints.

ELEMENTS OF A SPRINT

Sprint Planning

We plan the work.

01

The Work

We do the work.

02

Daily Scrum

We coordinate the work.

03

1

3

2

We coordinate the work.

We plan the work.

Sprint Review &

04 ^{Retrospective}

We review the work.

We review the work.

4

We do the work.

CHANGES DURING THE SPRINT

Quality goals do

not decrease

02

01

03

Scope may be clarified and renegotiated as more is learned

No changes are made that would endanger the sprint goal

Starting a Sprint

1

2

3

4

Choose the user stories that

support those goals

Establish the goals for your

sprint

Break user stories into

specific tasks

Create a Sprint Backlog

Overview: Starting a Sprint

When planning a Sprint, you will:

₀₄ Steps

Sprint Backlog: Tasks

Tasks in agile projects should take a day or less to

complete for two reasons:

24

hours

₁

People are motivated to get to the finish line. If you have a task that you know you can complete quickly, you are more likely to finish on time.

One-day tasks can provide early red flags that a project might be veering off course.

2

Working in a Sprint

60

DOING THE WORK THROUGH THE SPRINT BACKLOG

Scrum Master is responsible for the resolution of impediments

Once a story starts, work should continue until the story meets the sprint definition of done

The team wins and loses together

Additional work for the sprint can emerge from existing stories in the sprint

Any team member can add, delete, or change the sprint backlog

Daily Scrum

DAILY SCRUM MEETING�THE ANSWERS THREE QUESTIONS

What did you do yesterday?

What will you do today?

Is there anything in your way?

DAILY SCRUM MEETING�AKA “DAILY STANDUP” OR “DAILY HUDDLE”

Meeting must last 15 minutes or less

Anyone may attend but only the team & Scrum Master may talk

Focus on status of current work, priorities, and impediments

Daily Scrum Meetings are for coordination, not problem solving

Ending a Sprint

Sprint Review

SPRINT REVIEW

Entire team participates

Show off product like a demo

Maximum of one hour per week

per sprint duration

​

Informal, no slides

Team presents what they accomplished during the

sprint to the Product Owner

Invite anyone and everyone who may be interested in the product

Intended to elicit feedback and foster collaboration

Sprint Retrospective

SPRINT RETROSPECTIVE�THE ANSWERS THREE QUESTIONS

What actions do we need to take moving forward to fix #2?

What didn’t go

well?

What did we do well?

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next sprint

02

All Scrum team members participate except for Product Owner (unless asked to participate)

04

Done at the end of every sprint

01

The results should be inputs (stories) into the backlog

03

SPRINT RETROSPECTIVE

Retrospective Item to Review: Team Rules

SPRINT RETROSPECTIVE

What should we continue to do in training?

What should we change or stop doing?

KEY FEATURES OF SCRUM METHODOLOGY�

• Scrum has a short fixed schedule of release cycles with adjustable scope known as sprints to address rapidly changing development needs. Each release could have multiple sprints. Each Scrum Project could have multiple Release Cycles.
• A repeating sequence of meetings, events, and milestones
• A practice of testing and implementing new requirements, known as stories, to make sure some work is released ready after each sprint

​

WHO CAN BENEFIT FROM SCRUM?�

• While scrum can benefit a wide variety of businesses and projects, these are the most likely beneficiaries:
• Complicated projects: Scrum methodology is ideal for projects that require teams to complete a backlog.�
• Companies that value results: Scrum is also beneficial to companies that value results over the documented progress of the process.�
• Companies that cater to customers: Scrum can help companies that develop products in accordance with customer preferences and specifications.

​

WHAT ARE THE BENEFITS OF AGILE SCRUM METHODOLOGY?�

• Here are some of the collective benefits of agile scrum methodology:
• Flexibility and adaptability
• Creativity and innovation
• Lower costs
• Quality improvement
• Organizational synergy
• Employee satisfaction
• Customer satisfaction

​

BENEFITS OF SCRUM�

• Rugby players try to gain control of the ball in the scrum and move it downfield. Software developers use scrum to move their projects quickly. And the benefits trickle down to software developers:
• Developers who want the freedom to make decisions thrive in scrum teams. Team morale tends to be high.
• Each sprint produces a product that is ready for market even though the project is ongoing. The highest priority requirements are addressed first so a high-quality, low-risk product can be on the market.
• The incremental process shortens the time to market by about 30 percent to 40 percent. Because the product owner is part of the scrum team, requirements can be delivered as they are needed.
• Scrum projects often realize a higher return on investment (ROI). This is attributed to:
• Decreased time to market.
• Early and regular feedback that prompts course corrections early when they are less costly.
• Defects that are fewer and less costly.
• Projects failing early and quickly when it’s less costly.
• Reviewing each sprint before the team moves on to the next sprint spreads testing throughout development.
• Project focus and goals can change with evolving business goals.

​

DISADVANTAGES OF SCRUM�

• While a rugby scrum may get rough and bloody, software developers shouldn’t have to worry about that. Nonetheless, scrum is not for all developer teams or software development projects. There are disadvantages to implementing scrum projects:
• There is a danger of scope creep if stakeholders keep adding functionality to the backlog. This could be encouraged by the fixed deadline.
• Scrum works best with small teams of experienced software developers. They need to be able to work quickly.
• Scrum teams do not work well when the scrum master micromanages their work.
• Losing any team members can hurt the progress of the project.

​

SCRUM BEST PRACTICES�

• Teamwork wins rugby games and helps software developers create quality products. To get the best quality out of scrum:
• Define requirements just in time to keep product features as relevant as possible.
• Test and incorporate product owner feedback daily.
• Sprint reviews with stakeholders need to be regular.
• The scrum team needs to use the sprint retrospectives to improve how they work.
• Conduct face-to-face conversations to reduce miscommunications.
• Trust the teams to do the best job possible.
• Allow the teams to self-organize around people’s skills, work styles and personalities.
• Don’t burn out the team members. Respect the balance between their personal and professional lives to ease stress. 

​

TOOLS

Program Management Tool

• Helps collaboration and project management
• Create single source of record for decision-making across business across Distributed Agile model
• Used Defect management tracking and In-Sprint metrics like Burn Down chart

Unit Testing Tool

• Jasmine is used for Unit Testing in behaviour-driven development framework
• It has easy syntax to enable write test cases
• Reports defects with the help of automated reports to identify defects which can be reported early in stage

Automation Testing Tool

• Selenium in BDD framework is used for Dev testing of Web
• Thucydides report has been used to report issues in a proper format
• It uses the benefits of JBehave and Maven build tool

Code Quality Reporting Tool

• Sonar is used as a web based code quality analysis tool for Maven based Java projects.
• Covers wide area of code quality check
• Sonar has rich set of features provided by tools like Covertura, PMD which makes it powerful for In-sprint testing

Continuous Delivery Tool

• Used to deploy code by a single click during In-sprint development builds for various environments(dev and local)
• Enables automation and streamline of build-test-release cycle
• Gives a graphical view of the staging process of Builds

AGILE METHODS

XP

WHY CAN XP BE BETTER?

EXTREME PROGRAMMING PROJECT

For more specific definitions of agile methodologies check out Agile’s Interview questions and Answers.

SCRUM (AGILE) METHODOLOGY

Material was borrowed from the “development that pays” site. Material is available at that site and is used with permission.

KANBAN (AGILE) METHODOLOGY

Material was borrowed from the “development that pays” site. Material is available at that site, and is used with permission.

RATIONAL UNIFIED PROCESS

RATIONAL UNIFIED PROCESS

JOINT APPLICATION DESIGN

• Users, Managers and Analysts work together for several days

​

• System requirements are reviewed

​

• Structured meetings

​

​

RISKS OF AGILE AND PROTOTYPING

​

• Premature convergence
• The design is not technically feasible
• The design phase encouraged a “big batch”
• The prototype “tests well” but fails to truly meet user needs
• You miss opportunities to deliver value (and learn) earlier
• You miss opportunities to engage engineers early in ideation
• The end product does not fully leverage what is technically achievable

From John Cutler, Is Agile the Enemy (of Good Design)? Hackernoon, Available Online. Last viewed July 31, 2018.

​

ENTERPRISE SYSTEM PLANNING

STAGES OF THE SDLC

IS 421

Systems Analysis

IS 422

Systems Design

PHASES OF THE SYSTEMS DEVELOPMENT LIFE CYCLE

• Project Identification and Selection Two Main Activities
• Identification of need
• Prioritization and translation of need into a development schedule
• Helps organization to determine whether or not resources should be dedicated to a project.
• Project Initiation and Planning
• Formal preliminary investigation of the problem at hand
• Presentation of reasons why system should or should not be developed by the organization

SYSTEMS DEVELOPMENT LIFE CYCLE

Analysis

• Study of current procedures and information systems
• Determine requirements
• Study current system
• Structure requirements and eliminate redundancies
• Generate alternative designs
• Compare alternatives
• Recommend best alternative

SYSTEMS DEVELOPMENT LIFE CYCLE

​

Design

• Logical Design
• Concentrates on business aspects of the system
• Physical Design
• Technical specifications

​

Implementation

• Implementation
• Hardware and software installation
• Programming
• User Training
• Documentation

Discussion about each methodology and its benefits is available at

http://www.technologyuk.net/software-development/sad/methodologies.shtml

​

This resource has recommendations about the various stages.

ROLES OF A METHODOLOGY

​

• Specify what tasks need to be completed

​

• Specify what deliverables should be created

​

• Specify whom should be included

​

​

WHAT A REAL METHODOLOGY LOOKS LIKE

ROLE OF A METHODOLOGY

To identify and track necessary deliverables

ROLE OF A METHODOLOGY

Project Management Guidelines

ROLE OF A METHODOLOGY

Estimation Guidelines

ROLE OF A METHODOLOGY

ROLE OF A METHODOLOGY

ROLE OF A METHODOLOGY

ROLE OF A METHODOLOGY

ROLE OF A METHODOLOGY

​

• Consistency of product

​

• Ease of reusability of code

​

• Facilitates changes in personnel

​

• Consistency of documentation

​